Hi Mike, On Thursday, November 10, 2011 at 3:01 PM, Michael Seaton wrote:
> 1. I could check out the module code, reproduce the error, commit a fix back > to trunk of the module > 2. I could create a ticket to report this particular issue > 3. I could _not_ mark this ticket as "Ready For Work", "Claim Issue", or > "Assign Issue". That seems restricted. > 4. Because of 3, I could also not perform "Committed Code" on the issue That sounds more likely -- I think a fundamental assumption is that the critical path for issue management is that bugs are generally observed (and reported) before they are fixed. It's good for communication and it's good change management. For OpenMRS core, I personally would be concerned with allowing everyone to do issue triage due to potential quality and release planning issues. Of course, there is inherent delay in such a model as it scales - see Mozilla's challenges with triage [0] for example. On the other hand, a module developer or may choose otherwise (which is fine, of course) and can add multiple individuals or indeed all JIRA users into the "Approver" role which can triage issues. Fortunately, JIRA like GitHub has decentralized administration which allows this flexibility and independence, which I agree is important for a large distributed project like OpenMRS. Regarding the example at hand, I notice you are listed as in the Approver role for this project - I assume that's a recent addition and you'd be able to triage tickets for this project in the future. Michael [0] http://tylerdowner.wordpress.com/2011/08/27/some-clarification-and-musings/ _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
