Update governance to replace TSC and add maintainer roles

Signed-off-by: Derek McGowan <derek@mcg.dev>

project/GOVERNANCE.md

@@ -1,12 +1,13 @@
 # Moby project governance
 
-Moby projects are governed by the [Moby Technical Steering Committee (TSC)](https://github.com/moby/tsc).
-See the Moby TSC [charter](https://github.com/moby/tsc/blob/master/README.md) for
-further information on the role of the TSC and procedures for escalation
-of technical issues or concerns.
+Moby is the open-source project used to build Docker, jointly maintained by Docker
+and the community. As a [community project](https://www.docker.com/community/open-source/),
+we abide by a [Code of Conduct](https://github.com/docker/code-of-conduct)
+and define a governance which ensures the project is community driven and open to
+anyone to contribute.
 
-Contact [any Moby TSC member](https://github.com/moby/tsc/blob/master/MEMBERS.md) with your questions/concerns about the governance or a specific technical 
-issue that you feel requires escalation.
+Contact moby@docker.com with any questions/concerns about the enforcement of the
+Code of Conduct.
 
 ## Project maintainers
 
@@ -26,32 +27,55 @@ to appreciate the absence of bugs, the slow but steady improvement in stability,
 or the reliability of a release process. But those things distinguish a good
 project from a great one.
 
-### Adding maintainers
+## Reviewers
 
-Maintainers are first and foremost contributors who have shown their
-commitment to the long term success of a project. Contributors who want to
-become maintainers first demonstrate commitment to the project by contributing
-code, reviewing others' work, and triaging issues on a regular basis for at
-least three months.
+A reviewer is a maintainer within the project.
+They share in reviewing issues and pull requests and their LGTM counts towards the
+required LGTM count to merge a code change into the project.
 
-The contributions alone don't make you a maintainer. You need to earn the
-trust of the current maintainers and other project contributors, that your
-decisions and actions are in the best interest of the project.
+Reviewers are part of the organization but do not have write access to the project.
+Becoming a reviewer is a core aspect in the journey to becoming a committer.
 
-Periodically, the existing maintainers curate a list of contributors who have
-shown regular activity on the project over the prior months. From this
-list, maintainer candidates are selected and proposed on the maintainers
-mailing list.
+## Committers
 
-After a candidate is announced on the maintainers mailing list, the
-existing maintainers discuss the candidate over the next 5 business days,
-provide feedback, and vote. At least 66% of the current maintainers must
-vote in the affirmative.
+A committer is a maintainer who is responsible for the overall quality and
+stewardship of the project. They share the same reviewing responsibilities as
+reviewers, but are also responsible for upholding the project bylaws as well as
+participating in project level votes.
 
-If a candidate is approved, a maintainer contacts the candidate to
-invite them to open a pull request that adds the contributor to
-the MAINTAINERS file. The candidate becomes a maintainer once the pull
-request is merged.
+Committers are part of the organization with write access to the project.
+Committers are expected to remain actively involved in the project and
+participate in voting and discussing of proposed project level changes.
+
+
+## Adding maintainers
+
+Maintainers are first and foremost contributors that have shown they are
+committed to the long term success of a project. Contributors wanting to become
+maintainers are expected to be deeply involved in contributing code, pull
+request review, and triage of issues in the project for more than three months.
+
+Just contributing does not make you a maintainer, it is about building trust
+with the current maintainers of the project and being a person that they can
+depend on and trust to make decisions in the best interest of the project.
+
+Periodically, the existing maintainers curate a list of contributors that have
+shown regular activity on the project over the prior months. From this list,
+maintainer candidates are selected and proposed in the maintainers forum.
+
+After a candidate has been informally proposed in the maintainers forum, the
+existing maintainers are given seven days to discuss the candidate, raise
+objections and show their support. Formal voting takes place on a pull request
+that adds the contributor to the MAINTAINERS file. Candidates must be approved
+by 2/3 of the current committers by adding their approval or LGTM to the pull
+request. The reviewer role has the same process but only requires 1/3 of current
+committers.
+
+If a candidate is approved, they will be invited to add their own LGTM or
+approval to the pull request to acknowledge their agreement. A committer will
+verify the numbers of votes that have been received and the allotted seven days
+have passed, then merge the pull request and invite the contributor to the
+organization.
 
 ### Removing maintainers
 
@@ -114,7 +138,12 @@ the same steps:
 
 Pull requests are reviewed by the current maintainers of the moby/moby
 repository. Weekly meetings are organized to synchronously
-discuss tricky PRs, as well as design and architecture decisions.. When
-technical agreement cannot be reached among the maintainers of the project,
-escalation or concerns can be raised by opening an issue to be handled
-by the [Moby Technical Steering Committee](https://github.com/moby/tsc).
+discuss tricky PRs, as well as design and architecture decisions.
+
+### Conflict Resolution
+
+If you have a technical dispute that you feel has reached an impasse with a
+subset of the community, any contributor may open an issue, specifically
+calling for a resolution vote of the current committers to resolve the
+dispute. A resolution vote must be approved by 2/3 of the current
+committers.