Mr. Meitar Moscovitz wrote: > On Aug 25, 2008, at 12:21 PM, Noah Kantrowitz wrote: > >> Mr. Meitar Moscovitz wrote: >>> > >>> For what it's worth, from your reaction, I'm starting to think >>> "subtickets" or "supertickets" is probably a bad name for what I'm >>> doing since it evokes too much similar imagery to the whole >>> dependency >>> thing. Perhaps "somewhat related tickets" would be better, but it >>> doesn't quite roll off the tongue as nicely. >> I think you mean to be saying "related tickets". In any case, not >> having >> the bi-directional linking seems silly to me, since you can only trace >> what is related in a single direction (not really up or down, since >> this >> more of a set of buckets than a tree). I think what you want is >> actually >> a graph (though a mostly flat one consisting of several clusters), but >> you are getting hung up on the concept of "blocking" which is >> orthogonal >> from creating a graph of ticket relations. The semantics of those >> relations are an entirely different topic. >> >> --Noah > > Yeah, "related tickets" might be better. The term "sub/super"-ticket > came from the direction of the relationship, but perhaps that's not > really important for my use case and could be dropped from the > terminology. > > With regard to bi-directionality, one could always use the same > technique to (litter) one of the "superticket"'s fields with keywords/ > TracLinks/whatever to the subtickets, but I haven't (yet) encountered > a situation where this is actually that useful and I think that > introduces the kinds of problems you mentioned in your previous > message. If this kind of bi-directional functionality is desired, I > agree that something in the software system itself would need to > enforce consistency. > > I guess, really, I'm purposefully not looking for complicated > functionality because I want to keep the software out of it as much as > possible. What is that great Einstein quote? "Things should be as > simple as possible, and no simpler."
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
signature.asc
Description: OpenPGP digital signature
