On Aug 21, 2008, at 10:47 PM, Jorge Salamero Sanz wrote: > hi all, > > i've implemented a very basic and maybe in a hackish way subtickets > over the > masterticketplugin. > > you can have a look to the src here[0] and some doc here[1]. what do > you think > about merging this into mastertickets ? > > btw, you can find some other trac plugins and tools we develop in > Warp Networks > in the same trac website. > > [0] http://public.warp.es/trac-stuff/browser/plugins/mastertickets-plugin > [1] http://public.warp.es/trac-stuff/wiki/Plugins/MasterTickets
Indeed, as noted prior in this thread, these links require a log in. On a slightly related note, however, I'm wondering what people's motivations are for using "subtickets" in the first place. Recently, my dev team has discussed the whole idea of tickets within other tickets at length and we've come up with a few simple guiding principles that help us on our projects: * If you have an idea or want to remember to "do something," we make a ticket. * If the ticket or the thing to do is "kind of big" it's just a regular ticket. * If we then add another ticket that is "kind of related", we use the keyword field to place a reference to the original ticket number. * Enforcing ticket *dependencies*, however, is actually unhelpful because they *create* exactly the kinds of situations (blocks) we want to avoid. This was originally conceived in a classic "oh hey, this should be easy" light bulb moment. I even tweeted it[0]. It's lead to the following documentation on the (not installed by default) TicketKeywords wiki page on most of our projects: "…a subticket keyword is simply a reference to another ticket by its ticket number (in standard TracLinks format) that marks the ticket with the keyword as a subticket of the one referred to by the keyword (which then becomes a superticket). These keywords always begin with an octothorp (#) and are followed by one or more numerals. For example, to mark a new ticket being created as a subticket of ticket: 10, enter #10 as one of its keywords." This creates a very loose concept of a "superticket" and a "subticket", but does not cause the software to enforce any kinds of dependencies or workflow on these tickets, which is what we want. Nevertheless, this is extremely useful because then traditional queries can reference "all subtickets" of a ticket simply by using a query like one in the following example (which shows subtickets for ticket:13): [[TicketQuery(kewords~=#13)]] To any supertickets in our projects, we typically add this TicketQuery macro at the end of the ticket description so that the ticket description itself contains a listing of all its subtickets. If desired, *policy*, and specifically not software, can then enforce workflows around what to do with supertickets, yet we've actually found that the more we treat cases like this on a case-by-case basis, the more agile we are. Just my 2 cents. Cheers, -- -Meitar Moscovitz Personal: http://maymay.net Professional: http://MeitarMoscovitz.com EXTERNAL REFERENCES: [0] http://twitter.com/maymaym/statuses/853375056 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
