kotovalexarian-likes-github/moby--moby
1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00
Code Releases Activity
moby--moby/docs/project/coding-style.md
Mary Anthony 8fee1c2020 Enabled GitHub Flavored Markdown 
GitHub flavored markdown is now supported for links and images. Also, ran LinkChecker and FileResolver. Yay!
Fixes from Spider check
Output for docker/docker now goes into engine directory

Signed-off-by: Mary Anthony <mary@docker.com>
2015-10-11 07:49:54 -07:00

3.5 KiB
Raw Blame History

Coding style checklist

This checklist summarizes the material you experienced working through make a code contribution and advanced contributing. The checklist applies to both program code and documentation code.

Change and commit code

  • Fork the docker/docker repository.

  • Make changes on your fork in a feature branch. Name your branch XXXX-something where XXXX is the issue number you are working on.

  • Run gofmt -s -w file.go on each changed file before committing your changes. Most editors have plug-ins that do this automatically.

  • Run golint on each changed file before committing your changes.

  • Update the documentation when creating or modifying features.

  • Commits that fix or close an issue should reference them in the commit message Closes #XXXX or Fixes #XXXX. Mentions help by automatically closing the issue on a merge.

  • After every commit, run the test suite and ensure it is passing.

  • Sync and rebase frequently as you code to keep up with docker master.

  • Set your git signature and make sure you sign each commit.

  • Do not add yourself to the AUTHORS file. This file is autogenerated from the Git history.

Tests and testing

  • Submit unit tests for your changes.

  • Make use of the builtin Go test framework built.

  • Use existing Docker test files (name_test.go) for inspiration.

  • Run the full test suite on your branch before submitting a pull request.

  • Run make docs to build the documentation and then check it locally.

  • Use an online grammar checker or similar to test you documentation changes for clarity, concision, and correctness.

Pull requests

  • Sync and cleanly rebase on top of Docker's master without multiple branches mixed into the PR.

  • Before the pull request, squash your commits into logical units of work using git rebase -i and git push -f.

  • Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.

  • Reference each issue in your pull request description (#XXXX)

Respond to pull requests reviews

  • Docker maintainers use LGTM (looks-good-to-me) in PR comments to indicate acceptance.

  • Code review comments may be added to your pull request. Discuss, then make the suggested modifications and push additional commits to your feature branch.

  • Incorporate changes on your feature branch and push to your fork. This automatically updates your open pull request.

  • Post a comment after pushing to alert reviewers to PR changes; pushing a change does not send notifications.

  • A change requires LGTMs from an absolute majority maintainers of an affected component. For example, if you change docs/ and registry/ code, an absolute majority of the docs/ and the registry/ maintainers must approve your PR.

Merges after pull requests