Wiki Spaces


Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack


Page tree
Skip to end of metadata
Go to start of metadata


As a community, OpenMRS understands there is great value in investing in ongoing (omni-present) development effort dedicated to cleaning up general bugs and feature requests that are highly voted (i.e., important to implementations).  We also know new developers have a better experience when there are more experienced developers around to help answer their questions.  Therefore, we have created an explicit "Community Development" swim lane that is always running (and sometimes gets its own sprint) within which developers in the community can work together to learn how to work with OpenMRS and, together, try to knock out some of the bugs & feature requests that matter most to our implementations.  Recognizing the importance of this swim lane, we (OpenMRS) ensure that an experienced developer is involved in the community development swim lane. The lead developer in the community development swim lane should try to find about 20%-25% of their time to work on tickets in the ongoing OpenMRS sprint at the given time.

Swim lane? Why a swim lane?

In swimming pools (whether for practice or during competitions), swimmers are placed into lanes. This serves to keep people from bumping into each other and, for developers, the idea of a "swim lane" keeps them focused on their task/goal. Swim lanes are a popular metaphor used in managing business processes.


  • Every week there will be at least one developer (hopefully many) working in the bug fixing swim lane. We call these folks 'Community Developers'.  This can (and purposely) happens while other devs are working on the current Development Sprint.
  • We assign a full-time OpenMRS developer to lead the community development process.  See calendar below to identify who this person is on any given week.
  • The goal of the community development swim lane is to tackle both high-priority bugs and long-standing issues. This keeps the queue of them from building up and requiring fewer all-team bug fixing sprints.
  • The community developers should send a *report* out to the community at the end of each week with a brief overview of what all tickets were completed during that week.

    When possible, the community developers should try to avoid the low complexity & intro tickets, if they are able to tackle others, leaving those for new devs and volunteers wanting to get their feet wet.

  • Community developers should look at bugs across all openmrs-supported projects and modules. That list currently is:

    project in ("OpenMRS Trunk", "OpenMRS Standalone", "Release Testing Helper", "HTML Form Entry Module",
     "Reporting Module", "HTML Widgets", "Reporting Compatability Module", "Serialization XStream", "XForms Module", 
     "Patient Flags Module", "Form Entry Module", "Metadata Sharing Module", "Module Maven Archetype")
  • The list of all OpenMRS pull requests.
  • You should also regularly look at error reports at . Look for validity/reproducibility, and, if appropriate, convert them into bug issues in the appropriate JIRA project(s):

T Key Summary Assignee Reporter P Status Resolution Created Updated Due

Join the Community Development Swim Lane

We assign a full-time OpenMRS developer to lead the community development process.  See the calendar below to identify who this person is on any given week.  Look for community developers in IRC or send a note to our Developers mailing list.


The queue of tickets that the community developers should choose from is here:

Choosing tickets

The most important box is the yellow "Open Blocker Tickets". This list should always be as small as possible. Any unassigned ticket should be top priority; claim them; Some in the list might just need a second person to review; review those. Some might have an assignee that has languished; ask them if you can claim the ticket from them.

The bottom left box is general open bugs. These are ordered by votes. The popular tickets are on top. Choose any off the stack.

The middle box are tickets that have been submitted but need to be confirmed, tested, reproduced, or just moved into the "Ready For Work" state in the right project. These should be relatively quick tasks. Anything needed to get them out of the "Needs Assessment" state.

The far right column contains unclosed tickets with patches attached to it that need to be reviewed and tickets that have been committed and just need to be reviewed a final time before being closed (or asked for Rework if needbe)

Community Development Lead Calendar


    Customise the different types of events you'd like to manage in this calendar.


    Optionally, restrict who can view or add events to the team calendar.


    Grab the calendar's URL and email it to your team, or paste it on a page to embed the calendar.


    The calendar is ready to go! Click any day on the calendar to add an event or use the Add event button.


    Subscribe to calendars using your favourite calendar client.




  1. All these queries are not as good as a list, at least tag them for the community development swim lane and keep the number of issues tagged down to that which can be worked in, say, 10 days.

    I want to call your attention to TRUNK-3072. It's still marked unresolved, although patches are attached through 1.8. It appears to be related to a problem in 1.9, see TRUNK-3482.

    1. This list is supposed to be an ongoing/weekly list of things to work on. We don't want to have to update and choose/label bugs every week. The devs that are working in the community development swim lane can pick and choose what he wants from as high on the list as possible.

      As far as the tickets, thanks for the pointer. I commented on one and committed the other.