github.com/xuyutom/docker@v1.6.0/docs/sources/project/review-pr.md (about) 1 page_title: Participate in the PR Review 2 page_description: Basic workflow for Docker contributions 3 page_keywords: contribute, pull request, review, workflow, beginner, squash, commit 4 5 6 # Participate in the PR Review 7 8 Creating a pull request is nearly the end of the contribution process. At this 9 point, your code is reviewed both by our continuous integration (CI) systems and 10 by our maintainers. 11 12 The CI system is an automated system. The maintainers are human beings that also 13 work on Docker. You need to understand and work with both the "bots" and the 14 "beings" to review your contribution. 15 16 17 ## How we proces your review 18 19 First to review your pull request is Gordon. Gordon is fast. He checks your 20 pull request (PR) for common problems like a missing signature. If Gordon finds a 21 problem, he'll send an email through your GitHub user account: 22 23 ![Gordon](/project/images/gordon.jpeg) 24 25 Our build bot system starts building your changes while Gordon sends any emails. 26 27 The build system double-checks your work by compiling your code with Docker's master 28 code. Building includes running the same tests you ran locally. If you forgot 29 to run tests or missed something in fixing problems, the automated build is our 30 safety check. 31 32 After Gordon and the bots, the "beings" review your work. Docker maintainers look 33 at your pull request and comment on it. The shortest comment you might see is 34 `LGTM` which means **l**ooks-**g**ood-**t**o-**m**e. If you get an `LGTM`, that 35 is a good thing, you passed that review. 36 37 For complex changes, maintainers may ask you questions or ask you to change 38 something about your submission. All maintainer comments on a PR go to the 39 email address associated with your GitHub account. Any GitHub user who 40 "participates" in a PR receives an email to. Participating means creating or 41 commenting on a PR. 42 43 Our maintainers are very experienced Docker users and open source contributors. 44 So, they value your time and will try to work efficiently with you by keeping 45 their comments specific and brief. If they ask you to make a change, you'll 46 need to update your pull request with additional changes. 47 48 ## Update an Existing Pull Request 49 50 To update your existing pull request: 51 52 1. Change one or more files in your local `docker-fork` repository. 53 54 2. Commit the change with the `git commit --amend` command. 55 56 $ git commit --amend 57 58 Git opens an editor containing your last commit message. 59 60 3. Adjust your last comment to reflect this new change. 61 62 Added a new sentence per Anaud's suggestion 63 64 Signed-off-by: Mary Anthony <mary@docker.com> 65 66 # Please enter the commit message for your changes. Lines starting 67 # with '#' will be ignored, and an empty message aborts the commit. 68 # On branch 11038-fix-rhel-link 69 # Your branch is up-to-date with 'origin/11038-fix-rhel-link'. 70 # 71 # Changes to be committed: 72 # modified: docs/sources/installation/mac.md 73 # modified: docs/sources/installation/rhel.md 74 75 4. Push to your origin. 76 77 $ git push origin 78 79 5. Open your browser to your pull request on GitHub. 80 81 You should see your pull request now contains your newly pushed code. 82 83 6. Add a comment to your pull request. 84 85 GitHub only notifies PR participants when you comment. For example, you can 86 mention that you updated your PR. Your comment alerts the maintainers that 87 you made an update. 88 89 A change requires LGTMs from an absolute majority of an affected component's 90 maintainers. For example, if you change `docs/` and `registry/` code, an 91 absolute majority of the `docs/` and the `registry/` maintainers must approve 92 your PR. Once you get approval, we merge your pull request into Docker's 93 `master` code branch. 94 95 ## After the merge 96 97 It can take time to see a merged pull request in Docker's official release. 98 A master build is available almost immediately though. Docker builds and 99 updates its development binaries after each merge to `master`. 100 101 1. Browse to <a href="https://master.dockerproject.com/" target="_blank">https://master.dockerproject.com/</a>. 102 103 2. Look for the binary appropriate to your system. 104 105 3. Download and run the binary. 106 107 You might want to run the binary in a container though. This 108 will keep your local host environment clean. 109 110 4. View any documentation changes at <a href="http://docs.master.dockerproject.com/" target="_blank">docs.master.dockerproject.com</a>. 111 112 Once you've verified everything merged, feel free to delete your feature branch 113 from your fork. For information on how to do this, 114 <a href="https://help.github.com/articles/deleting-unused-branches/" target="_blank"> 115 see the GitHub help on deleting branches</a>. 116 117 ## Where to go next 118 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 beginner 121 issue or two. We really appreciate the help. 122 123 If you are very experienced and want to make a major change, go on to 124 [learn about advanced contributing](/project/advanced-contributing).