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

[Josh Baron]

I'll just toss into the discussion the idea of leveraging CS/IS students 
(both graduate and undergraduate) to play some role in such a team. 
Several institutions, RPI being one that comes to mind, are or have 
created computer science programs that focus on open source development 
models.  Although I recognize that students are not going to address major 
problems, they might be able to work on more minor issues.  I see two 
benefits:  inexpensive/no cost labor and some "free" project management 
that would be done by the faculty member involved.

I'd be interested in helping to organize some type of pilot around this 
concept here at Marist College but would need a way of "plugging" them 
into this effort.

Josh

-----------------------------
Joshua Baron
Director, Academic Technology and eLearning
Marist College
Poughkeepsie, New York  12601
(845) 575-3623 (work)
Twitter: JoshBaron



From:
Clay Fenlason <clay.fenlason at et.gatech.edu>
To:
Anthony Whyte <arwhyte at umich.edu>
Cc:
management at collab.sakaiproject.org, Sakai QA 
<sakai-qa at collab.sakaiproject.org>, "sakai-dev at collab.sakaiproject.org 
Developers" <sakai-dev at collab.sakaiproject.org>
Date:
07/16/2009 02:47 PM
Subject:
Re: [WG: Sakai QA] [Building Sakai] Maintenance Team Discussion



I'd add that Anthony would be far better at this than I would be.

~Clay

On Thu, Jul 16, 2009 at 1:04 PM, Anthony Whyte<arwhyte at umich.edu> wrote:
> 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"
>>
>>
>
>



-- 
Clay Fenlason
Director, Educational Technology
Georgia Institute of Technology
(404) 385-6644
_______________________________________________
sakai-qa mailing list
sakai-qa at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-qa

TO UNSUBSCRIBE: send email to sakai-qa-unsubscribe at collab.sakaiproject.org 
with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20090716/90c17f6c/attachment.html