[WG: I18N & L10N] Resource bottlenecks and the need to look for dedicated effort.

[Neal Caidin]

Hi Anthony and All,

Administrative:

I've created a Jira filter called "i18n CLE Open and Awaiting Review" just now, which should be available to everyone.  It picks up 104 issues. I didn't add the filter of Affects version since the CLE projects don't all use the same version numbers. So we might filter things out that shouldn't be filtered?

I tried refining the search for issuetype = Contributed Patch, but that brings up 4 out of the 104, so clearly that is not picking up all the patches. Not surprising as I would expect that issues labeled as bugs and feature requests might get patches added to them, but not sure how to pick that up in a query.

Neal


On Feb 19, 2013, at 11:32 PM, Anthony Whyte <arwhyte at umich.edu> wrote:

> Alan/Neal--can you provide filters to the i18n and feature request tickets in question?  An i18n filter I created as a cursory check is below:
> 
> i18n open/awaiting review with an affects version of 2.8.0+ (n=75) [1]
> 	open = 37 (49.33%)
> 		open with patch attached = 18 (48.64%)
> 	awaiting review = 38 (50.66%)
> 		awaiting review with patch attached = 8 (21.05%)
> 	total patch attached = 26 (34.66%)
> 
>> The conclusion was that the patches were bottlenecked due to the lack of a dedicated and trusted committer(s). Other slow moving patches include feature requests that have the same cause.
> 
> 
> The data suggests that the conclusion above is too narrowly drawn and that at least two additional factors are contributing to the bottleneck, as you describe it.  First, less than half of the open tickets included the i18n filter I created include a patch.  Patch output is clearly an issue; without patches open i18n tickets are likely to languish.  Also, a cursory check of the comments sections of these tickets suggests that a number of the patches have been reviewed and have not been accepted for one reason or another or in one case at least have been applied but reverted.  So quality issues affecting certain patches is another factor contributing to the bottleneck.
> 
> Second, over half of the tickets in the dataset are awaiting review.  Such a number supports Sam's contention that a review bottleneck exists and that i18n reviewers are needed to keep the tickets moving.
> 
> Cheers,
> 
> Anth
> 
> [1] https://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=13660
> 
> JQL = (project = SAK OR project=BLTI OR project=KNL or project=LSNBLDR OR project=MSND OR project=MSGCNTR OR project=POLL OR project=PRFL OR project=RES OR project=SAM OR project=SRCH OR project=SHORTURL OR project=STAT) AND component = internationalization AND status IN ("open", "Awaiting Review") AND affectedVersion IN ("2.8.0","2.8.1","2.8.2","2.8.3","2.9.0", "2.9.1") order by priority desc
> 
> 
> 
> 
> On Feb 19, 2013, at 6:40 PM, Sam Ottenhoff wrote:
> 
>> 
>> At the Paris Conference Jean-Francois and myself were tasked with supporting the review of i18n  Jira patches that were long standing and did not appear to be moving forward. Neal Caidin followed through with looking at a number of example patches.  The conclusion was that the patches were bottlenecked due to the lack of a dedicated and trusted committer(s). Other slow moving patches include feature requests that have the same cause.
>> 
>> 
>> Is the committer the bottleneck, or is the review the bottleneck?  On a CLE Team call where we discussed a large amount of new translations contributed by Unicon, Jean-Francois mentioned that he wanted a reviewer for each language before a commit was made to trunk.  There were several people on that CLE Team call willing to commit, but clearly we don't have the review capabilities.
>> 
>>  
>> 
>> Murcia University have reviewed their local improvements. When they migrate to the our best Sakai version ever (2.9.1) they will follow community best practice and try to return the improvements all 22 patches back to trunk. I expect that a similar bottleneck condition will ensue under the present conditions.
>> 
>> 
>> I can promise that if they are added to our weekly CLE Team call, they will be reviewed.  We meet every week on Thursday at a European-friendly 15:00 GMT.  Our agenda URL follows this pattern:
>> 
>>   http://etherpad.ctools.org/rmmt-2013-02-21
>> 
>> Steps that can be taken to increase the chances of a quick and helpful review:
>> 
>> 1) Clean patches; no formatting changes, whitespace changes
>> 2) Patches against latest trunk 
>> 3) Attend the CLE Team call to answer questions or explain the need
>> 4) Answer questions presented in the JIRA (the quicker the responses, the better)
>> 5) A clear explanation of the problem the patch is attempting to solve
>> 6) Screenshots!
>> 
>> The weekly phone call is attended by many core committers to Sakai who respond and followup to issues every week.  I assure any institution looking to get their patches into trunk that they will receive debate and feedback if they are added to our weekly agenda. 
>> 
>> --Sam
>> _______________________________________________
>> i18n mailing list
>> i18n at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/i18n
>> 
>> TO UNSUBSCRIBE: send email to i18n-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> _______________________________________________
> i18n mailing list
> i18n at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/i18n
> 
> TO UNSUBSCRIBE: send email to i18n-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/i18n/attachments/20130220/2ee02cb7/attachment-0001.html