Maintainers: Suggest the maintainers codex (#932)

The guide is based on the one from the RunC project, but
has some criu-related specifics.

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>

MAINTAINERS

@@ -0,0 +1,2 @@
+Pavel Emelyanov <ovzxemul@gmail.com> (chief)
+Andrey Vagin <avagin@gmail.com>

MAINTAINERS_GUIDE.md

@@ -0,0 +1,136 @@
+## Introduction
+
+Dear maintainer. Thank you for investing the time and energy to help
+make CRIU as useful as possible. Maintaining a project is difficult,
+sometimes unrewarding work. Sure, you will contribute cool features
+to the project, but most of your time will be spent reviewing patches,
+cleaning things up, documenting, answering questions, justifying design
+decisions - while everyone else will just have fun! But remember -- the
+quality of the maintainers work is what distinguishes the good projects
+from the great. So please be proud of your work, even the unglamorous
+parts, and encourage a culture of appreciation and respect for *every*
+aspect of improving the project -- not just the hot new features.
+
+Being a maintainer is a time consuming commitment and should not be
+taken lightly. This document is a manual for maintainers old and new.
+It explains what is expected of maintainers, how they should work, and
+what tools are available to them.
+
+This is a living document - if you see something out of date or missing,
+speak up!
+
+## What are a maintainer's responsibility?
+
+Part of a healthy project is to have active maintainers to support the
+community in contributions and perform tasks to keep the project running.
+It is every maintainer's responsibility to:
+
+  * Keep the community a friendly place
+  * Deliver prompt feedback and decisions on pull requests and mailing
+    list threads
+  * Encourage other members to help each other, especially in cases the
+    maintainer is overloaded or feels the lack of needed expertise
+  * Make sure the changes made respects the philosophy, design and
+    roadmap of the project
+
+## How are decisions made?
+
+CRIU 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. *If it's part of the project, it's in the repo. It's in the
+repo, it's part of the project.*
+
+All decisions affecting CRIU, big and small, follow the same 3 steps:
+
+  * Submit a change. Anyone can do this
+
+  * Discuss it. Anyone can and is encouraged to do this
+
+  * Accept or decline it. Only maintainers do this
+
+*I'm a maintainer, should I make pull requests / send patches too?*
+
+Yes. Nobody should ever push to the repository directly. All changes
+should be made through submitting (and accepting) the change.
+
+### Two-steps decision making ###
+
+Since CRIU is extremely complex piece of software we try double hard
+not to make mistakes, that would be hard to fix in the future. In order
+to facilitate this, the "final" decision is made in two stages:
+
+  * We definitely want to try something out
+
+  * We think that the attempt was successful
+
+Respectively, new features get accepted first into the *criu-dev* branch and
+after they have been validated they are merged into the *master* branch. Yet,
+urgent bug fixes may land directly in the master branch. If a change in
+the criu-dev branch is considered to be bad (whatever it means), then it
+can be reverted without propagation to the master branch. Reverting from
+the master branch is expected not to happen at all, but if such an
+extraordinary case occurs, the impact of this step, especially the question
+of backward compatibility, should be considered in the most careful manner.
+
+## Who decides what?
+
+All decisions can be expressed as changes to the repository (either in the
+form of pull requests, or patches sent to the mailing list), and maintainers
+make decisions by merging or rejecting them. Review and approval or
+disagreement can be done by anyone and is denoted by adding a respective
+comment in the pull request. However, merging the change into either branch
+only happens after approvals from maintainers.
+
+In order for a patch to be merged into the criu-dev branch at least two
+maintainers should accept it. In order for a patch to be merged into the
+master branch the majority of maintainers should decide that (then prepare
+a pull request, submit it, etc.).
+
+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.
+
+### Chief maintainer
+
+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.
+
+Also the chief maintainer has the veto power on any change submitted
+to any branch. Naturally, a change in the criu-dev branch can be reverted
+after a chief maintainer veto, a change in the master branch must be
+carefully reviwed by the chief maintainer and vetoed in advance.
+
+### How are maintainers added (and removed)?
+
+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,
+patches review, and paying needed attention to the issues in the project.
+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
+rely on and trust to make decisions in the best interest of the project.
+
+When a contributor wants to become a maintainer or nominate someone as a
+maintainer, one can submit a "nomination", which technically is the
+respective modification to the `MAINTAINERS` file. When a maintainer feels
+they is unable to perform the required duties, or someone else wants to draw
+the community attention to this fact, one can submit a "(self-)removing"
+change.
+
+The final vote to add or to remove a maintainer is to be approved by the
+majority of current maintainers (with the chief maintainer having veto power
+on that too).
+
+One might have noticed, that the chief maintainer (re-)assignment is not
+regulated by this document. That's true :) However, this can be done. If
+the community decides that the chief maintainer needs to be changed the
+respective "decision making rules" are to be prepared, submitted and
+accepted into this file first.
+
+Good luck!