[Trac] Feature comparison of Trac to Jira? (not baiting)

Christopher Petrilli petrilli at gmail.com
Thu Jul 28 23:26:10 CDT 2005


On 7/28/05, Janine Sisk <janine at furfly.net> wrote:
> On Jul 28, 2005, at 5:39 PM, Jason Dunham wrote:
> 
> > I'm trying to install the beta and try to add this "custom" workflow
> > in our copy, but I don't understand the resistance into adding this
> > into Trac, or the assertion that the existing workflow is "good"
> > enough for most teams.  Doesn't everyone have this problem?
> 
> I haven't even installed Trac yet so my opinion doesn't count for very
> much, but this is very important to me as well.  In fact the lack of
> this feature is one reason why I'm looking for alternatives to our
> current task manager.

I can't speak for the "team" that works on Trac regularly, but I think
the general "guideline" is to make Trac suitable for 80% of the world
while encuring 20% of the work.  It will never replace Remedy, but
then Remedy is a disaster of needless complexity for its own sake.

My personal opinion is that if you, for example, have people that
shouldn't be closing a ticket, that this is a permission issue, not a
"workflow" issue. Workflow, for me, traditionally, is the routing of
things. Think Lotus Notes.  What I hear is people saying that they
don't want certain individuals/groups of individuals to be capable of
performing certain actions.  This is permission structure, and
something I believe that is being worked on at some level.

Honestly, if you can't trust your developers to set the box on a
ticket to the right setting and need a nanny to do this for you, then
you have problems infinately worse than lack of "workflow".  I've
found that from a practical perspective, in a good development team
(mind you, the largest I've had to corral is about 6) that simply
telling people how to treat the system is nearly as effective as
making the system babysit them.

Just my two cents, but if this is your "deciding factor," then I think
you need to re-think your evaluation priorities. For me, the factors
are:

1. Ease-of-use. Without this, people simply won't use the system, and
the rest is irrelevent.
2. Loose coupling. Tightly coupled systems tend to be stagnant and
less adaptable to new problems.
3. Integration with knowledge. This is where the integration with the
wiki is critical.
4. Integration with code-set.  We use Subversion, and this integration
level is excellent.

Again, Trac isn't all-things-to-all-people, and so if you absosmurfly
must have a formal workflow system, then I suspect you're going to
need to look elsewhere.  Personally, with 6 developers and several
thousand tickets, it's not been a problem.

Chris
-- 
| Christopher Petrilli
| petrilli at gmail.com


More information about the Trac mailing list