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

Merge pull request #7310 from stevecrozz/maintainers-grammar-update

Browse source 
Correct grammar in MAINTAINERS.md
This commit is contained in:
Tianon Gravi 2014-08-04 17:57:08 -06:00
commit 6b94f2d9be
1 changed files with 18 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

36
hack/MAINTAINERS.md
View file

@ -4,12 +4,12 @@
Dear maintainer. Thank you for investing the time and energy to help Dear maintainer. Thank you for investing the time and energy to help
make Docker as useful as possible. Maintaining a project is difficult, make Docker as useful as possible. Maintaining a project is difficult,
sometimes unrewarding work. Sure, you will get to contribute cool sometimes unrewarding work. Sure, you will get to contribute cool
features to the project. But most of your time will be spent reviewing, features to the project. But most of your time will be spent reviewing,
cleaning up, documenting, answering questions, justifying design cleaning up, documenting, answering questions, and justifying design
decisions - while everyone has all the fun! But remember - the quality decisions - while everyone has all the fun! But remember - the quality
of the maintainers work is what distinguishes the good projects from the of the maintainers' work is what distinguishes the good projects from
great. So please be proud of your work, even the unglamourous parts, the great. So please be proud of your work, even the unglamourous parts,
and encourage a culture of appreciation and respect for *every* aspect and encourage a culture of appreciation and respect for *every* aspect
of improving the project - not just the hot new features. of improving the project - not just the hot new features.
@ -20,34 +20,34 @@ available to them.
This is a living document - if you see something out of date or missing, This is a living document - if you see something out of date or missing,
speak up! speak up!
## What are a maintainer's responsibility? ## What is a maintainer's responsibility?
It is every maintainer's responsibility to: It is every maintainer's responsibility to:
1. Expose a clear roadmap for improving their component. 1. Expose a clear road map for improving their component.
2. Deliver prompt feedback and decisions on pull requests. 2. Deliver prompt feedback and decisions on pull requests.
3. Be available to anyone with questions, bug reports, criticism etc. 3. Be available to anyone with questions, bug reports, criticism etc.
on their component. This includes IRC, GitHub requests and the mailing on their component. This includes IRC, GitHub requests and the mailing
list. list.
4. Make sure their component respects the philosophy, design and 4. Make sure their component respects the philosophy, design and
roadmap of the project. road map of the project.
## How are decisions made? ## How are decisions made?
Short answer: with pull requests to the docker repository. Short answer: with pull requests to the Docker repository.
Docker is an open-source project with an open design philosophy. This 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 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 project, including its philosophy, design, road map, and APIs. *If it's
part of the project, it's in the repo. It's in the repo, it's part of part of the project, it's in the repo. If it's in the repo, it's part of
the project.* the project.*
As a result, all decisions can be expressed as changes to the As a result, all decisions can be expressed as changes to the
repository. An implementation change is a change to the source code. An 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 API change is a change to the API specification. A philosophy change is
a change to the philosophy manifesto. And so on. a change to the philosophy manifesto, and so on.
All decisions affecting docker, big and small, follow the same 3 steps: All decisions affecting Docker, big and small, follow the same 3 steps:
* Step 1: Open a pull request. Anyone can do this. * Step 1: Open a pull request. Anyone can do this.
@ -60,16 +60,16 @@ this (see below "Who decides what?")
## Who decides what? ## Who decides what?
All decisions are pull requests, and the relevant maintainers make All decisions are pull requests, and the relevant maintainers make
decisions by accepting or refusing the pull request. Review and acceptance decisions by accepting or refusing pull requests. Review and acceptance
by anyone is denoted by adding a comment in the pull request: `LGTM`. by anyone is denoted by adding a comment in the pull request: `LGTM`.
However, only currently listed `MAINTAINERS` are counted towards the required However, only currently listed `MAINTAINERS` are counted towards the
majority. required majority.
Docker follows the timeless, highly efficient and totally unfair system Docker follows the timeless, highly efficient and totally unfair system
known as [Benevolent dictator for known as [Benevolent dictator for
life](http://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life), with life](http://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life), with
yours truly, Solomon Hykes, in the role of BDFL. This means that all yours truly, Solomon Hykes, in the role of BDFL. This means that all
decisions are made by default by Solomon. Since making every decision decisions are made, by default, by Solomon. Since making every decision
myself would be highly un-scalable, in practice decisions are spread myself would be highly un-scalable, in practice decisions are spread
across multiple maintainers. across multiple maintainers.
@ -90,7 +90,7 @@ maintainers for a specified directory.
Please let your co-maintainers and other contributors know by raising a pull Please let your co-maintainers and other contributors know by raising a pull
request that comments out your `MAINTAINERS` file entry using a `#`. request that comments out your `MAINTAINERS` file entry using a `#`.
### I'm a maintainer, should I make pull requests too? ### I'm a maintainer. Should I make pull requests too?
Yes. Nobody should ever push to master directly. All changes should be Yes. Nobody should ever push to master directly. All changes should be
made through a pull request. made through a pull request.