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

[Jean-Francois Leveque]

There are already documented best practices in
http://confluence.sakaiproject.org/display/I18N/Best+Practices+for+Internationalized+Tools+in+Sakai

They may not be complete (cover every dev use case) but it seems that, 
most of the time, new developments aren't done using them and old code 
is not reviewed by owners to account for them.

I will gladly help improve the best practices for more dev use case 
coverage, but it seems very few devs mind because they haven't asked any 
question about this documentation for cases not covered.

Maybe we should ask devs to document how their code is internationalized 
first instead of having to find ourselves and be disappointed. Could 
this be requested for new releases?

J-F

David Haines a écrit :
> 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 <mailto: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 
>> <mailto: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