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

[David Haines]

One way to sidestep some of these issues is to have clear best practices for cross cutting concerns.  If an issue does occur a lot in different context there very likely is a standard approach that works in Sakai.  If that is well documented then developers will know where to find a good solution.  Increasing this kind of consistency reduces everybody's work load in the long run by avoiding churn when things need to updates / fixes / enhancements. 

Is there a clearly documented set of best practices for internationalization?  If not is this an area that could have clear best practices?

- Dave

David Haines
CTools Developer
Digital Media Commons
University of Michigan 
dlhaines at umich.edu




On Nov 30, 2010, at 8:54 AM, DAVID ROLDAN MARTINEZ wrote:

> I was not talking about changes in properties files. I can manage them by myself and make the commit directly without asking permission because they are low risk changes.
> 
> I was talking about functionality bugs. Tools that don't work at all if you change the language and, for example, shows the content in English because they are not able to change dynamically language to adapt to user preferred language. Will you put in production a tool that shows everything in Chinese to non-Chinese speaking users? I'm sure you won't, won't you? I'm talking about tools that use conditions based in hardcoded English values at checkboxes o radiobuttons and that, when you change the languages, don't respond and seem to do nothing.
> 
> I'm not talking about providing the tasks and leave the tool/project leader alone. I'm talking about helping him/her to test it (once again, because we don't upload a patch if it hasn't been property tested) and make the commit to save him/her time. I'm talking about improving Sakai existing features that are objectively working bad not about adding new features that you can find useful or you can't.
> 
> I'm not offering only a list of problems but also solutions to those problems. Why not to take it in a more agile way, above all if the tool/project leader is unresponsive? 
> 
> What we should state clearly is what we want Sakai to be. Do we want Sakai to be spread all around the world? If yes, we must fix i18n issues first. Do we want Sakai to be used by disabled people? If yes, we must fix accessibility issue first. Do we have a strategic approach or roadmap about which are the objectives that Sakai want to reach? If don't, probably, we must invest time into this before to continue discussing about how patches should be managed. In order to deploy tactic plans (for example, guidelines to make patch management more efficiently and effectively), we must have better defined the strategic plan. 
> 
> -----Mensaje original-----
> De: csev [mailto:csev at umich.edu] 
> Enviado el: martes, 30 de noviembre de 2010 14:37
> Para: sakai2-tcc at collab.sakaiproject.org Committee
> CC: DAVID ROLDAN MARTINEZ; Megan May
> Asunto: Re: [sakai2-tcc] Cross cutting concerns and prompt patching during a major release
> 
> 
> On Nov 30, 2010, at 7:59 AM, May, Megan Marie wrote:
> 
>> 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.   
> 
> 
> I was thinking a similar thing - this probably is not about properties file changes - which I think moves in pretty quickly with Beth making sure things move reasonably deterministically.    If there is some sticking point about properties changes - then we should understand what those are.   If project leads are resisting properties changes or making them wait a long time - that is not good at all.
> 
> I am guessing that this is more about functionality changes to improve the ability to internationalize something - this is not something that Beth fast-tracks and requires a bit of project team involvement.   Historically, these code tweaks are not always as trivial as they sound on the surface and I hesitate creating a process that pushes them in when a timer expires.
> 
> In a sense, we are better off with a slightly broken Russian translation than no translation - but we are not better off with broken or inconsistent functionality.
> 
> I am mindful of the effort that made button text translatable and the number of hacks that 'solved the problem for now' versus the longer-term careful work that went into fixing it properly.
> 
> We need to be careful not to conflate "properties changes" which have historically been given special privilege and fast-tracked - with other forms of internationalization-related code changes that really fall into the same category as other code changes and need to be worked into a project effort and resourced.
> 
>> 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. 
> 
> I have lost track of the multiple suggestions for how we tweak the UI.  I want an indication that anyone can set that says a JIRA is "trunk-ready" much like we already indicate "ready to merge" in the various branches.  Some else said we need a "patch attached checkbox" - as a project lead I find a mere checkbox that a patch is attached as useless.  When I have a few days few to work on portal after a month where local priorities took me away, I want to be able to quickly scan and find the low hanging fruit so I can make the best progress and get the most work done in my limited time.  Without the trunk ready flag, the job of scanning my "queue" is just harder - so I will get less done and likely miss some low-hanging patch fruit.
> 
> I lost track of where the conversation was going - I made my suggestion with my project lead hat on - no one agreed - counter proposals were put out that I liked less - so I kind of figured I would drop the conversation and let the collective figure it out. :)
> 
> /Chuck
> _______________________________________________
> 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/20101130/901d3e07/attachment-0001.html