2.4 KiB
title | description |
---|---|
Issue Handling Workflow | Instructions for managing GitHub issues |
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 examplearea: 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
The Geth core team hold a weekly or bi-weekly triage meeting. Issues are preselected by labelling them "status:triage" and sorted the oldest ones first. This is when the team goes 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.