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

[Steve Swinsburg]

HI Alan,

This process sounds good. If there was a way to automate it via some JIRA plugin, that would be ideal. Otherwise, a cleverly created filter would work.
The other options is that we have more committers that can do it themselves.

cheers,
Steve


On 24/11/2010, at 8:06 PM, Berg, Alan wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20101124/12636f5b/attachment-0001.html