OpenMRS individual bug fix

So the semester is starting to come to an end and everyone in team handicapped is working on individual bugs to fix in order to contribute to the project as a whole. The OpenMRS project has been changing a lot in the last few weeks. OpenMRS has now moved to a SCRUM like methodology for their main development team. OpenMRS now concentrates on a specific development issue for two weeks at a time. These sprints help the development team conquer individual issues very efficiently. Last sprint's theme was the OpenMRS 2.x UI framework design and development. Here are some stats that were sent out on the dev list:

• 7 people used the 2.x UI framework to create patient dashboard fragments
• Abbas Hachem: patientPrograms
• Darius Jazayeri: personDetails, patientIdentifiers, standardPatientHeader
• Jeremy Keiper: personNames
• Mike Seaton: personAttributes
• Rafal Korytkowski: personAddresses
• Wyclif Luyima: patientProblems
• We did a pretty good job of navigating distributed locations and time zones
• We completed 18 tickets
• the dashboard fragments, and assorted framework improvements I made in response to people's requests
• We didn't get to 3 non-essential tickets
• Each participant made useful suggestions about features the framework needs, improvements to widgets, or to our patient fragment conventions.

It seems to me like these sprints have been very useful for OpenMRS.

There is one problem with the new methodology that I was concerned with. How was team handicapped going to contribute? I promptly asked Ben Wolfe, who is now my go-to-guy for OpenMRS questions, if we had to only work on sprints. Turns out we can work on whatever tickets we want. Sprints are simply the recommended process of contribution.

After my conversation with Ben our group sat down and planned out an individual bug to work on for each of us. Right now I am working on TRUNK-2148. This bug is related to the JUnit tests within OpenMRS. Right now some tests are reporting ERROR to the build log. OpenMRS dev team has requested that they be logged as INFO instead. My job is to find every place the log.error is used within OpenMRS code and change it. No Problem! Just so happens there are 723 matches within eclipse's search. I've got some time to work on the project later this week so i hope to finish parsing the project this week. This fix might take some time because direct communication with some of the lead devs is needed to find out the functionality of each error that is logged.

My plans for contribution later is to somehow contribute to the creation of OpenMRS 2.x. I think there is lots of opportunity there and I would like to dive into it.

Til' next time...Adios.