[sugar] Software Status Meeting Tomorrow @ 1400 EDT, 1800 UTC in #olpc-meeting on freenode

[Marco Pesenti Gritti]

On Wed, May 28, 2008 at 4:08 PM, Michael Stone <michael at laptop.org> wrote:
> 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"?

All of this sounds pretty good to me.

> 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].)

Couple of random ideas:

* Several people started to add a TODO to their User wiki page on
sugarlabs.org. We might encourage something like that. It's unlikely
that everyone will do it and keep it updated though.
* At Red Hat all the engineers are sending in weekly status reports,
which also contains a "Plans for this week" section.

Marco