Issue handling workflow
Keep the number of open issues under 820
Keep the ratio of open issues per all issues under 13%
Use structured labels of the form
<category>:<label> or if need be
<category>:<main>/<sub>, for example
Use the following labels. Areas and statuses depend on the application and workflow.
status: PR review
status: community working on it
need: more info
need: steps to reproduce
Use these milestones
- Future - Maybe implement one day
- Coming soon - Not assigned to a specific release, but to be delivered in one of the upcoming releases
- <next version> - Next release with a version number
- <next-next version> - The version after the next release with a version number
- <next major release> - Optional.
It’s ok to not set a due date for a milestone, but once you release it, close it. If you have a few issues dangling, consider moving them to the next milestone, and close this one.
Optionally, use a project board to collect issues of a larger effort that has an end state and overarches multiple releases.
We have a weekly or bi-weekly triage meeting. Issues are preselected by labelling them “status:triage” and sorted the oldest ones first. This is when we go through the new issues and do one of the following
- Close it.
- Assign it to “Coming soon” milestone which doesn’t have an end date.
- Move it to the “Future” milestone.
- Change its status to “Need:<what-is-needed>”.
Optional further activities:
- Label the issue with the appropriate area/component.
- Add a section to the FAQ or add a wiki page. Link to it from the issue.