[WG: Sakai QA] [Management] Release Process Proposal

Beth Kirschner bkirschn at umich.edu
Thu Jul 30 05:57:20 PDT 2009


+1

This all seems reasonable to me -- subject to change and refinement as  
we go along. I think explicit leadership is a good thing, while  
maintaining an open process.

- Beth

On Jul 29, 2009, at 8:45 PM, Clay Fenlason wrote:

> Just a reminder that I'm looking for comment through the end of this
> week, and if there remain no objections, plan to press ahead as
> outlined in the proposal.
>
> ~Clay
>
> On Mon, Jul 27, 2009 at 3:43 PM, Clay
> Fenlason<clay.fenlason at et.gatech.edu> wrote:
>> After having a couple conversations offline, it sounded to me like it
>> wasn't hard to get the wrong idea about the notion of the release
>> management team, so I'm going to hunt for some better language, but I
>> thought I'd do that by thinking out loud in this thread.
>>
>> The main purpose of the close collaboration of the product manager  
>> and
>> this formal release team ahead of code freeze is, in my view, to
>> develop an achievable plan for release management and testing. It's  
>> to
>> survey all the development work on the table, get a sense of what the
>> associated risks are, see that they have time to be adequately  
>> tested,
>> documented, and lead to a solid release.  But the focus is on  
>> devising
>> a credible plan and publishing it for the community ahead of time,  
>> not
>> on approving or rejecting development work.
>>
>> Now, if it turns out that a credible plan is impossible in a given
>> timeframe and with the array of new development work on the table,
>> then that will have to lead to another conversation which the release
>> team isn't going to settle it by fiat.  Its role will be to surface
>> this information for a broader consensus to be reached, basically
>> saying, "We don't think this can be done, and so we either need to
>> look at adding a month or two to the release schedule, or postponing
>> some planned features, but something needs to give."  Leaving aside
>> the details of what happens then, the important point is that the  
>> team
>> is meant to bring greater transparency to these issues up front, and
>> reduce the risk of surprises well into the process. (As a
>> side-benefit, I think the community should get a fairly decent
>> projection of "release notes" even before formal QA begins, which
>> should put their respective training and support staffs ahead of the
>> game)
>>
>> After code freeze there may be decision points along the way where
>> action needs to be taken based on issues of code quality, etc. In  
>> such
>> instances we don't want a discussion with no clear resolution, nor do
>> we want expertise overruled by influence (or whoever happened to show
>> up for the call that week).  In my view, we want a technical
>> decision-making process like the balance achieved by Apache's
>> processes, where consensus is sought, yet which is also bracketed by
>> formal mechanisms for reaching resolution. To that extent, then, a
>> formal team.
>>
>> Finally, the initial set of 3 team members is to me still very much
>> just a minimal starting point, and I expect the group to grow quickly
>> by meritocratic means, where again I think the Apache process has
>> useful rules of thumb for expanding this kind of technical governance
>> in a meaningful way. The proposal linked to below would task the
>> initial 3 members with proposing how they think that should run.
>>
>> ~Clay
>>
>> On Fri, Jul 24, 2009 at 11:20 AM, Clay
>> Fenlason<clay.fenlason at et.gatech.edu> wrote:
>>> I'd promised a week ago a specific proposal for a release process,
>>> building on discussions at the project coordination meetings and
>>> on-list [1].  I now have a draft of this proposal on Confluence,  
>>> which
>>> focuses on the release process for 2.x over the next 10-12 months:
>>>
>>> http://confluence.sakaiproject.org/display/MGT/Release+Proposal 
>>> +2009 [2]
>>>
>>> My plan is to continue to develop/refine this proposal with comment
>>> from the community over the course of the next week, and if no
>>> 'blocker' disagreements emerge in discussion, I will act to  
>>> coordinate
>>> the 'Next Steps' laid out in the proposal fairly quickly. Some of  
>>> the
>>> details in the proposal can be revised as we go, but I'm eager to  
>>> get
>>> started and allow as much time as possible to follow through on its
>>> aims, so I'll urge eveyone to take a close look and offer up  
>>> questions
>>> and comment as soon as they can.
>>>
>>> ~Clay
>>>
>>> [1] http://www.nabble.com/-Building-Sakai--2.7-Release-Discussion-to24541385.html
>>> [2] http://confluence.sakaiproject.org/display/MGT/Release+Proposal+2009
>>>
>>
> _______________________________________________
> management mailing list
> management at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"



More information about the sakai-qa mailing list