CVSTrac
Contents:
2004-2008: The RT years
Starting in 2004, my former company used Best Practical's Request Tracker 3.4 to manage our customer requests. As years passed, we modified it more and more heavily, to the point where it knew about CVS commits related to tickets, displayed multi-ticket project structure progress charts, and had complete time tracking and invoicing.
Also, because some of our tickets had nearly a thousand messages, RT and mod_perl proved utterly inefficient, taking over 5 minutes to display our longest tickets, so I redid the history display in PHP to achieve the same results in under 3 seconds for the longest ones... But that's beyond the point of this document. :)
Life after RT
When I sold the company, RT went with it, and I definitely didn't want to support its system requirements on my home Linux computer. After a few months without anything though, I realized how much I missed it for managing tasks. I tried Task Coach 0.70, but that only allowed ME to track my tasks, not for anyone else to keep tabs.
Finally, I found CVSTrac which is tiny, runs on a SQLite database, and is surprisingly efficient for all things CVS. Sure it lacks all of RT's e-mail communication skills (not to mention those which we added over the years in our custom version) but it does have solid audit trails, and much tighter integration with CVS than we had achieved with RT. Given that I am a nearly one-man operation now, I can live with managing e-mails separately from tickets, so CVSTrac is a great fit.
Software I wrote around CVSTrac
This is the kind of feature which, for now anyway, seemed beyond the scope of CVSTrac per se, which aims to be a "low-ceremony bug tracker." I absolutely needed these features though, so I implemented them in modular PHP additions that are designed to exist side-by-side with CVSTrac. With these features, I'm able to use CVSTrac for managing 100% of my work, including allowing my clients to keep track of my TODO and budgetting. Less and less reasons to miss RT. :-)
Time Clock
I needed two custom fields: "Hours Estimated" and "Hours Worked." In both fields, I use decimal notation. That said, it's a pain to manually estimate how much time we've spent here or there. Thus, I created my 4th generation "punch in/out" interface (first was shell-based in the 1990's, second was based on my obsolete alternative to PHP "DT" around 2000, third was in PHP/JS for RT around 2005.)
Get it here: Time Clock for CVSTrac
Invoicing
A natural progression from Time Clock, is the need to select closed tickets (which haven't yet been invoiced) and bundle them up into a little invoice e-mail. Nothing fancy, but that method worked great for me back in the RT days. Select your criteria, type your hourly rate, select which matching tickets you want to include in this specific invoice, enter comments if you have any, and e-mail away. The result has a total and everything, though it's in text format for now. I plan to upgrade to text+html eventually.
I will release it as soon as I'll finish my user-friendliness tweaks.
Mailgate
I also wrote an e-mail gateway for CVSTrac. It serves as both a "Change Notification" program for outgoing updates, and as an inbound new ticket creator and remark appender based on the subject. Note that it is not protected from SPAM, but it does refuse to create tickets from strangers. (No automatic user creation.)
Get it here: Mailgate for CVSTrac
Possible future innovations
Flexible e-mail history
The only thing I still miss from RT is the rigor from ticket numbers. When communicating with clients, we were always referring to tickets by number, (with hundreds of open/stalled tickets at a time, ticketing was an absolute necessity. We managed over 10,000 in just a few years.) Even our clients grew fond of the concept, which is now somewhat lost since I exchange e-mails directly with clients instead of using something like RT to file them in the appropriate tickets and what not. (And no, "threading" in a regular e-mail client doesn't do a good enough job; I've tried several times.) RT was regularly my only CRM interface.
I wrote CVSTrac Mailgate (see above) to at least log new requests and little remarks, and keep the right people informed about significant ticket updates. That said, it's very basic, and could not sustain the kinds of long-winded threads some of our R&D stuff generated in the RT days.
So about incoming e-mails, I think I'll want to create new DB tables containing e-mails individually and fully parsed like we had in RT. An external tool to tickets could then simply be the e-mail history viewer; that way CVSTrac wouldn't have to be modified at all. That way the audit trail (called "history" in CVSTrac) would stay clean. The main question left at this point is whether I should still append new messages to CVSTrac's remarks or leave them alone.
Project management
If the above ever gets done, the next logical step would be to bring to CVSTrac the kind of project management goodies I had grafted into RT back in the day. Basically it's a matter of allowing ticket parenthood (easy), preventing one from closing a ticket with unresolved children, and creating a "project" display of a ticket and all its family tree, including a visual on time estimated vs already worked for each and globally. Since the view aspect of this was already done in PHP on top of RT databases, I think I could port these aspects without too much trouble on top of CVSTrac. It's overkill for the work I'm doing these days, though. But if I have larger projects again, I think I'll prefer creating such tools for CVSTrac rather than going back to RT. I just don't like Perl's performance on my hardware.
Whoa, that's it
Actually, for what we did in RT, that would bring CVSTrac on par with it. Tickets are already wiki text in CVSTrac so there's no need for the "Project Charter" hack we had in RT. The distinction between parenthood and dependency was also tricky to deal with, so I don't miss it too much. It could be implemented relatively easily anyway. With all of the above, though, CVSTrac wouldn't be "low-ceremony" that's for sure, but in its current form (version 2.0.1) the lack of communications in it is bothersome. (For example, I opened a few tickets at cvstrac.org but I have no other way than to go visit each page periodically to see if any got new remarks appended. If I was "subscribed" to e-mail notifications in tickets I created or participated in, it would be unbelievably more efficient for all involved. So at minimum, CVSTrac needs a good intelligent e-mail gateway to send relevant people the notifications they need. Hm. Food for thought, anyway.