...
What we use the issue tracker for?
We use the issue tracker:
- for project management purposes
- so people can follow whether and how issues they are interested in are being addressed
- so people can be aware of the work that is ongoing in general
- to record what was included in different releases.
What we DONOT use the issue tracker for?
We do not use the issue tracker for detailed design discussions, because it does not provide a good conversational user experience.
These kinds of discussions should happen in the Discussion Forums. The standard process would be to create a discussion topic with a title like "Design for feature X (BAH-123)" and to link to this from the issue.
How should I write a ticket?
A ticket needs to be actionable by a developer who will start with only a limited understanding of the enhancement or bug fix you are asking for, therefore, in the Description field in the issue tracker, please try to include as many of these sections as you can:
- Context (layperson’s description of what you’re asking for and why it matters, possibly mention an implementation or type of user, or link to a Talk thread)
- Steps to Reproduce (only for bugs; describe exact steps to reproduce it, ideally on the bahmni demo server; if not on the demo server, indicate which Bahmni version and relevant config/data)
- Acceptance Criteria (numbered list of each individual thing that should be developed and tested)
- or else Actual Behavior and Expected Behavior if this makes the ticket clearer in the case of a defect
- Tech Notes (can have both tech approach and any configuration changes that will be introduced as part of the approach)
- Open Questions (if you’re not completely sure how this should work, it’s fine to leave some “open questions”)
- Links, Mockups, etc (obviously if you have these, include them)
- Dev Notes (if you’re a dev, add anything you know that’s relevant to the code)
What do different fields mean?
- Issue Type: (to do)
- Summary: a short description that should be human
- Description: see "How should I write a ticket"
- Fix Version: the Bahmni release that this ticket is scheduled to be fixed in.
- Affects Version: for defects only, which versions of Bahmni the defect has been reproduced in.
- Assignee: during the analysis process, this is the person who is analyzing the ticket. For all states after Ready For Dev, this should be the developer who is currently working on, or completed dev work on the ticket. In other words, if you are doing code review or QA testing, do not make yourself the assignee.
- Dev Pair: if another developer paired with the Assignee on this ticket, record their name here
- Reviewer: the developer who signed off on code review and/or merged the pull request
- UAT Assignee: the person who tested the ticket during our community QA process and confirms it works as expected
As a developer, how do I choose a ticket?
See What To Work On.
How do I indicate that a ticket is a priority?
If an unresolved ticket is important to you, then:
- Vote on it, with the "Vote for this issue" link on the right side of this page
- Ensure that its description is complete enough for a developer to want to work on it. You might want to edit a ticket to match the format given in "How should I write a ticket" above.
While doing these don't guarantee anything, they make it a bit more likely for a developer to pick this ticket over another one.
If you are part of the Product Architecture Team (PAT calls) and you see a ticket that is in line with our specific priorities for upcoming releases, you can set the Fix Version to the appropriate release.
If you have already done the work on a ticket, and you want other devs to prioritize reviewing and merging it, then please mention this on slack or the discussion forum.