[WG: Sakai QA] [Building Sakai] Maintenance Team Discussion

[Anthony Whyte]

I was nominated at Saturday's meeting to work on putting together a  
maintenance team.

Cheers,

Anth

> - a Foundation staff member would need to initiate the effort to first
> assemble such a team (and it should be Michael's problem to figure out
> who)




On Jul 16, 2009, at 11:03 AM, Clay Fenlason wrote:

> Among the topics treated in Saturday's project coordination
> discussions (as well as the product council meeting and a breakfast of
> forlorn managers) was the idea of a "maintenance team."  I'm going to
> try to represent this broad discussion for community comment,
> following which I'll try to draft a consensus proposal that may be
> used to attract concrete commitments.
>
> The goals of such a team seemed fairly uncontroversial. Support for
> the idea in principle was echoed by managers at IU, Cambridge, CSU,
> Berkeley, Georgia Tech, UCT, UMich, and Unicon, and was reinforced by
> a post-mortem examination of the 2.6 QA process. The goals expressed
> were:
>
> - to have a reliable set of resource to call upon in fixing problems  
> in the code
> - to allow institutions to reclaim development resource at the end of
> a project without threatening maintainability of the codebase.
> Tracking down the original developer to fix issues has not proved to
> be a sustainable tactic.
> - to provide expert review of code quality and to that extent
> influence the question of whether a given project is ready for release
> (ie 'maintainability' may be measured by whether the maintenance team
> is prepared to take it on)
> - to provide a way for new contributors to learn and become active in
> the developer community; submitting patches for bugs is a time-honored
> way to both get many eyes on the problem and get people on the
> meritocratic on-ramp.
>
> But that leaves open many practical questions.  The project
> coordination discussion on Saturday took things further by examining
> two models for such a team:
>
> 1) a single, strong coordinator with a diffuse set of devoted time (ie
> managers of developers would commit hours of time from their teams
> rather than particular people)
> 2) a small set of core, dedicated people (ie managers of developers
> would commit larger shares of time from particular people)
>
> In the end (of the discussion on Saturday) it seemed that the only
> model which could satisfy the goals would be a hybrid.  Without a set
> of core people it was felt that mentorship would be hard to achieve,
> for example, and yet without a diffuse membership with a low threshold
> for entry it would be more difficult for managers to make the resource
> commitment, and more difficult for new participants to get engaged.
> So we came to the point of proposing:
>
> 3) a small set of core, dedicated people providing leadership and
> mentoring for a diffuse pool of effort based on a commitment of hours
> from managers of development resource.
>
> A few other practical points were agreed on:
>
> - a Foundation staff member would need to initiate the effort to first
> assemble such a team (and it should be Michael's problem to figure out
> who)
> - once the initial team was assembled, it should self-organize in
> taking on its charge
> - lest there be any confusion, the team would be devoted to fixes, not
> new features
>
> If I've left anything out, I'm sure someone will correct me. Other
> comments and questions are welcome.
>
> -- 
> Clay
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20090716/9872bafe/attachment-0001.bin