[sakai2-tcc] FW: Cross cutting concerns and prompt patching during a major release

[Anthony Whyte]

Gents, it's a public list.  Please join at

http://collab.sakaiproject.org/mailman/listinfo

Anth



On Nov 25, 2010, at 3:23 AM, Berg, Alan wrote:

> 
> ________________________________________
> From: DAVID ROLDAN MARTINEZ [darolmar at upvnet.upv.es]
> Sent: 24 November 2010 20:21
> To: Berg, Alan
> Subject: RV: Cross cutting concerns and prompt patching during a major release
> 
> And this one...
> ________________________________________
> De: DAVID ROLDAN MARTINEZ
> Enviado el: miércoles, 24 de noviembre de 2010 10:31
> Para: Berg, Alan; sakai2-tcc at collab.sakaiproject.org
> Asunto: RE: Cross cutting concerns and prompt patching during a major release
> 
> Dear all,
> 
> First of all, I would like to thank Alan his support, help, patience... :)
> 
> I'm strongly agree with this procedure. What I was doing until now was:
> 1) Wait two weeks for patch to merge
> 2) Send email to project lead
> 3) Cry and sing Bobby McFerrin' song "Don't worry, be happy". ;-)
> 4) Go to 2)...and, probably, go to 3)
> 
> I'm offering Spanish Sakai Universities (S2U) group resource to fix open bugs. We don't need anyone to fix the bugs on our behalf. We will fix them. What we want is to be sure that our effort and work will be incorporated to Sakai releases in a concrete timeline. Thus, we are preparing a project plan (I'll make you arrive our MS-Project file as soon as it will be ready) to show our commitment. However, this project plan won't be successful if we don't have the power to "force" tools leader to apply our patch or we apply the patches on our own (but, obviously, in a coordinated way with the tool leader or TCC). And I'm offering myself to manage it. We don't want to add more workload to community member, we want to lighten their workload and, of course, lighten our workload each time we change of Sakai realease because we have to face (once again, and againg, and again, ....) with same issue.
> 
> We (S2U) want to spread Sakai over Latinamerican countries but, to do this, having Sakai fully internationalized (not only translated) is key. Will you put in to production a software/system that is not working 100 % in English? I don't think so.
> 
> Cheers,
> 
>     David
> ________________________________________
> De: Berg, Alan [A.M.Berg at uva.nl]
> Enviado el: miércoles, 24 de noviembre de 2010 10:06
> Para: sakai2-tcc at collab.sakaiproject.org
> CC: DAVID ROLDAN MARTINEZ
> Asunto: Cross cutting concerns and prompt patching during a major release
> 
> Dear TCC,
> 
> Firing off my 5 cents worth ...
> 
> The majority of projects are good neighbours; a couple of projects are well intentioned but slow moving due to local resource issues.  We are all in the same shared boat, Internationalization, accessibility, security, UI issues affect the whole of Sakai. To make sure that patches get merged in a timely manner during a major release I would like a generic escalation process to be agreed for all cross cutting concerns.
> 
> As part of the process improvement around QA in my role I supported the idea of focussing on cross cutting concerns that over arch all projects. A number of members of the development community have come forward to deal with the technological deficit from the QA side.
> 
> Currently the Spanish speaking community has an opportunity to grow exponentially.  The members of that community are actively thinking of coordinating resources through the QA lead for Internationalization David Roldan Martinez to improve to a state that the community (Samoo and Sigma) can hand on heart say that Sakai 2.x is truly ready for their target audience.   The punch line is this; some of the donated patches are not getting in fast enough or at all for specific projects.
> 
> My suggestion looking for refinement is that donated patches. For cross cutting concerns, if they are not merged or rejected in a certain agreed time, then we should have a valid escalation process.
> 
> If you want exact details of slower moving projects David R can supply, however, I would prefer to discuss at a more procedural level and avoid any potential finger pointing. I am certain slow moving patches are caused not by any bad motivations, simply resource and time planning barriers.
> 
> The escalation process I was thinking of was:
> 
> 
> 1)      Wait two weeks for patch to merge
> 
> 2)      Send email to project lead
> 
> 3)      If patch is not merged by x then the MT review the patch and merge unless the project lead disagrees.
> 
> 4)      If the project lead disagrees then the patch is escalated for debate to the TCC.
> 
> 
> 
> WDYT?
> 
> 
> 
> 
> Alan
> 
> Alan Berg
> QA Director - The Sakai Foundation
> 
> Senior Developer / Quality Assurance
> Group Education and Research Services
> Central Computer Services
> University of Amsterdam
> 
> http://home.uva.nl/a.m.berg
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20101125/9d52560b/attachment-0001.bin