MAINTAINERS_GUIDE: Mention email in "How are decisions made?"

The old wording did not mention email discussion before working up
changes, which we often recommend [1,2] to avoid contributors sinking
a lot of work into a pull request that ends up being rejected because
of a fundamental design issue.  The new wording mentions that and
also:

* Removes the overly compact short answer to avoid confusion [3].  The
  section is not so long that it needs a one-line summary.
* Distinguishes between in-PR votes (LGTM/Rejected) and
  merging/closing the PR.
* Mentions GOVERNANCE for management changes.
* Uses an enumerated list instead of "Step N" text.
* Uses the README's recommended one line per sentence.

[1]: CONTRIBUTING.md#conventions
[2]: opencontainers/runtime-spec#420 (comment)
[3]: opencontainers/runtime-spec#420 (comment)

Signed-off-by: W. Trevor King <[email protected]>

Author: wking

MAINTAINERS_GUIDE.md

@@ -30,8 +30,6 @@ It is every maintainer's responsibility to:
 
 ## How are decisions made?
 
-Short answer: with pull requests to the project repository.
-
 This project 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
@@ -43,14 +41,19 @@ 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 this project, big and small, follow the same 3 steps:
-
-* Step 1: Open a pull request. Anyone can do this.
-
-* Step 2: Discuss the pull request. Anyone can do this.
-
-* Step 3: Accept (`LGTM`) or refuse a pull request. The relevant maintainers do
-this (see below "Who decides what?")
+All decisions affecting this project, big and small, follow the same procedure:
+
+1. Discuss a proposal on the [mailing list](CONTRIBUTING.md#mailing-list).
+   Anyone can do this.
+2. Open a pull request.
+   Anyone can do this.
+3. Discuss the pull request.
+   Anyone can do this.
+4. Endorse (`LGTM`) or oppose (`Rejected`) the pull request.
+   The relevant maintainers do this (see below [Who decides what?](#who-decides-what)).
+   Changes that affect project management (changing policy, cutting releases, etc.) are [proposed and voted on the mailing list](GOVERNANCE.md).
+5. Merge or close the pull request.
+   The relevant maintainers do this.
 
 ### I'm a maintainer, should I make pull requests too?