Mailing List Archive

Now, I can understand how this feature would be useful to certain users,
but my personal opinion is that Trac may not be a good fit in these
environments. Not every application can meet every need, and I'm not
sure I see Trac being able to fulfill this need in the near future. I
think one of Trac's strengths is it's simplicity. It supports some nice
features, but the interface has been kept fairly trim and easy-to-use.
While features like this would be of use to some people, I have a
feeling that it would simply over-complicate Trac for many users.

I see Trac being best suited for smallish development teams and open-
source projects. This kind of feature is useful in a larger corporate
setting, but I think it would detract from the usability of Trac for
these smaller users. I don't want to see Trac's interface turn into
Bugzilla with so many options that it's even intimidating to developers.
I'm sure Trac can learn some from the other bug-tracking systems out
there, but I don't want to see it try support every feature just because
someone else has implemented it.

Now, I've gotten the impression that one of the goals for Trac's future
is to make it more modular and extensible, so at some point it may be
possible to add-in "optional" features that some people would find
useful, but others may desire to leave out. However, I don't think
there's any strong push in that direction at the moment, it's just an
idea that's being considered for the future.

I suppose that since you're looking at Trac, then Mantis must be lacking
in other areas that Trac is good at, but I think trying to hack
something like this into Trac at the moment would just lead to
code/interface bloat.

--
Matthew Good <trac@matt-good.net>

> I see Trac being best suited for smallish development teams and open-
> source projects. This kind of feature is useful in a larger corporate
> setting, but I think it would detract from the usability of Trac for
> these smaller users.

Closed source. One primary developer, plus three other external
contributors who have supplied specific small elements (installers,
protocol translation), one graphic designer, two sales/support guys, a
dozen beta testers and a few thousand customers, some tens of whom have
problems.

I think that qualifies us as a smallish development team?

Actually this kind of feature would be especially useful to us, a small
team developing in a commercial environment, because it would give us the
possibility of using one tool to cover our needs for a number of different
groups. From an administration point of view setting one acceptance level
and a private/public checkbox is going to be a lot more usable than having
to set up multiple packages and the communications between them to cater
for the differing needs of developers, support etc, especially when you
consider that each group is so small.

I understand your desire to avoid bloat, but from where I'm sitting
(thinking about the time required to administer the system) this doesn't
qualify.

regards

Jon

Well, I think that I'm a little concerned about the public/private thing
since while it seems simple, I believe there are a number of concerns
I'd have about how to protect some of that information. My initial
thought would be to keep the whole system internal, though I suppose
that you could block anonymous users from viewing most everything on the
site, but still give them permission to file tickets.

I would think that the ticket ownership may good enough for now to group
tickets like you're talking about. Just have a standard for assigning
tickets like "test", "sales", and "dev" or something similar, and the
people can use different reports to look up the tickets they're
interested in. It wouldn't prevent the employees from looking at each
other's tickets, but I wouldn't think that's as much the concern as
trying to filter them so they don't have to see everyone else's tickets.

If you still need something added to Trac, try to figure out the
requirements (e.g. should tickets default to public or private?, can
anonymous users change the public/privateness of a ticket?, do you need
customers to see their own tickets, but not other peoples?, how do you
deal with technical discussions on a ticket if the customer can see
it?). Also someone's been working on ticket dependencies recently which
may be necessary in your situation, since it's likely you'd need to
create separate tickets for the customer's report of a problem, and a
more detailed ticket for the technical side of things, and you'd need to
figure out how to deal with the relationship of these tickets.

--
Matthew Good <trac@matt-good.net>

Oh, the other thing I meant to say is that maybe if you really need
this, you can hack it onto your own installation of Trac. When you've
gotten it to a good point submit a patch and see what other Trac users
think about it. Even if it isn't adopted into the main Trac source,
you'll have your tool to do what you need.

--
Matthew Good <trac@matt-good.net>