MAINTAINERS_GUIDE: Replace Chief Maintainer with GOVERNANCE

Hooray institutions ;).  Because GOVERNANCE is already making
decisions with a 2/3 vote, there's no reason to appeal to the TOB (the
old 2/3 vote for appeal is now sufficient for making the decision
outright).

All current OCI Projects have adopted the GOVERNANCE docs [1]
(although runC has yet to actually merge them into its repository) so
I think this approach is portable while the Chief Maintainer approach
was not [2].  Taking the runC maintainer subset of that vote (just to
be sure the doc applies to runC):

+7: Aleksa Sarai, Alexander Morozov, Daniel Dao, Mrunal Patel, Qiang
    Huang, Rohit Jnagal, Victor Marmol
-0
opencontainers#2: Andrey Vagin, Michael Crosby

and 7/9 > 2/3.

This also avoids the strange behavior where a 2/3 vote of maintainers
could approve a new maintainer, the Chief Maintainer could veto, and
the same 2/3 vote could appeal that veto to the TOB.  And it's nice to
have a single set of rules for project-management issues, and not a
five "business days" window for new maintainers one-week window for
other management issues.  The ten-day window for maintainer removal is
now a shorter seven, but with the call for earlier private discussion
I don't think it's worth special-casing just to get an extra three
days.

Also:

* Remove "across the maintainers of the project".  "respect across"
  seemed awkward ("respect between" is closer but still not quite
  right).  In any case, the next sentence makes it clear with "trust
  one another", so I think the bit I removed was superfluous.
* Replace "depend on and trust" with "depend on", because building
  trust was already mentioned in that sentence, and I don't see any
  semantic distiction between "depend on and trust" and "depend on".
* Replace "make decisions" with "act".  Same meaning, fewer letters ;).
* Adjust the paragraphs I touched to the README's recommended one line
  per sentence.

[1]: https://groups.google.com/a/opencontainers.org/d/msg/dev/x-Oh3PDz1Y8/q7t2IseVAwAJ
     Subject: [project-template adopted]: Merge 56abe12 (+13 -0 opencontainers#5)
     Date: Wed, 20 Jul 2016 16:51:58 +0000
     Message-ID: <CAD2oYtPwMcF__WD32cV6dHgHt8=F6qFw+XFGw4iQK9LGi_QWsg@mail.gmail.com>
[2]: opencontainers/runtime-spec#420 (comment)
     Subject: Update maintainers and contributors guides

Signed-off-by: W. Trevor King <wking@tremily.us>

MAINTAINERS_GUIDE.md

@@ -68,25 +68,10 @@ two LGTMs. In addition, if a maintainer has created a pull request, they cannot
 count toward the two LGTM rule (to ensure equal amounts of review for every pull
 request, no matter who wrote it).
 
-Overall the maintainer system works because of mutual respect across the
-maintainers of the project.  The maintainers trust one another to make decisions
-in the best interests of the project.  Sometimes maintainers can disagree and
-this is part of a healthy project to represent the point of views of various people.
-In the case where maintainers cannot find agreement on a specific change the
-role of a Chief Maintainer comes into play.
-
-The Chief Maintainer for the project is responsible for overall architecture
-of the project to maintain conceptual integrity.  Large decisions and
-architecture changes should be reviewed by the chief maintainer.
-The current chief maintainer for the project is the first person listed
-in the MAINTAINERS file.
-
-Even though the maintainer system is built on trust, if there is a conflict
-with the chief maintainer on a decision, their decision can be challenged
-and brought to the technical oversight board if two-thirds of the
-maintainers vote for an appeal. It is expected that this would be a
-very exceptional event.
-
+Overall the maintainer system works because of mutual respect.
+The maintainers trust one another to act in the best interests of the project.
+Sometimes maintainers can disagree and this is part of a healthy project to represent the point of views of various people.
+In the case where maintainers cannot find agreement on a specific change, maintainers should use the [governance procedure](GOVERNANCE.md) to attempt to reach a consensus.
 
 ### How are maintainers added?
 
@@ -96,14 +81,8 @@ the long term success of the 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 two 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.  The
-final vote to add a new maintainer should be approved by over 66% of the current
-maintainers with the chief maintainer having veto power.  In case of a veto,
-conflict resolution rules expressed above apply.  The voting period is
-five business days on the Pull Request to add the new maintainer.
-
+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 to act in the best interest of the project.
+The final vote to add a new maintainer should be approved by the [governance procedure](GOVERNANCE.md).
 
 ### What is expected of maintainers?
 
@@ -113,8 +92,5 @@ expected to be able to respond in a timely manner if their help is required on s
 issues where they are pinged.  Being a maintainer is a time consuming commitment and should
 not be taken lightly.
 
-When a maintainer is unable to perform the required duties they can be removed with
-a vote by 66% of the current maintainers with the chief maintainer having veto power.
-The voting period is ten business days.  Issues related to a maintainer's performance should
-be discussed with them among the other maintainers so that they are not surprised by
-a pull request removing them.
+When a maintainer is unable to perform the [required duties](#what-are-a-maintainers-responsibilities) they can be removed by the [governance procedure](GOVERNANCE.md).
+Issues related to a maintainer's performance should be discussed with them among the other maintainers so that they are not surprised by a pull request removing them.