Issue handling workflow

(Draft proposal)

Keep the number of open issues under 820

Keep the ratio of open issues per all issues under 13%

Have 50 issues labelled help wanted and 50 good first issue.

Use structured labels of the form <category>:<label> or if need be <category>:<main>/<sub>, for example area: plugins/foobuzzer.

Use the following labels. Areas and statuses depend on the application and workflow.

  • area
    • area: android
    • area: clef
    • area: network
    • area: swarm
    • area: whisper
  • type
    • type: bug
    • type: feature
    • type: documentation
    • type: discussion
  • status
    • status: PR review
    • status: community working on it
  • need
    • need: more info
    • need: steps to reproduce
    • need: investigation
    • need: decision

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.

Workflow

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

  1. Close it.
  2. Assign it to “Coming soon” milestone which doesn’t have an end date.
  3. Move it to the “Future” milestone.
  4. 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.