1. docker
  2. Commit 321d94b17e0b23754cb8c5858c11bef554ec8279
Browse code

Expand the contributing guidelines

Jonathan Rudenberg authored on 2013/04/02 01:28:54
Showing 2 changed files
CONTRIBUTING.md
History View file @ 321d94b
... ... 
@@ -49,21 +49,45 @@ help prioritize the most common problems and requests.
49 49
50 50 
 Fork the repo and make changes on your fork in a feature branch:
51 51
52 
-- If it's a bugfix branch, name it XXX-something where XXX is the number of the issue
53 
-- 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.
52 
+- If it's a bugfix branch, name it XXX-something where XXX is the number of the
53 
+  issue
54 
+- If it's a feature branch, create an enhancement issue to announce your
55 
+  intentions, and name it XXX-something where XXX is the number of the issue.
54 56
55 
-Submit unit tests for your changes.  Golang has a great testing suite built
56 
-in: use it! Take a look at existing tests for inspiration. Run the full test
57 
-suite against your change and the master.
57 
+Submit unit tests for your changes.  Go has a great test framework built in; use
58 
+it! Take a look at existing tests for inspiration. Run the full test suite on
59 
+your branch before submitting a pull request.
58 60
59 
-Submit any relevant updates or additions to documentation.
61 
+Make sure you include relevant updates or additions to documentation when
62 
+creating or modifying features.
60 63
61 
-Add clean code:
64 
+Write clean code. Universally formatted code promotes ease of writing, reading,
65 
+and maintenance. Always run `go fmt` before committing your changes. Most
66 
+editors have plugins that do this automatically, and there's also a git
67 
+pre-commit hook:
62 68
63 
-- Universally formatted code promotes ease of writing, reading, and maintenance.  We suggest using gofmt before committing your changes. There's a git pre-commit hook made for doing so.
64 
-- curl -o .git/hooks/pre-commit https://raw.github.com/edsrzf/gofmt-git-hook/master/fmt-check && chmod +x .git/hooks/pre-commit
69 
+```
70 
+curl -o .git/hooks/pre-commit https://raw.github.com/edsrzf/gofmt-git-hook/master/fmt-check && chmod +x .git/hooks/pre-commit
71 
+```
65 72
66 73 
 Pull requests descriptions should be as clear as possible and include a
67 
-referenced to all the issues that they address.
68 
-
69 
-Add your name to the AUTHORS file.
74 
+reference to all the issues that they address.
75 
+
76 
+Code review comments may be added to your pull request. Discuss, then make the
77 
+suggested modifications and push additional commits to your feature branch. Be
78 
+sure to post a comment after pushing. The new commits will show up in the pull
79 
+request automatically, but the reviewers will not be notified unless you
80 
+comment.
81 
+
82 
+Before the pull request is merged, make sure that you squash your commits into
83 
+logical units of work using `git rebase -i` and `git push -f`. After every
84 
+commit the test suite should be passing. Include documentation changes in the
85 
+same commit so that a revert would remove all traces of the feature or fix.
86 
+
87 
+Commits that fix or close an issue should include a reference like `Closes #XXX`
88 
+or `Fixes #XXX`, which will automatically close the issue when merged.
89 
+
90 
+Add your name to the AUTHORS file, but make sure the list is sorted and your
91 
+name and email address match your git configuration. The AUTHORS file is
92 
+regenerated occasionally from the git commit history, so a mismatch may result
93 
+in your changes being overwritten.
docs/sources/contributing/contributing.rst
History View file @ 321d94b
... ... 
@@ -56,21 +56,46 @@ Conventions
56 56
57 57 
 Fork the repo and make changes on your fork in a feature branch:
58 58
59 
-- If it's a bugfix branch, name it XXX-something where XXX is the number of the issue
60 
-- 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.
59 
+- If it's a bugfix branch, name it XXX-something where XXX is the number of the
60 
+  issue
61 
+- If it's a feature branch, create an enhancement issue to announce your
62 
+  intentions, and name it XXX-something where XXX is the number of the issue.
61 63
62 
-Submit unit tests for your changes.  Golang has a great testing suite built
63 
-in: use it! Take a look at existing tests for inspiration. Run the full test
64 
-suite against your change and the master.
64 
+Submit unit tests for your changes.  Go has a great test framework built in; use
65 
+it! Take a look at existing tests for inspiration. Run the full test suite on
66 
+your branch before submitting a pull request.
65 67
66 
-Submit any relevant updates or additions to documentation.
68 
+Make sure you include relevant updates or additions to documentation when
69 
+creating or modifying features.
67 70
68 
-Add clean code:
71 
+Write clean code. Universally formatted code promotes ease of writing, reading,
72 
+and maintenance. Always run ``go fmt`` before committing your changes. Most
73 
+editors have plugins that do this automatically, and there's also a git
74 
+pre-commit hook:
69 75
70 
-- Universally formatted code promotes ease of writing, reading, and maintenance.  We suggest using gofmt before committing your changes. There's a git pre-commit hook made for doing so.
71 
-- curl -o .git/hooks/pre-commit https://raw.github.com/edsrzf/gofmt-git-hook/master/fmt-check && chmod +x .git/hooks/pre-commit
76 
+.. code-block:: bash
77 
+
78 
+    curl -o .git/hooks/pre-commit https://raw.github.com/edsrzf/gofmt-git-hook/master/fmt-check && chmod +x .git/hooks/pre-commit
72 79
73 
-Pull requests descriptions should be as clear as possible and include a
74 
-referenced to all the issues that they address.
75 80
76 
-Add your name to the AUTHORS file.
81 
+Pull requests descriptions should be as clear as possible and include a
82 
+reference to all the issues that they address.
83 
+
84 
+Code review comments may be added to your pull request. Discuss, then make the
85 
+suggested modifications and push additional commits to your feature branch. Be
86 
+sure to post a comment after pushing. The new commits will show up in the pull
87 
+request automatically, but the reviewers will not be notified unless you
88 
+comment.
89 
+
90 
+Before the pull request is merged, make sure that you squash your commits into
91 
+logical units of work using ``git rebase -i`` and ``git push -f``. After every
92 
+commit the test suite should be passing. Include documentation changes in the
93 
+same commit so that a revert would remove all traces of the feature or fix.
94 
+
95 
+Commits that fix or close an issue should include a reference like ``Closes #XXX``
96 
+or ``Fixes #XXX``, which will automatically close the issue when merged.
97 
+
98 
+Add your name to the AUTHORS file, but make sure the list is sorted and your
99 
+name and email address match your git configuration. The AUTHORS file is
100 
+regenerated occasionally from the git commit history, so a mismatch may result
101 
+in your changes being overwritten.