The OpenMRS core development team uses the a semi agile sprinting mechanism for getting features written in a coordinated fashion. This allows new features to move forward at a quick pace. It also distributes the knowledge of different features to a wider audience.
Anyone interested in joining a sprint should let either the sprint lead know or just send a general request to be on one to the dev list.
- Sprints are focused on one topic, and are usually 2 weeks long (some could be 1 or 3 weeks long as appropriate for the topic at hand)
- Each sprint should include 2+ OpenMRS developers. We may occasionally have multiple sprints going simultaneously, as not everyone needs to be assigned to every topic.
- We should always try to decide on a sprint topic 4 weeks before it starts.
- Each sprint should have a release in JIRA. The tickets in the release should be partially organized one week before the sprint. They must be finalized by the day before the sprint.
- The scope and tickets are locked-down once the sprint begins.
- To keep improving, each sprint ends with a retrospective look at what did and did not work with the previous week.
Schedule
2011
May
- 2nd - 16th: a module focused sprint
April
- 25th - May 2nd: Core bug fixes
- 11th - 24th: 1.9 Tickets
- 4th - 10th: Learn to use the 2.x UI Framework by building patient dashboard fragments. Lead: [Darius Jazayeri|~darius]
March
- 21st - 3rd: Reporting Module tickets. Lead: ~mseaton