diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f461e95303..2e1141c30f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,9 +1,6 @@ # Contributing to Docker -Want to hack on Docker? Awesome! There are instructions to get you -started on the website: http://docker.io/gettingstarted.html - -They are probably not perfect, please let us know if anything feels +Want to hack on Docker? Awesome! Here are instructions to get you started. They are probably not perfect, please let us know if anything feels wrong or incomplete. ## Contribution guidelines diff --git a/docs/sources/contributing/contributing.rst b/docs/sources/contributing/contributing.rst index c2bd7c80fb..25b4df763a 100644 --- a/docs/sources/contributing/contributing.rst +++ b/docs/sources/contributing/contributing.rst @@ -5,101 +5,5 @@ Contributing to Docker ====================== -Want to hack on Docker? Awesome! There are instructions to get you -started on the website: http://docker.io/gettingstarted.html +Want to hack on Docker? Awesome! The repository includes `all the instructions you need to get started `. -They are probably not perfect, please let us know if anything feels -wrong or incomplete. - -Contribution guidelines ------------------------ - -Pull requests are always welcome -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -We are always thrilled to receive pull requests, and do our best to -process them as fast as possible. Not sure if that typo is worth a pull -request? Do it! We will appreciate it. - -If your pull request is not accepted on the first try, don't be -discouraged! If there's a problem with the implementation, hopefully you -received feedback on what to improve. - -We're trying very hard to keep Docker lean and focused. We don't want it -to do everything for everybody. This means that we might decide against -incorporating a new feature. However, there might be a way to implement -that feature *on top of* docker. - -Discuss your design on the mailing list -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -We recommend discussing your plans `on the mailing -list `__ -before starting to code - especially for more ambitious contributions. -This gives other contributors a chance to point you in the right -direction, give feedback on your design, and maybe point out if someone -else is working on the same thing. - -Create issues... -~~~~~~~~~~~~~~~~ - -Any significant improvement should be documented as `a github -issue `__ before anybody -starts working on it. - -...but check for existing issues first! -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Please take a moment to check that an issue doesn't already exist -documenting your bug report or improvement proposal. If it does, it -never hurts to add a quick "+1" or "I have this problem too". This will -help prioritize the most common problems and requests. - -Conventions -~~~~~~~~~~~ - -Fork the repo and make changes on your fork in a feature branch: - -- If it's a bugfix branch, name it XXX-something where XXX is the number of the - issue -- If it's a feature branch, create an enhancement issue to announce your - intentions, and name it XXX-something where XXX is the number of the issue. - -Submit unit tests for your changes. Go has a great test framework built in; use -it! Take a look at existing tests for inspiration. Run the full test suite on -your branch before submitting a pull request. - -Make sure you include relevant updates or additions to documentation when -creating or modifying features. - -Write clean code. Universally formatted code promotes ease of writing, reading, -and maintenance. Always run ``go fmt`` before committing your changes. Most -editors have plugins that do this automatically, and there's also a git -pre-commit hook: - -.. code-block:: bash - - curl -o .git/hooks/pre-commit https://raw.github.com/edsrzf/gofmt-git-hook/master/fmt-check && chmod +x .git/hooks/pre-commit - - -Pull requests descriptions should be as clear as possible and include a -reference to all the issues that they address. - -Code review comments may be added to your pull request. Discuss, then make the -suggested modifications and push additional commits to your feature branch. Be -sure to post a comment after pushing. The new commits will show up in the pull -request automatically, but the reviewers will not be notified unless you -comment. - -Before the pull request is merged, make sure that you squash your commits into -logical units of work using ``git rebase -i`` and ``git push -f``. After every -commit the test suite should be passing. Include documentation changes in the -same commit so that a revert would remove all traces of the feature or fix. - -Commits that fix or close an issue should include a reference like ``Closes #XXX`` -or ``Fixes #XXX``, which will automatically close the issue when merged. - -Add your name to the AUTHORS file, but make sure the list is sorted and your -name and email address match your git configuration. The AUTHORS file is -regenerated occasionally from the git commit history, so a mismatch may result -in your changes being overwritten.