kotovalexarian-likes-github/moby--moby
1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00
Code Releases Activity

Merge pull request #14719 from icecrime/14662_update_issue_triage

Browse source 
Update issue triaging process
This commit is contained in:
Arnaud Porterie 2015-08-07 14:37:31 -07:00
commit 4f349cdd4b
1 changed files with 38 additions and 50 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

86
project/ISSUE-TRIAGE.md
View file

@ -4,16 +4,13 @@ Triaging of issues
Triage provides an important way to contribute to an open source project. Triage helps ensure issues resolve quickly by: Triage provides an important way to contribute to an open source project. Triage helps ensure issues resolve quickly by:
- Describing the issue's intent and purpose is conveyed precisely. This is necessary because it can be difficult for an issue to explain how an end user experiences an problem and what actions they took. - Describing the issue's intent and purpose is conveyed precisely. This is necessary because it can be difficult for an issue to explain how an end user experiences an problem and what actions they took.
- Giving a contributor the information they need before they commit to resolving an issue. - Giving a contributor the information they need before they commit to resolving an issue.
- Lowering the issue count by preventing duplicate issues. - Lowering the issue count by preventing duplicate issues.
- Streamlining the development process by preventing duplicate discussions. - Streamlining the development process by preventing duplicate discussions.
If you don't have time to code, consider helping with triage. The community will thank you for saving them time by spending some of yours. If you don't have time to code, consider helping with triage. The community will thank you for saving them time by spending some of yours.
### Step 1: Ensure the issue contains basic information ### 1. Ensure the issue contains basic information
Before triaging an issue very far, make sure that the issue's author provided the standard issue information. This will help you make an educated recommendation on how this to categorize the issue. Standard information that *must* be included in most issues are things such as: Before triaging an issue very far, make sure that the issue's author provided the standard issue information. This will help you make an educated recommendation on how this to categorize the issue. Standard information that *must* be included in most issues are things such as:
@ -31,74 +28,65 @@ If the author provides the standard information but you are still unable to tria
If the author does not respond requested information within the timespan of a week, close the issue with a kind note stating that the author can request for the issue to be If the author does not respond requested information within the timespan of a week, close the issue with a kind note stating that the author can request for the issue to be
reopened when the necessary information is provided. reopened when the necessary information is provided.
### Step 2: Apply the template ### 2. Classify the Issue
When triaging, use the standard template below. You should cut and place the template in the issue's description. An issue can have multiple of the following labels.
The template helps other reviewers find key information in an issue. For example, using a template saves a
potential contributor from wading though 100s of comments to find a proposed solution at the very end. When adding
the template to the issue's description also add any required labels to the issue for the classification and difficulty.
Here is a sample summary for an [issue](https://github.com/docker/docker/issues/10545). #### Issue kind
```
**Summary**: docker rm can return a non-zero exit code if the container does not
exist and it is not easy to parse the error message.
**Proposed solution**:
docker rm should have consistent exit codes for different types of errors so
that the user can easily script and know the reason why the command failed.
```
### Step 3: Classify the Issue
Classifications help both to inform readers about an issue's priority and how to resolve it.
This is also helpful for identifying new, critical issues. "Kinds of" are
applied to the issue or pull request using labels. You can apply one or more labels.
Kinds of classifications:
| Kind | Description | | Kind | Description |
|------------------|---------------------------------------------------------------------------------------------------------------------------------| |------------------|---------------------------------------------------------------------------------------------------------------------------------|
| kind/enhancement | Enhancement are not bugs or new features but can drastically improve usability or performance of a project component. |
| kind/cleanup | Refactoring code or otherwise clarifying documentation. |
| kind/content | Content that is not documentation such as help or error messages. |
| kind/graphics | Work involving graphics skill |
| kind/regression | Regressions are usually easy fixes as hopefully the action worked previously and git history can be used to propose a solution. |
| kind/bug | Bugs are bugs. The cause may or may not be known at triage time so debugging should be taken account into the time estimate. | | kind/bug | Bugs are bugs. The cause may or may not be known at triage time so debugging should be taken account into the time estimate. |
| kind/docs | Writing documentation, man pages, articles, blogs, or other significant word-driven task. |
| kind/enhancement | Enhancement are not bugs or new features but can drastically improve usability or performance of a project component. |
| kind/feature | Functionality or other elements that the project does not currently support. Features are new and shinny. | | kind/feature | Functionality or other elements that the project does not currently support. Features are new and shinny. |
| kind/question | Contains a user or contributor question requiring a response. | | kind/question | Contains a user or contributor question requiring a response. |
| kind/usecase | A description of a user or contributor situation requiring a response perhaps in code or documentation. |
| kind/writing | Writing documentation, man pages, articles, blogs, or other significant word-driven task. |
| kind/test | Tests or test infrastructure needs adding or updating. |
#### Functional area
Contributors can add labels by using a `+kind/bug` in an issue or pull request comment. | Area |
|---------------------------|
| area/api |
| area/builder |
| area/cli |
| area/kernel |
| area/runtime |
| area/storage |
| area/storage/aufs |
| area/storage/btrfs |
| area/storage/devicemapper |
| area/storage/overlay |
| area/storage/zfs |
### Step 4: Estimate the experience level required #### Experience level
Experience level is a way for a contributor to find an issue based on their Experience level is a way for a contributor to find an issue based on their
skill set. Experience types are applied to the issue or pull request using skill set. Experience types are applied to the issue or pull request using
labels. labels.
| Level | Experience level guideline | | Level | Experience level guideline |
|------------------|--------------------------------------------------------------------------------------------------------------------------| |------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| exp/beginner | You have made less than 10 contributions in your life time to any open source project. | | exp/beginner | New to Docker, and possibly Golang, and is looking to help while learning the basics. |
| exp/novice | You have made more than 10 contributions to an open source project or at least 5 contributions to Docker. | | exp/intermediate | Comfortable with golang and understands the core concepts of Docker and looking to dive deeper into the project. |
| exp/proficient | You have made more than 5 contributions to Docker which amount to at least 200 code lines or 1000 documentation lines. | | exp/expert | Proficient with Docker and Golang and has been following, and active in, the community to understand the rationale behind design decisions and where the project is headed. |
| exp/expert | You have made less than 20 commits to Docker which amount to 500-1000 code lines or 1000-3000 documentation lines. |
| exp/master | You have made more than 20 commits to Docker and greater than 1000 code lines or 3000 documentation lines. |
As the table states, these labels are meant as guidelines. You might have As the table states, these labels are meant as guidelines. You might have
written a whole plugin for Docker in a personal project and never contributed to written a whole plugin for Docker in a personal project and never contributed to
Docker. With that kind of experience, you could take on an <strong Docker. With that kind of experience, you could take on an <strong
class="gh-label expert">exp/expert</strong> or <strong class="gh-label class="gh-label expert">exp/expert</strong> level task.
master">exp/master</strong> level task.
Contributors can add labels by using a `+exp/expert` format in issue comment. ### 3. Prioritizing issue
When attached to a specific milestone, an issue can be attributed one of the
following labels to indicate their degree of priority (from more urgent to less
urgent).
| Priority | Description |
|-------------|-----------------------------------------------------------------------------------------------------------------------------------|
| priority/P0 | Urgent: Security, critical bugs, blocking issues. P0 basically means drop everything you are doing until this issue is addressed. |
| priority/P1 | Important: P1 issues are a top priority and a must-have for the next release. |
| priority/P2 | Normal priority: default priority applied. |
| priority/P3 | Best effort: those are nice to have / minor issues. |
And that's it. That should be all the information required for a new or existing contributor to come in an resolve an issue. And that's it. That should be all the information required for a new or existing contributor to come in an resolve an issue.