You are spot on Darius, voting for tickets hasn't been done that much so there are a couple of tickets with 1 vote and the rest with none.
As Darius requested, Implementers and Devs please take time and vote for tickets that you need to get done by the developer in the swim lane. I think it should be fine to vote for new features as long as the additions to get them done are minimal. Wyclif On Fri, Apr 13, 2012 at 7:41 PM, Darius Jazayeri <[email protected]>wrote: > 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 <[email protected]> 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<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >> OpenMRS Implementers' mailing list > > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from > OpenMRS Implementers' mailing list _________________________________________ To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-implement-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l]
