On Wed, May 28, 2008 at 03:02:17PM +0200, Marco Pesenti Gritti wrote: > Relying on email and irc for this seems fragile to me. If a trac query > would reveal the packages which are staged for inclusion in a certain > release, it would be pretty much impossible that they go unnoticed. > > Marco
That's fair. Suppose we make tickets for each release contract. The relevant properties of the contracts that we want to represent include their risk of slippage, the people who are responsible for seeing them to fruition, and some material about the terms of the contract like links to test cases, test results, and which bugs/features are supposed to be finished upon successful completion of the contract. Some of these things are easy to represent with existing Trac features. For example, we might represent slippage risk with a simple tag scheme like <rel>:+, <rel>:?, and <rel>:- Example interpretation: If we saw a ticket labeled rel-8.1.1:- rel-8.2:? then we should conclude that this was a contract which had slipped from 8.1.1 to 8.2 and which was in question in 8.2. (The advantage of this scheme over regular milestones is that my example ticket would be represented in proper context in displays about either 8.1.1 or 8.2). We also need some way of recording what actual people are responsible for bringing the contract to fruition. Trac only permits one Owner but it permits many tags. It seems that tags like <role>:<name> (e.g. tester:erikos) would suffice for this purpose. What to do about test cases and test results? Perhaps we should establish a convention that all release contracts will have a test cases wiki page and a test results wiki page at specific names, e.g. wiki.laptop.org/go/Test Cases/<num> wiki.laptop.org/go/Test Results/<num> and modify Trac to automatically insert prominent hyperlinks on tickets tagged "rel-contract"? Finally, there is the issue of work queues. I still have no clue how to represent, using either either Trac or the wiki, the fact that every individual has a work queue which differs from the Global Ticket Priority ordering. People clearly have personal queues for all sorts of reasons including: * people process several tickets concurrently to avoid waiting on one another * individuals often prefer to fix easy, hard, or well-understood things first * people barter work among themselves in order to help one another finish things off; this causes people to work on surprising things (I want to know about personal queues because I want to pay attention to the instantaneous velocity of development [i.e. in order to predict where the code base will have moved to after the next \epsilon units of time have elapsed].) Comments? Michael _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar