I, for one, would just like to have my own email added to the longest email thread ever about OpenMRS and git.
Also, I am willing to move formentry, remoteformentry, dataintegrity or any of the other modules I am intimately familiar with over to git if someone really wants me to. I'll probably start my toying around by moving AMPATH-specific modules to our own organization, but I will keep with the nomenclature of "openmrs-module-[modulename]". Jeremy Keiper OpenMRS Core Developer AMPATH / IU-Kenya Support On Thu, Nov 10, 2011 at 3:41 PM, Michael Seaton <[email protected]> wrote: > ** > 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<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > > ------------------------------ > Click here to > unsubscribe<[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]
