Browse code

Update contributor docs and triage to match new labeling system Add clarification around experience Adding test improvement > enhancement

Signed-off-by: Mary Anthony <mary@docker.com>

Mary Anthony authored on 2015/03/22 07:30:29
Showing 7 changed files
... ...
@@ -1,6 +1,6 @@
1 1
 page_title: Create a pull request (PR)
2 2
 page_description: Basic workflow for Docker contributions
3
-page_keywords: contribute, pull request, review, workflow, white-belt, black-belt, squash, commit
3
+page_keywords: contribute, pull request, review, workflow, beginner, squash, commit
4 4
 
5 5
 # Create a pull request (PR)
6 6
 
... ...
@@ -1,6 +1,6 @@
1 1
 page_title: Make a project contribution
2 2
 page_description: Basic workflow for Docker contributions
3
-page_keywords: contribute, pull request, review, workflow, white-belt, black-belt, squash, commit
3
+page_keywords: contribute, pull request, review, workflow, beginner, expert, squash, commit
4 4
 
5 5
 <style type="text/css">
6 6
 
... ...
@@ -8,7 +8,7 @@ page_keywords: contribute, pull request, review, workflow, white-belt, black-bel
8 8
 .gh-label {
9 9
     display: inline-block;
10 10
     padding: 3px 4px;
11
-    font-size: 11px;
11
+    font-size: 12px;
12 12
     font-weight: bold;
13 13
     line-height: 1;
14 14
     color: #fff;
... ...
@@ -16,11 +16,25 @@ page_keywords: contribute, pull request, review, workflow, white-belt, black-bel
16 16
     box-shadow: inset 0 -1px 0 rgba(0,0,0,0.12);
17 17
 }
18 18
 
