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

[DAVID ROLDAN MARTINEZ]

Thank you very much, Steve!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
________________________________________
De: Steve Swinsburg [steve.swinsburg at gmail.com]
Enviado el: martes, 30 de noviembre de 2010 23:40
Para: Jean-Francois Leveque
CC: David Haines; sakai2-tcc at collab.sakaiproject.org Committee; DAVID ROLDAN MARTINEZ
Asunto: Re: [sakai2-tcc] Cross cutting concerns and prompt patching during a major release

FYI I've added a section to that page that covers i18n in Wicket:

http://confluence.sakaiproject.org/display/I18N/Best+Practices+for+Internationalized+Tools+in+Sakai#BestPracticesforInternationalizedToolsinSakai-Wicketbasedtools

cheers,
Steve


On 01/12/2010, at 1:58 AM, Jean-Francois Leveque wrote:

> 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
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc