github.com/circular-dark/docker@v1.7.0/docs/project/coding-style.md (about)

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