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

[DAVID ROLDAN MARTINEZ]

Oh, I know that i18n is not the only subject in the world. :D
But is the field in what I'm working at. What I would like to feel with enough permissions to commit the patches without hurting to an unresponsive tool/project leader. Bugs are bugs and if patches are really well tested (remember if we generate a patch, generally, we have tested it in production), committing that patches will be great for everyone. This is why we should distinguish between bugs (something that doesn't work thus, fixing it is objectively good for everybody) and feature requests or contributed patches than can be more subjective.
David

-----Mensaje original-----
De: May, Megan Marie [mailto:mmmay at indiana.edu] 
Enviado el: martes, 30 de noviembre de 2010 13:59
Para: DAVID ROLDAN MARTINEZ; sakai2-tcc at collab.sakaiproject.org
Asunto: RE: [sakai2-tcc] Cross cutting concerns and prompt patching during a major release

Hi David, 
  My comments were solely in response to Chucks suggestion to changing the JIRA workflow and trying to better understand the differences in the different suggestions.  It's a dirty secret but I love reengineering processes :-) The first step  in that is truly understanding what people want to accomplish. 

My two cents - when leads are unresponsive to patches that is when the SF staff members should be brought in.    I'm also going to throw in that getting patches reviewed/committed isn't just an issue for i18n.   

Remember, collaboration comes at a cost!
Megan 



-----Original Message-----
From: sakai2-tcc-bounces at collab.sakaiproject.org [mailto:sakai2-tcc-bounces at collab.sakaiproject.org] On Behalf Of DAVID ROLDAN MARTINEZ
Sent: Monday, November 29, 2010 5:44 PM
To: sakai2-tcc at collab.sakaiproject.org
Subject: Re: [sakai2-tcc] Cross cutting concerns and prompt patching during a major release


      Hi Megan,

      The problem is what happens when the tool leader is unresponsive. In my case (i18n), this happens more times than I wanted. :( When I fix a bug, first thing I do is write an email to the leader asking him/her to test (and offering my help, if needed) and commit the patch to solve the bug (note that I'm refering to bug and a bug is something that doesn't work, a failure). If 15 days after, the leader is unresponsive, I write an email once again. Some of them, answer then but other don't. Should I commit the patch fixing a bug (let me insist in the fact that a bug is a solution to a problem that makes a software no to work) instead of writing an email to the leader n times? Should I forward my mails to MT that, by the way, it is very busy and whose I'm a member. I waste lots of time writing mails instead of fixing bugs and this has a impact on Sakai QA.

      If we want Sakai to be spread all around the world, i18n is key (think in China, Latinamerica, etc.). So we need an agile way to put our i18n bug patches so that institutions can see Sakai speaking multilingual without errors.

      Cheers,
           David
_______________________________________________
sakai2-tcc mailing list
sakai2-tcc at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc