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

[Clay Fenlason]

Right. What would happen after this week is not that the issue will be
closed and no more debate allowed, but rather that we would start in
on the "Next Steps" and continue to work things out as we go.

~Clay

On Thu, Jul 30, 2009 at 8:57 AM, Beth Kirschner<bkirschn at umich.edu> wrote:
> +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"
>
>