On Aug 25, 2008, at 2:37 PM, Noah Kantrowitz wrote:
> While I can't question if this works for you or not, I think you are
> ignoring some major usability concerns. If person A only looks at
> their
> tickets, and you (person B) mark one of your tickets as being
> related to
> one of person A's tickets, I would imagine they would want to be
> informed of that fact. If everyone watches all ticket changes, I
> suppose
> this is a non-issue, but that would be very hard to do on a project of
> any decent size.
>
> --Noah
It's quite possible that I've never worked on a large-enough project
for this to be an issue. It's also possible that this is another
example of where the problem is actually a people issue, not a
software issue.
That is, if I am a developer and I wish to mark my ticket as being
related to another developer's tickets, whether or not I notify that
developer of this fact should be my choice and I may choose to send
that developer a message to that effect. In essence, it's still *my*
ticket, isn't it? And the keywords I add to it are, at least under
this convention, for my own benefit anyway.
I'm not saying that this feature wouldn't "be nice to have," because
sure, that'd be a nice option. As you mentioned, however, Trac
currently doesn't do this, which is obviously only a problem for those
people who want that feature *right now* (hence the existence of
MasterTicketsPlugin, I assume).
Another option for someone who wanted something like this *right now*,
if I am the "other developer" in this scenario, is to make some
*other* notification system which, theoretically, could be based off
of something as simple as a page on the wiki with a ticket query that
shows me something like this:
{{{
[[]TicketQuery(status!=closed&owner!=ME&keywords~=#)]
}}}
and then further filters those results. Fragile? Yeah, certainly not
as robust as a "native" solution, but entirely feasible nonetheless.
Ultimately, though, this is the point I was making before: it's up to
the project to determine the level of complexity they require from
their tools. I've never been involved in something like, say, the
Linux kernel or Firefox development so I'm not claiming to be an
expert on this topic, but I can tell you that in all of my experience,
all of these problems were better solved by improving the cohesion of
the development team(s) rather than building business logic into
software that enforced undesirable workflows.
But that, as you've also mentioned, is another topic entirely.
Cheers,
--
-Meitar Moscovitz
Personal: http://maymay.net
Professional: http://MeitarMoscovitz.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---
