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

[csev]

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