github.com/xuyutom/docker@v1.6.0/docs/sources/project/find-an-issue.md (about) 1 page_title: Make a project contribution 2 page_description: Basic workflow for Docker contributions 3 page_keywords: contribute, pull request, review, workflow, beginner, expert, squash, commit 4 5 <style type="text/css"> 6 7 /* GitHub label styles */ 8 .gh-label { 9 display: inline-block; 10 padding: 3px 4px; 11 font-size: 12px; 12 font-weight: bold; 13 line-height: 1; 14 color: #fff; 15 border-radius: 2px; 16 box-shadow: inset 0 -1px 0 rgba(0,0,0,0.12); 17 } 18 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 38 39 </style> 40 41 42 # Find and claim an issue 43 44 On this page, you choose what you want to work on. As a contributor you can work 45 on whatever you want. If you are new to contributing, you should start by 46 working with our known issues. 47 48 ## Understand the issue types 49 50 An existing issue is something reported by a Docker user. As issues come in, 51 our maintainers triage them. Triage is its own topic. For now, it is important 52 for you to know that triage includes ranking issues according to difficulty. 53 54 Triaged issues have one of these labels: 55 56 <table class="tg"> 57 <tr> 58 <td class="tg-031e">Level</td> 59 <td class="tg-031e">Experience level guideline</td> 60 </tr> 61 <tr> 62 <td class="tg-031e"><strong class="gh-label beginner">exp/beginner</strong></td> 63 <td class="tg-031e">You have made less than 10 contributions in your life time to any open source project.</td> 64 </tr> 65 <tr> 66 <td class="tg-031e"><strong class="gh-label novice">exp/novice</strong></td> 67 <td class="tg-031e">You have made more than 10 contributions to an open source project or at least 5 contributions to Docker. </td> 68 </tr> 69 <tr> 70 <td class="tg-031e"><strong class="gh-label proficient">exp/proficient</strong></td> 71 <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> 72 </tr> 73 <tr> 74 <td class="tg-031e"><strong class="gh-label expert">exp/expert</strong></td> 75 <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> 76 </tr> 77 <tr> 78 <td class="tg-031e"><strong class="gh-label master">exp/master</strong></td> 79 <td class="tg-031e">You have made more than 20 commits to Docker and greater than 1000 code lines or 3000 documentation lines.</td> 80 </tr> 81 </table> 82 83 As the table states, these labels are meant as guidelines. You might have 84 written a whole plugin for Docker in a personal project and never contributed to 85 Docker. With that kind of experience, you could take on an <strong 86 class="gh-label expert">exp/expert</strong> or <strong class="gh-label 87 master">exp/master</strong> level task. 88 89 ## Claim a beginner or novice issue 90 91 In this section, you find and claim an open documentation lines issue. 92 93 94 1. Go to the `docker/docker` <a 95 href="https://github.com/docker/docker" target="_blank">repository</a>. 96 97 2. Click on the "Issues" link. 98 99 A list of the open issues appears. 100 101 ![Open issues](/project/images/issue_list.png) 102 103 3. Look for the <strong class="gh-label beginner">exp/beginner</strong> items on the list. 104 105 4. Click on the "labels" dropdown and select <strong class="gh-label beginner">exp/beginner</strong>. 106 107 The system filters to show only open <strong class="gh-label beginner">exp/beginner</strong> issues. 108 109 5. Open an issue that interests you. 110 111 The comments on the issues can tell you both the problem and the potential 112 solution. 113 114 6. Make sure that no other user has chosen to work on the issue. 115 116 We don't allow external contributors to assign issues to themselves. So, you 117 need to read the comments to find if a user claimed the issue by leaving a 118 `#dibs` comment on the issue. 119 120 7. When you find an open issue that both interests you and is unclaimed, add a 121 `#dibs` comment. 122 123 ![Easy issue](/project/images/easy_issue.png) 124 125 This example uses issue 11038. Your issue # will be different depending on 126 what you claimed. After a moment, Gordon the Docker bot, changes the issue 127 status to claimed. 128 129 8. Make a note of the issue number; you'll need it later. 130 131 ## Sync your fork and create a new branch 132 133 If you have followed along in this guide, you forked the `docker/docker` 134 repository. Maybe that was an hour ago or a few days ago. In any case, before 135 you start working on your issue, sync your repository with the upstream 136 `docker/docker` master. Syncing ensures your repository has the latest 137 changes. 138 139 To sync your repository: 140 141 1. Open a terminal on your local host. 142 143 2. Change directory to the `docker-fork` root. 144 145 $ cd ~/repos/docker-fork 146 147 3. Checkout the master branch. 148 149 $ git checkout master 150 Switched to branch 'master' 151 Your branch is up-to-date with 'origin/master'. 152 153 Recall that `origin/master` is a branch on your remote GitHub repository. 154 155 4. Make sure you have the upstream remote `docker/docker` by listing them. 156 157 $ git remote -v 158 origin https://github.com/moxiegirl/docker.git (fetch) 159 origin https://github.com/moxiegirl/docker.git (push) 160 upstream https://github.com/docker/docker.git (fetch) 161 upstream https://github.com/docker/docker.git ( 162 163 If the `upstream` is missing, add it. 164 165 $ git remote add upstream https://github.com/docker/docker.git 166 167 5. Fetch all the changes from the `upstream/master` branch. 168 169 $ git fetch upstream/master 170 remote: Counting objects: 141, done. 171 remote: Compressing objects: 100% (29/29), done. 172 remote: Total 141 (delta 52), reused 46 (delta 46), pack-reused 66 173 Receiving objects: 100% (141/141), 112.43 KiB | 0 bytes/s, done. 174 Resolving deltas: 100% (79/79), done. 175 From github.com:docker/docker 176 9ffdf1e..01d09e4 docs -> upstream/docs 177 05ba127..ac2521b master -> upstream/master 178 179 This command says get all the changes from the `master` branch belonging to 180 the `upstream` remote. 181 182 7. Rebase your local master with the `upstream/master`. 183 184 $ git rebase upstream/master 185 First, rewinding head to replay your work on top of it... 186 Fast-forwarded master to upstream/master. 187 188 This command writes all the commits from the upstream branch into your local 189 branch. 190 191 8. Check the status of your local branch. 192 193 $ git status 194 On branch master 195 Your branch is ahead of 'origin/master' by 38 commits. 196 (use "git push" to publish your local commits) 197 nothing to commit, working directory clean 198 199 Your local repository now has any changes from the `upstream` remote. You 200 need to push the changes to your own remote fork which is `origin/master`. 201 202 9. Push the rebased master to `origin/master`. 203 204 $ git push origin 205 Username for 'https://github.com': moxiegirl 206 Password for 'https://moxiegirl@github.com': 207 Counting objects: 223, done. 208 Compressing objects: 100% (38/38), done. 209 Writing objects: 100% (69/69), 8.76 KiB | 0 bytes/s, done. 210 Total 69 (delta 53), reused 47 (delta 31) 211 To https://github.com/moxiegirl/docker.git 212 8e107a9..5035fa1 master -> master 213 214 9. Create a new feature branch to work on your issue. 215 216 Your branch name should have the format `XXXX-descriptive` where `XXXX` is 217 the issue number you are working on. For example: 218 219 $ git checkout -b 11038-fix-rhel-link 220 Switched to a new branch '11038-fix-rhel-link' 221 222 Your branch should be up-to-date with the upstream/master. Why? Because you 223 branched off a freshly synced master. Let's check this anyway in the next 224 step. 225 226 9. Rebase your branch from upstream/master. 227 228 $ git rebase upstream/master 229 Current branch 11038-fix-rhel-link is up to date. 230 231 At this point, your local branch, your remote repository, and the Docker 232 repository all have identical code. You are ready to make changesfor your 233 issues. 234 235 236 ## Where to go next 237 238 At this point, you know what you want to work on and you have a branch to do 239 your work in. Go onto the next section to learn [how to work on your 240 changes](/project/work-issue/).