github.com/christopherobin/docker@v1.6.2/docs/sources/project/coding-style.md (about)

     1  page_title: Coding Style Checklist
     2  page_description: List of guidelines for coding Docker contributions
     3  page_keywords: change, commit, squash, request, pull request, test, unit test, integration tests, Go, gofmt, LGTM
     4  
     5  # Coding Style Checklist
     6  
     7  This checklist summarizes the material you experienced working through [make a
     8  code contribution](/project/make-a-contribution) and [advanced
     9  contributing](/project/advanced-contributing). The checklist applies to code
    10  that is program code or code that is documentation code.
    11  
    12  ## Change and commit code
    13  
    14  * Fork the `docker/docker` repository.
    15  
    16  * Make changes on your fork in a feature branch. Name your branch `XXXX-something`
    17    where `XXXX` is the issue number you are working on.
    18  
    19  * Run `gofmt -s -w file.go` on each changed file before
    20    committing your changes. Most editors have plug-ins that do this automatically.
    21  
    22  * Update the documentation when creating or modifying features. 
    23  
    24  * Commits that fix or close an issue should reference them in the commit message
    25    `Closes #XXXX` or `Fixes #XXXX`. Mentions help by automatically closing the
    26    issue on a merge.
    27  
    28  * After every commit, run the test suite and ensure it is passing.
    29  
    30  * Sync and rebase frequently as you code to keep up with `docker` master.
    31  
    32  * Set your `git` signature and make sure you sign each commit.
    33  
    34  * Do not add yourself to the `AUTHORS` file. This file is autogenerated from the
    35    Git history.
    36  
    37  ## Tests and testing
    38  
    39  * Submit unit tests for your changes. 
    40  
    41  * Make use of the builtin Go test framework built. 
    42  
    43  * Use existing Docker test files (`name_test.go`) for inspiration. 
    44  
    45  * Run <a href="../test-and-docs" target="_blank">the full test suite</a> on your
    46    branch before submitting a pull request.
    47  
    48  * Run `make docs` to build the documentation and then check it locally.
    49  
    50  * Use an <a href="http://www.hemingwayapp.com" target="_blank">online grammar
    51    checker</a> or similar to test you documentation changes for clarity,
    52    concision, and correctness.
    53  
    54  ## Pull requests
    55  
    56  * Sync and cleanly rebase on top of Docker's `master` without multiple branches
    57    mixed into the PR.
    58  
    59  * Before the pull request, squash your commits into logical units of work using
    60    `git rebase -i` and `git push -f`. 
    61  
    62  * Include documentation changes in the same commit so that a revert would
    63    remove all traces of the feature or fix.
    64  
    65  * Reference each issue in your pull request description (`#XXXX`)
    66  
    67  ## Respond to pull requests reviews 
    68  
    69  * Docker maintainers use LGTM (**l**ooks-**g**ood-**t**o-**m**e) in PR comments
    70    to indicate acceptance.
    71  
    72  * Code review comments may be added to your pull request. Discuss, then make
    73    the suggested modifications and push additional commits to your feature
    74    branch.
    75  
    76  * Incorporate changes on your feature branch and push to your fork. This
    77    automatically updates your open pull request.
    78  
    79  * Post a comment after pushing to alert reviewers to PR changes; pushing a
    80    change does not send notifications.
    81  
    82  * A change requires LGTMs from an absolute majority maintainers of an
    83    affected component. For example, if you change `docs/` and `registry/` code,
    84    an absolute majority of the `docs/` and the `registry/` maintainers must
    85    approve your PR.
    86  
    87  ## Merges after pull requests
    88  
    89  * After a merge, [a master build](https://master.dockerproject.com/) is
    90    available almost immediately.
    91  
    92  * If you made a documentation change, you can see it at
    93    [docs.master.dockerproject.com](http://docs.master.dockerproject.com/).