diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c4095641cb..7eb20c473a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -117,7 +117,7 @@ to indicate acceptance. 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 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) @@ -170,10 +170,15 @@ curl -o .git/hooks/prepare-commit-msg https://raw.github.com/dotcloud/docker/mas * Note: the above script expects to find your GitHub user name in ``git config --get github.user`` +#### Small patch exception + +There are several exceptions to the signing requirement. Currently these are: + +* Your patch fixes spelling or grammar errors. +* Your patch is a single line change to documentation. + If you have any questions, please refer to the FAQ in the [docs](http://docs.docker.io) - - ### How can I become a maintainer? * Step 1: learn the component inside out diff --git a/docs/sources/faq.rst b/docs/sources/faq.rst index 2b48cc564c..07055941bd 100644 --- a/docs/sources/faq.rst +++ b/docs/sources/faq.rst @@ -189,10 +189,15 @@ How do I report a security issue with Docker? You can learn about the project's security policy `here `_ and report security issues to this `mailbox `_. +Why do I need to sign my commits to Docker with the DCO? +........................................................ + +Please read `our blog post `_ on the introduction of the DCO. + Can I help by adding some questions and answers? ................................................ - Definitely! You can fork `the repo`_ and edit the documentation sources. +Definitely! You can fork `the repo`_ and edit the documentation sources. Where can I find more answers? @@ -216,5 +221,4 @@ Where can I find more answers? .. _Ask questions on Stackoverflow: http://stackoverflow.com/search?q=docker .. _Join the conversation on Twitter: http://twitter.com/docker - Looking for something else to read? Checkout the :ref:`hello_world` example. diff --git a/hack/MAINTAINERS.md b/hack/MAINTAINERS.md index 8944fbee1a..be3117c864 100644 --- a/hack/MAINTAINERS.md +++ b/hack/MAINTAINERS.md @@ -1,22 +1,24 @@ -# The Docker maintainer manual +# The Docker Maintainer manual ## Introduction -Dear maintainer. Thank you for investing the time and energy to help make Docker as -useful as possible. Maintaining a project is difficult, sometimes unrewarding work. -Sure, you will get to contribute cool features to the project. But most of your time -will be spent reviewing, cleaning up, documenting, answering questions, justifying -design decisions - while everyone has all the fun! But remember - the quality of the -maintainers work is what distinguishes the good projects from the great. -So please be proud of your work, even the unglamourous parts, and encourage a culture -of appreciation and respect for *every* aspect of improving the project - not just the -hot new features. +Dear maintainer. Thank you for investing the time and energy to help +make Docker as useful as possible. Maintaining a project is difficult, +sometimes unrewarding work. Sure, you will get to contribute cool +features to the project. But most of your time will be spent reviewing, +cleaning up, documenting, answering questions, justifying design +decisions - while everyone has all the fun! But remember - the quality +of the maintainers work is what distinguishes the good projects from the +great. So please be proud of your work, even the unglamourous parts, +and encourage a culture of appreciation and respect for *every* aspect +of improving the project - not just the hot new features. -This document is a manual for maintainers old and new. It explains what is expected of -maintainers, how they should work, and what tools are available to them. - -This is a living document - if you see something out of date or missing, speak up! +This document is a manual for maintainers old and new. It explains what +is expected of maintainers, how they should work, and what tools are +available to them. +This is a living document - if you see something out of date or missing, +speak up! ## What are a maintainer's responsibility? @@ -24,19 +26,26 @@ It is every maintainer's responsibility to: * 1) Expose a clear roadmap for improving their component. * 2) Deliver prompt feedback and decisions on pull requests. -* 3) Be available to anyone with questions, bug reports, criticism etc. on their component. This includes irc, github requests and the mailing list. -* 4) Make sure their component respects the philosophy, design and roadmap of the project. - +* 3) Be available to anyone with questions, bug reports, criticism etc. + on their component. This includes IRC, GitHub requests and the mailing + list. +* 4) Make sure their component respects the philosophy, design and + roadmap of the project. ## How are decisions made? Short answer: with pull requests to the docker repository. -Docker is an open-source project with an open design philosophy. This means that the repository is the source of truth for EVERY aspect of the project, -including its philosophy, design, roadmap and APIs. *If it's part of the project, it's in the repo. It's in the repo, it's part of the project.* +Docker is an open-source project with an open design philosophy. This +means that the repository is the source of truth for EVERY aspect of the +project, including its philosophy, design, roadmap and APIs. *If it's +part of the project, it's in the repo. It's in the repo, it's part of +the project.* -As a result, all decisions can be expressed as changes to the repository. An implementation change is a change to the source code. An API change is a change to -the API specification. A philosophy change is a change to the philosophy manifesto. And so on. +As a result, all decisions can be expressed as changes to the +repository. An implementation change is a change to the source code. An +API change is a change to the API specification. A philosophy change is +a change to the philosophy manifesto. And so on. All decisions affecting docker, big and small, follow the same 3 steps: @@ -49,25 +58,36 @@ All decisions affecting docker, big and small, follow the same 3 steps: ## Who decides what? -So all decisions are pull requests, and the relevant maintainer makes the decision by accepting or refusing the pull request. -But how do we identify the relevant maintainer for a given pull request? +So all decisions are pull requests, and the relevant maintainer makes +the decision by accepting or refusing the pull request. But how do we +identify the relevant maintainer for a given pull request? -Docker follows the timeless, highly efficient and totally unfair system known as [Benevolent dictator for life](http://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life), -with yours truly, Solomon Hykes, in the role of BDFL. -This means that all decisions are made by default by me. Since making every decision myself would be highly un-scalable, in practice decisions are spread across multiple maintainers. +Docker follows the timeless, highly efficient and totally unfair system +known as [Benevolent dictator for +life](http://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life), with +yours truly, Solomon Hykes, in the role of BDFL. This means that all +decisions are made by default by Solomon. Since making every decision +myself would be highly un-scalable, in practice decisions are spread +across multiple maintainers. The relevant maintainer for a pull request is assigned in 3 steps: -* Step 1: Determine the subdirectory affected by the pull request. This might be src/registry, docs/source/api, or any other part of the repo. +* Step 1: Determine the subdirectory affected by the pull request. This + might be `src/registry`, `docs/source/api`, or any other part of the repo. -* Step 2: Find the MAINTAINERS file which affects this directory. If the directory itself does not have a MAINTAINERS file, work your way up the repo hierarchy until you find one. +* Step 2: Find the `MAINTAINERS` file which affects this directory. If the + directory itself does not have a `MAINTAINERS` file, work your way up + the repo hierarchy until you find one. -* Step 3: The first maintainer listed is the primary maintainer. The pull request is assigned to him. He may assign it to other listed maintainers, at his discretion. +* Step 3: The first maintainer listed is the primary maintainer. The + pull request is assigned to him. He may assign it to other listed + maintainers, at his discretion. ### I'm a maintainer, should I make pull requests too? -Yes. Nobody should ever push to master directly. All changes should be made through a pull request. +Yes. Nobody should ever push to master directly. All changes should be +made through a pull request. ### Who assigns maintainers?