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/sources/project/coding-style.md
Sebastiaan van Stijn efc625fcd0 Cleanup: new project docs fix-ups (alternative) 
This cleans up the recently added project docs and
fixes some minor issues.

- remove inline styles where possible
- add redirects for renamed/replaced documents
- add styles for GitHub labels to match the style on GitHub
- fix minor markdown issues causing some code-blocks
  to be shown as text
- wrap the documents to 80-chars
- use 4 spaces in stead of tabs for identing and remove
  trailing whitespace/redundant blank lines
- optimized 'gordon' image

NOTE:
This alternative commit/PR re-introduces some inline
styles because the docs/base image has not yet been
updated for the current docs.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2015-03-07 23:40:34 +01:00

3.4 KiB
Raw Blame History

page_title: Coding Style Checklist page_description: List of guidelines for coding Docker contributions page_keywords: change, commit, squash, request, pull request, test, unit test, integration tests, Go, gofmt, LGTM

Coding Style Checklist

This checklist summarizes the material you experienced working through make a code contribution and advanced contributing. The checklist applies to code that is program code or code that is 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.

  • 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