Hi Michael,
Thanks, I understand your position. What I'm saying is that I _did_
observe a bug before and I _was_ able to fix it, but the owner of the
module was out of contact for a period of time and without asking Darius
to add me as an approver, I was unable to move that ticket forward.
I'm not saying that there aren't points pro and con here. But I would
like to get the community's input on this, and if the consensus is to
let the community police itself and not add process restrictions
unnecessarily, then I would hope that we're open to changing the way
things operate.
Regards,
Mike
On 11/10/2011 03:25 PM, Michael Downey wrote:
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/
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
_________________________________________
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]
