Update maintainers guide

This makes some changes to the maintainer's guide and roles within the
project.  It removed the concept of a BDFL and carries over the chief
maintainer role into the project.  BDFL sucks and we can do better and
these changed help to make many more things specific around adding new
maintainers and removing them as well.

Signed-off-by: Michael Crosby <crosbymichael@gmail.com>

MAINTAINERS_GUIDE.md

@@ -25,8 +25,7 @@ It is every maintainer's responsibility to:
 * 1) Expose a clear roadmap for improving their component.
 * 2) Deliver prompt feedback and decisions on pull requests.
 * 3) Be available to anyone with questions, bug reports, criticism etc.
-  on their component. This includes IRC, GitHub requests and the mailing
-  list.
+  on their component. This includes IRC and GitHub issues and pull requests.
 * 4) Make sure their component respects the philosophy, design and
   roadmap of the project.
 
@@ -54,6 +53,10 @@ All decisions affecting runc, big and small, follow the same 3 steps:
 * Step 3: Accept (`LGTM`) or refuse a pull request. The relevant maintainers do 
 this (see below "Who decides what?")
 
+### I'm a maintainer, should I make pull requests too?
+
+Yes. Nobody should ever push to master directly. All changes should be
+made through a pull request.
 
 ## Who decides what?
 
@@ -63,35 +66,55 @@ by anyone is denoted by adding a comment in the pull request: `LGTM`.
 However, only currently listed `MAINTAINERS` are counted towards the required
 two LGTMs.
 
-runc follows the timeless, highly efficient and totally unfair system
-known as [Benevolent dictator for life](http://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life), with Michael Crosby in the role of BDFL.
-This means that all decisions are made by default by Michael. Since making
-every decision himself would be highly un-scalable, in practice decisions
-are spread across multiple maintainers.
+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 relevant maintainers for a pull request can be worked out in two steps:
+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 Michael Crosby (@crosbymichael).  
 
-* Step 1: Determine the subdirectories affected by the pull request. This
-  might be `netlink/` and `security/`, or any other part of the repo.
+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.
 
-* Step 2: Find the `MAINTAINERS` file which affects this directory. If the
-  directory itself does not have a `MAINTAINERS` file, work your way up
-  the repo hierarchy until you find one.
 
-### I'm a maintainer, and I'm going on holiday
+### How are maintainers added?
 
-Please let your co-maintainers and other contributors know by raising a pull
-request that comments out your `MAINTAINERS` file entry using a `#`.
+The best maintainers have a vested interest in the project.  Maintainers
+are first and foremost contributors that have shown they are committed to
+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.
 
-### I'm a maintainer, should I make pull requests too?
+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.
 
-Yes. Nobody should ever push to master directly. All changes should be
-made through a pull request.
 
-### Who assigns maintainers?
+### What is expected of maintainers?
+
+Part of a healthy project is to have active maintainers to support the community
+in contributions and perform tasks to keep the project running.  Maintainers are
+expected to be able to respond in a timely manner if their help is required on specific
+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.
 
-Michael has final `LGTM` approval for all pull requests to `MAINTAINERS` files.
 
-### How is this process changed?
 
-Just like everything else: by making a pull request :)