We’ve been using Trac for some time as a development and project management tool. It does have it’s shortcomings, but it is very easy to extend. The most recent issue I’ve had is trying to retrofit a hierarchy to the components and tickets.
I started by using a naming convention of [Component]:[Subcomponent]. This is nice as it groups the component, BUT when I tried to then use the milestones I discovered that they work by this this naming convention [Component]:[Milestone]. Oh dear. I would have thought a core module would be a bit more robustly implemented, but no matter. I am considering writing a replacement for the milestone which incorporates this change, and some other things I will discuss now.
The way milestones seem to be used is to look to future versions. ie, versions are historic, milestones are in the future. This is fine, but it seems odd that we would hold two separate lists for these. ie, when we make a release we don’t delete the milestone, we add a new version. Why doesn’t the milestone move over automatically. My suggestion is this:
Replace milestones and versions with one type called milestones. Have a type field for the milestone with “Project” and “Release” as the default values. The versions selection in the ticket screen will just show release milestones. We can then produce a report for any milestone to show the pending tickets, and if we want, gantt chart the project milestones.
This is designed to work with the sprint plugin which Andrew Sharpe wrote, which is just yet another way of grouping tickets into buckets of work. So, doing away with milestones will free up the fore-mentioned naming convention, and allow us to create a component hierarchy which will again assist in reporting. I would probably wrap all of this up in the spring plugin, as subcomponents which could be used. At least then we have one working package, as opposed to many disjoint ones.
Finally we could add some of the timing and estimations functionality in as well, which would round off the project management requirements.
I guess this brings up a philosophical argument about reuse vs reimplementation. While I usually make a song and dance about reuse (ie use the existing implementation), I think that some of this functionality is so small or fine-grained that integration and maintenance will become a headache. We can take the good ideas and wrap the whole thing up in a neat little ball.
Just a thought anyway.
Powered by ScribeFire.