1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00

Minor updates and fixes to the CONTRIBUTING doc

* Fixed some uses of docker v. Docker
* Formatting and line wrapping.
* Spelling errors and grammar fixes.

Docker-DCO-1.1-Signed-off-by: James Turnbull <james@lovedthanlost.net> (github: jamtur01)
This commit is contained in:
James Turnbull 2014-06-29 18:01:11 -04:00
parent 6eda9f3207
commit d013b76e10

View file

@ -6,12 +6,17 @@ feels wrong or incomplete.
## Reporting Issues ## Reporting Issues
When reporting [issues](https://github.com/dotcloud/docker/issues) When reporting [issues](https://github.com/dotcloud/docker/issues) on
on GitHub please include your host OS (Ubuntu 12.04, Fedora 19, etc), GitHub please include your host OS (Ubuntu 12.04, Fedora 19, etc).
the output of `uname -a` and the output of `docker version` along with Please include:
the output of `docker -D info`. Please include the steps required to reproduce
the problem if possible and applicable. * The output of `uname -a`.
This information will help us review and fix your issue faster. * The output of `docker version`.
* The output of `docker -D info`.
Please also include the steps required to reproduce the problem if
possible and applicable. This information will help us review and fix
your issue faster.
## Build Environment ## Build Environment
@ -34,7 +39,7 @@ received feedback on what to improve.
We're trying very hard to keep Docker lean and focused. We don't want it 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 to do everything for everybody. This means that we might decide against
incorporating a new feature. However, there might be a way to implement incorporating a new feature. However, there might be a way to implement
that feature *on top of* docker. that feature *on top of* Docker.
### Discuss your design on the mailing list ### Discuss your design on the mailing list
@ -60,12 +65,12 @@ help prioritize the most common problems and requests.
### Conventions ### Conventions
Fork the repo and make changes on your fork in a feature branch: Fork the repository 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 - If it's a bug fix branch, name it XXXX-something where XXXX is the number of the
issue issue.
- If it's a feature branch, create an enhancement issue to announce your - 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. intentions, and name it XXXX-something where XXXX is the number of the issue.
Submit unit tests for your changes. Go has a great test framework built in; use 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 it! Take a look at existing tests for inspiration. Run the full test suite on
@ -73,12 +78,12 @@ your branch before submitting a pull request.
Update the documentation when creating or modifying features. Test Update the documentation when creating or modifying features. Test
your documentation changes for clarity, concision, and correctness, as your documentation changes for clarity, concision, and correctness, as
well as a clean documentation build. See ``docs/README.md`` for more well as a clean documentation build. See `docs/README.md` for more
information on building the docs and how docs get released. information on building the docs and how they get released.
Write clean code. Universally formatted code promotes ease of writing, reading, Write clean code. Universally formatted code promotes ease of writing, reading,
and maintenance. Always run `gofmt -s -w file.go` on each changed file before and maintenance. Always run `gofmt -s -w file.go` on each changed file before
committing your changes. Most editors have plugins that do this automatically. committing your changes. Most editors have plug-ins that do this automatically.
Pull requests descriptions should be as clear as possible and include a Pull requests descriptions should be as clear as possible and include a
reference to all the issues that they address. reference to all the issues that they address.
@ -100,21 +105,22 @@ 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 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. 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` Commits that fix or close an issue should include a reference like
or `Fixes #XXX`, which will automatically close the issue when merged. `Closes #XXXX` or `Fixes #XXXX`, which will automatically close the
issue when merged.
Please do not add yourself to the AUTHORS file, as it is regenerated Please do not add yourself to the `AUTHORS` file, as it is regenerated
regularly from the Git history. regularly from the Git history.
### Merge approval ### Merge approval
Docker maintainers use LGTM (looks good to me) in comments on the code review Docker maintainers use LGTM (Looks Good To Me) in comments on the code review
to indicate acceptance. to indicate acceptance.
A change requires LGTMs from an absolute majority of the maintainers of each A change requires LGTMs from an absolute majority of the maintainers of each
component affected. For example, if a change affects docs/ and registry/, it component affected. For example, if a change affects `docs/` and `registry/`, it
needs an absolute majority from the maintainers of docs/ AND, separately, an needs an absolute majority from the maintainers of `docs/` AND, separately, an
absolute majority of the maintainers of registry. absolute majority of the maintainers of `registry/`.
For more details see [MAINTAINERS.md](hack/MAINTAINERS.md) For more details see [MAINTAINERS.md](hack/MAINTAINERS.md)
@ -137,7 +143,6 @@ San Francisco, CA 94110 USA
Everyone is permitted to copy and distribute verbatim copies of this Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed. license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1 Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that: By making a contribution to this project, I certify that:
@ -165,20 +170,20 @@ By making a contribution to this project, I certify that:
this project or the open source license(s) involved. this project or the open source license(s) involved.
``` ```
then you just add a line to every git commit message: Then you just add a line to every git commit message:
Docker-DCO-1.1-Signed-off-by: Joe Smith <joe.smith@email.com> (github: github_handle) Docker-DCO-1.1-Signed-off-by: Joe Smith <joe.smith@email.com> (github: github_handle)
using your real name (sorry, no pseudonyms or anonymous contributions.) Using your real name (sorry, no pseudonyms or anonymous contributions.)
One way to automate this, is customise your get ``commit.template`` by adding One way to automate this, is customize your git `commit.template` by adding
a ``prepare-commit-msg`` hook to your docker checkout: a `prepare-commit-msg` hook to your Docker repository:
``` ```
curl -o .git/hooks/prepare-commit-msg https://raw.githubusercontent.com/dotcloud/docker/master/contrib/prepare-commit-msg.hook && chmod +x .git/hooks/prepare-commit-msg curl -o .git/hooks/prepare-commit-msg https://raw.githubusercontent.com/dotcloud/docker/master/contrib/prepare-commit-msg.hook && chmod +x .git/hooks/prepare-commit-msg
``` ```
* Note: the above script expects to find your GitHub user name in ``git config --get github.user`` * Note: the above script expects to find your GitHub user name in `git config --get github.user`
#### Small patch exception #### Small patch exception
@ -194,11 +199,12 @@ If you have any questions, please refer to the FAQ in the [docs](http://docs.doc
### How can I become a maintainer? ### How can I become a maintainer?
* Step 1: learn the component inside out * Step 1: Learn the component inside out
* Step 2: make yourself useful by contributing code, bugfixes, support etc. * Step 2: Make yourself useful by contributing code, bug fixes, support etc.
* Step 3: volunteer on the irc channel (#docker@freenode) * Step 3: Volunteer on the IRC channel (#docker at Freenode)
* Step 4: propose yourself at a scheduled docker meeting in #docker-dev * Step 4: Propose yourself at a scheduled docker meeting in #docker-dev
Don't forget: being a maintainer is a time investment. Make sure you will have time to make yourself available. Don't forget: being a maintainer is a time investment. Make sure you
You don't have to be a maintainer to make a difference on the project! will have time to make yourself available. You don't have to be a
maintainer to make a difference on the project!