August 2009

First Agenda Items


1. Overall review of Clay's release proposal and the council's role therein

2. Characteristics for 2.8, and relationship w/ release management

Nate says: Should this be: "Criteria for 2.x projects moving to or already in the Maintenance development stage"?

Clay: What I have in mind are significant new capabilities (e.g. tools) that call for more than a lightweight process. Specifically, picking up on my release proposal, I'm talking about what the product council thinks it should be doing for 2.8. Assuming this proposal is adopted.

Nate says: OK, agreed. I think it would be good also to discuss who/when/how new capabilities will be deemed to follow the light- or heavy-weight process. I'm leaning toward the idea that projects should decide for themselves how significant new capabilities are and which process to follow, and then whatever teams are managing each process would recommend a project follow the other only if warranted (eg, faced with a proposed heavy-weight capability change that didn't seem to warrant it, the council might recommend to a project to follow the light-weight process instead).

3. Criteria for 3.x projects moving from R&D to incubation

4. "the characteristics we will ask to see demonstrated to approve status changes for new capabilities" (Nate said this, but I'm not sure I understand it, exactly)

Nate clarifies: this is the global topic for 1 and 2 above and anything else similar. Maybe I'm being too careful with language (wink) I've started to use the term "characteristics" rather than "criteria" as I think it sounds less foreboding and may better describe the variety of qualities (not all of them technical) we expect to see in projects as they move from one status to another. We want projects to "demonstrate" characteristics to us rather than expecting us to do the work to see if projects meet criteria. "Status" refers to the different project stages outlined in the new development process: R&D, Incubation, Product Development, Maintenance, End of Life.

So, in the end, I'm just suggesting we need to address the overall issue of project characteristics for different statuses, and how they will be demonstrated.

Clay: To keep it short and simple for now, I'm of the view that we should focus on what's needed to enter incubation, since nothing, in principle, has crossed even that threshold yet.  Suggestions I've heard include (a) simply having the project declare that it wishes to enter incubation and (b) having the project submit some sort of initial scorecard.  There may be other ideas. Then I think we need some clear, shared understanding of what we think should be happening in incubation, which I'm not sure can be simplified right now to just "working to demonstrate the characteristics needed to go into the next stage."  I'm (slightly) less concerned that we pin down what the remaining thresholds entail exactly, at the moment.

Then, of course, we need to get this all published for comment, revise and clarify. The chief goal in my mind is to quickly pave the way - by eliminating confusion - for project teams pawing at the gate.

Nate: OK, agreed. Agenda item withdrawn. Let's let the council's full role be defined organically following tangible release needs. Also, why do I always have to be Mr. Blue?