19
-.gh-label.black-belt  { background-color: #000000; color: #ffffff; }
20
-.gh-label.bug         { background-color: #fc2929; color: #ffffff; }
21
-.gh-label.improvement { background-color: #bfe5bf; color: #2a332a; }
22
-.gh-label.project-doc { background-color: #207de5; color: #ffffff; }
23
-.gh-label.white-belt  { background-color: #ffffff; color: #333333; }
19
+/* Experience */
20
+.gh-label.beginner  { background-color: #B5E0B5; color: #333333; }
21
+.gh-label.expert  { background-color: #599898; color: #ffffff; }
22
+.gh-label.master { background-color: #306481; color: #ffffff; }
23
+.gh-label.novice { background-color: #D6F2AC; color: #333333; }
24
+.gh-label.proficient { background-color: #8DC7A9; color: #333333; }
25
+
26
+/* Kind */
27
+.gh-label.bug { background-color: #FF9DA4; color: #333333; }
28
+.gh-label.cleanup { background-color: #FFB7B3; color: #333333; }
29
+.gh-label.content { background-color: #CDD3C2; color: #333333; }
30
+.gh-label.feature { background-color: #B7BEB7; color: #333333; }
31
+.gh-label.graphics { background-color: #E1EFCB; color: #333333; }
32
+.gh-label.improvement { background-color: #EBD2BB; color: #333333; }
33
+.gh-label.proposal { background-color: #FFD9C0; color: #333333; }
34
+.gh-label.question { background-color: #EEF1D1; color: #333333; }
35
+.gh-label.usecase { background-color: #F0E4C2; color: #333333; }
36
+.gh-label.writing { background-color: #B5E9D5; color: #333333; }
37
+
24 38
 
25 39
 </style>
26 40
 
... ...
@@ -37,20 +51,44 @@ An existing issue is something reported by a Docker user. As issues come in,
37 37
 our maintainers triage them. Triage is its own topic. For now, it is important
38 38
 for you to know that triage includes ranking issues according to difficulty. 
39 39
 
40
-Triaged issues have either a <strong class="gh-label white-belt">white-belt</strong> 
41
-or <strong class="gh-label black-belt">black-belt</strong> label.
42
-A <strong class="gh-label white-belt">white-belt</strong> issue is considered
43
-an easier issue. Issues can have more than one label, for example, 
44
-<strong class="gh-label bug">bug</strong>, 
45
-<strong class="gh-label improvement">improvement</strong>, 
46
-<strong class="gh-label project-doc">project/doc</strong>, and so forth. 
47
-These other labels are there for filtering purposes but you might also find
48
-them helpful.
49
-
50
-
51
-## Claim a white-belt issue
52
-
53
-In this section, you find and claim an open white-belt issue.
40
+Triaged issues have one of these labels:
41
+
42
+<table class="tg">
43
+  <tr>
44
+    <td class="tg-031e">Level</td>
45
+    <td class="tg-031e">Experience level guideline</td>
46
+  </tr>
47
+  <tr>
48
+    <td class="tg-031e"><strong class="gh-label beginner">exp/beginner</strong></td>
49
+    <td class="tg-031e">You have made less than 10 contributions in your life time to any open source project.</td>
50
+  </tr>
51
+  <tr>
52
+    <td class="tg-031e"><strong class="gh-label novice">exp/novice</strong></td>
53
+    <td class="tg-031e">You have made more than 10 contributions to an open source project or at least 5 contributions to Docker.  </td>
54
+  </tr>
55
+  <tr>
56
+    <td class="tg-031e"><strong class="gh-label proficient">exp/proficient</strong></td>
57
+    <td class="tg-031e">You have made more than 5 contributions to Docker which amount to at least 200 code lines or 1000 documentation lines. </td>
58
+  </tr>
59
+  <tr>
60
+    <td class="tg-031e"><strong class="gh-label expert">exp/expert</strong></td>
61
+    <td class="tg-031e">You have made less than 20 commits to Docker which amount to 500-1000 code lines or 1000-3000 documentation lines. </td>
62
+  </tr>
63
+  <tr>
64
+    <td class="tg-031e"><strong class="gh-label master">exp/master</strong></td>
65
+    <td class="tg-031e">You have made more than 20 commits to Docker and greater than 1000 code lines or 3000 documentation lines.</td>
66
+  </tr>
67
+</table>
68
+
69
+As the table states, these labels are meant as guidelines. You might have
70
+written a whole plugin for Docker in a personal project and never contributed to
71
+Docker. With that kind of experience, you could take on an <strong
72
+class="gh-label expert">exp/expert</strong> or <strong class="gh-label
73
+master">exp/master</strong> level task.
74
+
75
+## Claim a beginner or novice issue
76
+
77
+In this section, you find and claim an open documentation lines issue.
54 78
 
55 79
 
56 80
 1. Go to the `docker/docker` <a
... ...
@@ -62,11 +100,11 @@ In this section, you find and claim an open white-belt issue.
62 62
 
63 63
     ![Open issues](/project/images/issue_list.png)
64 64
 
65
-3. Look for the <strong class="gh-label white-belt">white-belt</strong> items on the list.
65
+3. Look for the <strong class="gh-label beginner">exp/beginner</strong> items on the list.
66 66
 
67
-4. Click on the "labels" dropdown and select  <strong class="gh-label white-belt">white-belt</strong>.
67
+4. Click on the "labels" dropdown and select  <strong class="gh-label beginner">exp/beginner</strong>.
68 68
 
69
-    The system filters to show only open <strong class="gh-label white-belt">white-belt</strong> issues.
69
+    The system filters to show only open <strong class="gh-label beginner">exp/beginner</strong> issues.
70 70
 
71 71
 5. Open an issue that interests you.
72 72
 
... ...
@@ -75,21 +113,18 @@ In this section, you find and claim an open white-belt issue.
75 75
 
76 76
 6. Make sure that no other user has chosen to work on the issue.
77 77
 
78
-    We don't allow external contributors to assign issues to themselves, so you
79
-    need to read the comments to find if a user claimed an issue by saying:
80
-    
81
-    - "I'd love to give this a try~"
82
-    - "I'll work on this!"
83
-    - "I'll take this."
84
-    
85
-    The community is very good about claiming issues explicitly.
78
+    We don't allow external contributors to assign issues to themselves. So, you
79
+    need to read the comments to find if a user claimed the issue by leaving a
80
+    `#dibs` comment on the issue.  
86 81
 
87
-7. When you find an open issue that both interests you and is unclaimed, claim it yourself by adding a comment.
82
+7. When you find an open issue that both interests you and is unclaimed, add a
83
+`#dibs` comment.
88 84
 
89 85
     ![Easy issue](/project/images/easy_issue.png)
90 86
 
91 87
     This example uses issue 11038. Your issue # will be different depending on
92
-    what you claimed.
88
+   what you claimed.  After a moment, Gordon the Docker bot, changes the issue
89
+   status to claimed.
93 90
 
94 91
 8. Make a note of the issue number; you'll need it later.
95 92
 
96 93
Binary files a/docs/sources/project/images/easy_issue.png and b/docs/sources/project/images/easy_issue.png differ
... ...
@@ -16,7 +16,7 @@ process simple so you'll want to contribute frequently.
16 16
 ## The basic contribution workflow
17 17
 
18 18
 In this guide, you work through Docker's basic contribution workflow by fixing a
19
-single *white-belt* issue in the `docker/docker` repository. The workflow
19
+single *beginner* issue in the `docker/docker` repository. The workflow
20 20
 for fixing simple issues looks like this:
21 21
 
22 22
 ![Simple process](/project/images/existing_issue.png)
... ...
@@ -1,6 +1,6 @@
1 1
 page_title: Participate in the PR Review
2 2
 page_description: Basic workflow for Docker contributions
3
-page_keywords: contribute, pull request, review, workflow, white-belt, black-belt, squash, commit
3
+page_keywords: contribute, pull request, review, workflow, beginner, squash, commit
4 4
 
5 5
 
6 6
 # Participate in the PR Review
... ...
@@ -117,8 +117,7 @@ see the GitHub help on deleting branches</a>.
117 117
 ## Where to go next
118 118
 
119 119
 At this point, you have completed all the basic tasks in our contributors guide.
120
-If you enjoyed contributing, let us know by completing another 
121
-<strong class="gh-label white-belt">white-belt</strong>
120
+If you enjoyed contributing, let us know by completing another beginner
122 121
 issue or two. We really appreciate the help. 
123 122
 
124 123
 If you are very experienced and want to make a major change, go on to 
... ...
@@ -1,6 +1,6 @@
1 1
 page_title: Work on your issue
2 2
 page_description: Basic workflow for Docker contributions
3
-page_keywords: contribute, pull request, review, workflow, white-belt, black-belt, squash, commit
3
+page_keywords: contribute, pull request, review, workflow, beginner, squash, commit
4 4
 
5 5
 
6 6
 # Work on your issue
... ...
@@ -54,30 +54,51 @@ that the user can easily script and know the reason why the command failed.
54 54
 ### Step 3: Classify the Issue
55 55
 
56 56
 Classifications help both to inform readers about an issue's priority and how to resolve it.
57
-This is also helpful for identifying new, critical issues.  Classifications types are
58
-applied to the issue or pull request using labels.
57
+This is also helpful for identifying new, critical issues.  "Kinds of" are
58
+applied to the issue or pull request using labels.  You can apply one or more labels.
59 59
 
60 60
 
61
-Types of classification:
61
+Kinds of classifications:
62 62
 
63
-| Type        | Description                                                                                                                     |
64
-|-------------|---------------------------------------------------------------------------------------------------------------------------------|
65
-| improvement | improvements are not bugs or new features but can drastically improve usability.                                                |
66
-| regression  | regressions are usually easy fixes as hopefully the action worked previously and git history can be used to propose a solution. |
67
-| 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.    |
68
-| feature     | features are new and shinny. They are things that the project does not currently support.                                       |
63
+| Kind             | Description                                                                                                                     |
64
+|------------------|---------------------------------------------------------------------------------------------------------------------------------|
65
+| kind/enhancement | Enhancement are not bugs or new features but can drastically improve usability or performance of a project component.           |
66
+| kind/cleanup     | Refactoring code or otherwise clarifying documentation.                                                                         |
67
+| kind/content     | Content that is not documentation such as help or error messages.                                                               |
68
+| kind/graphics    | Work involving graphics skill                                                                                                   |
69
+| kind/regression  | Regressions are usually easy fixes as hopefully the action worked previously and git history can be used to propose a solution. |
70
+| 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.    |
71
+| kind/feature     | Functionality or other elements that the project does not currently support.  Features are new and shinny.                      |
72
+| kind/question    | Contains a user or contributor question requiring a response.                                                                   |
73
+| kind/usecase     | A description of a user or contributor situation requiring a response perhaps in code or documentation.                         |
74
+| kind/writing     | Writing documentation, man pages, articles, blogs, or other significant word-driven task.                                       |
75
+| kind/test        | Tests or test infrastructure needs adding or updating.                                                                                                 |
69 76
 
70
-### Step 4: Estimate the Difficulty
71 77
 
72
-Difficulty is a way for a contributor to find an issue based on their skill set.  Difficulty types are
73
-applied to the issue or pull request using labels.
78
+Contributors can add labels by using a `+kind/bug` in an issue or pull request comment.  
74 79
 
75
-Difficulty
80
+### Step 4: Estimate the experience level required
81
+
82
+Experience level is a way for a contributor to find an issue based on their
83
+skill set.  Experience types are applied to the issue or pull request using
84
+labels.
85
+
86
+| Level            | Experience level guideline                                                                                               |
87
+|------------------|--------------------------------------------------------------------------------------------------------------------------|
88
+| exp/beginner     | You have made less than 10 contributions in your life time to any open source project.                                   |
89
+| exp/novice       | You have made more than 10 contributions to an open source project or at least 5 contributions to Docker.                | 
90
+| exp/proficient   | You have made more than 5 contributions to Docker which amount to at least 200 code lines or 1000 documentation lines.   | 
91
+| exp/expert       | You have made less than 20 commits to Docker which amount to 500-1000 code lines or 1000-3000 documentation lines.       | 
92
+| exp/master       | You have made more than 20 commits to Docker and greater than 1000 code lines or 3000 documentation lines.               | 
93
+
94
+As the table states, these labels are meant as guidelines. You might have
95
+written a whole plugin for Docker in a personal project and never contributed to
96
+Docker. With that kind of experience, you could take on an <strong
97
+class="gh-label expert">exp/expert</strong> or <strong class="gh-label
98
+master">exp/master</strong> level task.
99
+
100
+Contributors can add labels by using a `+exp/expert` format in issue comment.
76 101
 
77
-| Type         | Description                                                                 |
78
-|--------------|-----------------------------------------------------------------------------|
79
-| white-belt   | Simple, non-time consuming issue, easy first task to accomplish             |
80
-| black-belt   | Expert at the subject matter or someone who likes pain                      | 
81 102
 
82 103
 And that's it. That should be all the information required for a new or existing contributor to come in an resolve an issue.
83 104