Ticket Curation

Each week experienced developers in the Community Development Swim Lane are expected to be curating tickets. Under the direction of the Community Development Leader, the community development swim lane effort is expected to include about 1 day a week (or 2 hrs a day during a week) of ticket curation.

The goal of a curator is to check if the tickets are well defined and complete. Every ticket should be doable by a newcomer without much further input/discussion. If more information is needed, request additional information from the creator or from the dev list. The curator should make the tickets ready for work and also remove/link to any duplicate tickets.

All complete tickets should be labelled as 'curated' once they are ready for work and fully described as below.

A well curated ticket should have/be:

1. Ticket should not be duplicate in the repository

2. Must have short/accurate summary.

   • When creating or editing a summary, imagine what should appear as the bullet item in release notes describing that the work has been done.  For example: "OpenMRS won't work" would be a poor summary; "OpenMRS fails to successfully start if module X is misconfigured" would be better.

3. Description should give background information and a proposed solution/outcome such that a newcomer know where to start

   • Bugs should describe the problem, expected behavior, observed behavior, and instructions on how to recreate the problem

4. Description (or a comment) should have the expected files to edit

5. The Severity, Complexity, and Expected Time fields should be filled out

6. Set the affectedVersions field, in most cases add the latest released versions in each supported line of release where the bug can be reproduced

7. Add a label of "curated" to the ticket

8. If the ticket is simple enough for someone brand new to OpenMRS, set complexity=low add a label of "intro"

9. If the ticket needs design discussion, then change the status to Needs Design

10. A fixVersion is NOT required. Only bug fixes that look important need to be assigned a fixVersion immediately. Otherwise, the fixVersion will be chosen after a patch as been applied or a developer assigned

11. If a ticket is a general overall project, the ticket type should be moved to be an "Epic" or a "Story"

Tickets to Curate

If the upcoming sprints are well designed, here is a jira dashboard with a list of Needs Assessment tickets on the left (more important) and other non-curated tickets on the right (less important)

https://tickets.openmrs.org/secure/Dashboard.jspa?selectPageId=11950