The goal of issue organization is help team members appraise the work that an issue requires, without having to read it. An open
issue represents a problem that requires work on behalf of the team to solve the problem it describes. Issues that do not describe a specific problem will be closed
, but can (and often should) be used for discussion.
assorted links:
- bundler's labels
- cocoapods issue handling
- npm's repo
- how-is
- https://github.com/rubygems/rubygems/blob/master/CONTRIBUTING.rdoc
Status labels represent the "state" of work on an issue. Status labels will change (sometimes frequently) over the life of an issue. For example, an issue created by an end user might follow this path:
created =>
triage
=>user feedback required
=>triage
=>working / ready
=> closed
An issue created by a team member might follow this path:
created =>
working / ready
=>backlog
=>confirmed
=>working / ready
=> closed
Some of these labels represent when work can be done, specifically
working / ready
=> nowconfirmed
=> in the near futurebacklog
=> in the far future
The "default" label, gets applied when an end user describes a problem whose cause is unknown. triage
issues require a collaboration between developer and end user in order to be resolved. triage
issues move to working / ready
if they require a change with our code, and they are closed if they require a change in the users local setup (ex: permission errors).
Requires more feedback from the an end user. Generally information such as their OS, library versions, how they were using our code, etc. Issues with user feedback required
need a team member to ping to end user 1 - 3 times over the course of days / weeks. If the user does not respond, the issue can be closed.
Ready for work, or already being worked on. Issues usually start with this label when they are created by a team member.
Needs few days / weeks before we can begin work, and move it to working / ready
. This usually means that it requires a feature that will be in the next release.
Needs weeks / several months before we can begin work, and move it to working / ready
. This usually means that it requires large / backwards incompatible changes.
Type labels describe the area of work the needs to be done in order to resolve an issue
A bug that requires a change in our code to solve.
A request for a new feature to be added into our code. May sometimes be hard to distinguish from a bug report.
A question was asked and the issue can be closed when somebody provides an answer
The issue involves updating a readme, wiki, or some other sort of documentation
The issue describes administrative tasks such as: ownership of the code, feature roadmaps, work to be done by the project's managing organization, etc