@@ -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,9 +170,14 @@ 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``

-If you have any questions, please refer to the FAQ in the [docs](http://docs.docker.io)

+#### 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?

@@ -189,10 +189,15 @@ How do I report a security issue with Docker?

 You can learn about the project's security policy `here <http://www.docker.io/security/>`_

 and report security issues to this `mailbox <mailto:security@docker.com>`_.

+Why do I need to sign my commits to Docker with the DCO?

+........................................................

+

+Please read `our blog post <http://blog.docker.io/2014/01/docker-code-contributions-require-developer-certificate-of-origin/>`_ 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.

@@ -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?