mirror of
https://github.com/moby/moby.git
synced 2022-11-09 12:21:53 -05:00
Merge pull request #7310 from stevecrozz/maintainers-grammar-update
Correct grammar in MAINTAINERS.md
This commit is contained in:
commit
6b94f2d9be
1 changed files with 18 additions and 18 deletions
|
@ -6,10 +6,10 @@ 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.
|
||||||
|
|
Loading…
Reference in a new issue