[Building Sakai] Maintenance Team Discussion

[John Bush]

Count us in for participating with this group, I can dedicate some  
time and part of the time of our developer who pretty much does this  
sort of thing full time already.

John Bush
Development Manager
rSmart




On Jul 16, 2009, at 8: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"