Hi Wyclif, Thanks for sending this out, and for doing a great job with this new idea on short notice.
If I remember right, you did a couple of tickets that were highly-voted, but there were not that many Bug tickets in JIRA with lots of votes on them. Right? @Implementers and @Devs, we're pushing to always have someone work on the highest-voted bug tickets in JIRA. So, know that if you vote on those, they will get fixed. At this point there is only one Ready-for-Work ticket with issuetype=Bug and >1 vote. -Darius On Fri, Apr 13, 2012 at 4:05 PM, Wyclif Luyima <wyc...@openmrs.org> wrote: > Hi, > > This week we started something new in our development sprints where we > have one of the core developers taking the bug fixing 'swim lane', the > developer's primary focus is to work on the most voted/higher priority bug > issues from core, bundled modules and a couple of other modules, so it > happened to be me in the swim lane. > > Allow me to first whine for not playing 100% of this role not until > Tuesday mid morning, it was because i got to know about the new arrangement > on Monday so i used Monday and Tuesday morning to complete and clean up my > tickets in progress from the reporting sprint and evaluate GSoC proposals. > > With the above in mind, the Wednesday,Thursday developer calls, > the Regenstrief annual HIPPA training, i realized i had limited programming > time and the ticket(s) with the maximum votes had actually just 1, > therefore my criteria for picking tickets to work on came down to ticket > priority, those that required less time to get done and had no major design > controversies. Below are the tickets that i worked on/investigated; > > > - TRUNK-2442 <https://tickets.openmrs.org/browse/TRUNK-2442> - Person > attributes do not display on patient search results (Updated the wiki > page for the search widgets to reflect the additions to support attributes > in general) > - HTML-71 <https://tickets.openmrs.org/browse/HTML-71> - Add search to > location selector (Updated the wiki documentation for the tag) > - TRUNK-1868 <https://tickets.openmrs.org/browse/TRUNK-1868> - Force > password change page help text should reflect security global properties > - TRUNK-3149 <https://tickets.openmrs.org/browse/TRUNK-3149> on 1.6.5 > - Changing concept names with the ui doesn't save (Investigated > and couldn't reproduce it, so needs closing) > - TRUNK-1955 <https://tickets.openmrs.org/browse/TRUNK-1955> - > Relationships lost when creating a new patient and results not refreshed > - RCM-15 <https://tickets.openmrs.org/browse/RCM-15> - Include Patient > Attributes when doing a data export (Need to commit this, but should > do so before monday) > - REPORT-166 <https://tickets.openmrs.org/browse/REPORT-166> - Ensure > that all date-based queries are appropriately handling boundary conditions > (Investigated, > didn't gave time to finish it so i added a patch with my additions and > added all list of date based query classes that need to be tested in a > ticket comment) > - META-217 <https://tickets.openmrs.org/browse/META-127> - Recent MDS > versions break Sync, leading to potential data loss (came up today > towards end of day, investigated/had irc discussions but got no where code > wise so left it for darius since his work day was still going on) > > In general, I think the arrangement is a good idea, so i'm looking forward > to the next time i'm in 'The Lane'. > > Have a great weekend, > > Wyclif > > > > > > > ------------------------------ > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-implement-l>from > OpenMRS Implementers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
