[wplug-internet] Proposal to set up a ticket tracking system on the server

[Pat Barron]

On 10/11/2016 12:33 AM, Vance Kochenderfer wrote:
>
> Pat, it seems like you have a very clear idea of what you're trying to
> accomplish - I'd like to get a good handle on that.  What types of
> issues do you want to track?  Is this just for technical stuff, or are
> organizational issues included?
Ultimately, my goal is to be able to track items of work that need to be 
done and who is supposed to do it, and give other potentially interested 
parties a way to have visibility into it as progress is made.  I think 
this makes it less likely that tasks will get misplaced or tabled 
indefinitely because other things came up and the work was lost track 
of, since you have a nice (for some value of "nice", I guess...) 
dashboard you can look at at any time to see what work is open and who 
is supposed to act on it.

The items that could be trackable are really anything - technical 
issues, organizational issues, whatever we find that our needs are.

One of the nice things about Trac (I will speak from the perspective of 
Trac for the moment, because that's what I have working right now, and 
am somewhat familiar with) is that it supports the concept of multiple 
projects - each with it's own (potentially completely different) user 
base, ticket categories, ticket statuses, project areas and/or component 
identifiers, etc. - even all the way down to what Trac plugins are 
available for each project.  And once you have a Trac system set up, 
adding new projects to it is a piece of cake. For example, we could have 
one project area set up for the Technology Committee to work with 
technical issues (which is how I put together the example Trac project 
that is running right now), with the appropriate user list, categories 
of tickets that are applicable to technical issues, etc. - and an 
entirely separate project for the Board to track it's own activities, 
that has a completely separate user list, potentially different ticket 
categories that are a better fit for organizational tasks, etc.  I have 
lived in environments where there was "One Ticket System To Rule Them 
All", and absolutely *everything* was force-fit into that one single 
system, from technical "fix the server" tickets, to things like sales 
lead tracking - it can become very messy, and quite unpleasant to deal 
with (for both the people who have to use it, and the people who have to 
take care of it).

>
> Who are we anticipating to submit tickets?  Who will address them?  What
> notifications do we want the system to send?
The assumption I'm working with is that the people who will submit 
tickets will be the people generally involved in the work being done, 
and that the same population will be addressing the tickets. In other 
words, I'm not envisioning that the ticket system would have general 
access for anyone to open tickets.  What I have in mind is not like a 
"help desk" system, where anyone in the community being served can open 
tickets, which get triaged by a dispatcher of some kind and distributed 
to people who will resolve them (Trac actually does have the ability for 
anonymous users to open tickets without having an account in the system, 
and - via the account management plugin - the ability for anyone to fill 
out a form to request an account in the ticket system.  I have both of 
those functions disabled at this time).  I'm envisioning more of a 
"distributed to-do list", with perhaps some support for various sensible 
types of workflow (like ticket assignment workflow).

Notifications of ticket changes to whoever opened a ticket, whoever is 
supposed to own the ticket, and perhaps a given CC list of interested 
parties, is good.  From my perspective, it would be nice to see 
notifications to component or subject area "owners" anytime a ticket is 
opened in their area (though Trac doesn't support that, AFAIK).

Reporting (as distinct from real-time notifications) are also nice - 
like, show me a report of all open tickets, or show me a report of all 
tickets closed in the last 30 days, etc.  Though for the volume of 
tickets I'd imagine we'd be managing, probably not necessary. Most 
ticketing systems that store things in a relational database, you can do 
various kinds of ad hoc reporting "offline", by pulling data directly 
from the database.

For me, though, the primary characteristic of any system that we would 
want to use should be *simplicity*.  My own goal is a lightweight 
solution that doesn't require much (if any) supporting infrastructure, 
and doesn't require a lot of care and feeding.  I'm willing to give up 
some types of functionality (other than obvious "showstoppers") as a 
trade-off to make that part happen.  Our needs (as I envision them) are 
fairly simple, so I don't think we need, like, a full-blown CRM solution 
like Redmine, or an all-singing, all-dancing, "does every possible thing 
that anyone could ever want to do" configuration control system like 
Rational Team Concert, to satisfy those needs.  In fact, I'm kind of 
shying away from any kind of solution that would be more like, "this is 
really a configuration control system that has an issue tracking 
function, and we'd only use the issue tracking function and ignore 
everything else".  My immediate impression is that even something like 
Bugzilla is more complex than we'd really want.

In my mind, the two leading contenders at the moment are Trac and Fossil 
(even though Fossil is, in fact, a "configuration control system that 
has an issue tracking function, and we'd only use the issue tracking 
function and ignore everything else...."), in that they're both single 
executables that you just run, and they (for the most part) just work.  
Joe did some investigation of Fossil, and one of the stumbling blocks is 
it really isn't set up to do any kind of notifications, at all, unless 
you hack on it and write code yourself.

I'd love to learn of any additional candidates!

--Pat.