Add some rules to the MAINTAINERS file.

These are mostly taken from containerd and adjusted to LinuxKit.

Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>

MAINTAINERS

@@ -8,6 +8,154 @@
 #
 # This file is compiled into the MAINTAINERS file in docker/opensource.
 #
+
+[Rules]
+
+        [Rules.maintainers]
+
+        title = "What is a maintainer?"
+
+        text = """
+There are different types of maintainers, with different
+responsibilities, but all maintainers have 3 things in common:
+
+1) They share responsibility in the project's success.
+2) They have made a long-term, recurring time investment to improve
+   the project.
+3) They spend that time doing whatever needs to be done, not
+   necessarily what is the most interesting or fun.
+
+Maintainers are often under-appreciated, because their work is harder
+to appreciate.  It's easy to appreciate a really cool and technically
+advanced feature. It's harder 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.
+"""
+
+        [Rules.adding-maintainers]
+
+        title = "How are maintainers added?"
+
+        text = """
+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.
+
+After a candidate has been announced, the existing maintainers are
+given five business days to discuss the candidate, raise objections
+and cast their vote. Candidates must be approved by at least 66% of
+the current maintainers by adding their vote on the slack
+channel. Only maintainers of the repository that the candidate is
+proposed for are allowed to vote.
+
+If a candidate is approved, a maintainer will contact the candidate to
+invite the candidate to open a pull request that adds the contributor
+to the MAINTAINERS file. The candidate becomes a maintainer once the
+pull request is merged.
+"""
+
+        [Rules.stepping-down-policy]
+
+        title = "Stepping down policy"
+
+        text = """
+Life priorities, interests, and passions can change. If you're a
+maintainer but feel you must remove yourself from the list, inform
+other maintainers that you intend to step down, and if possible, help
+find someone to pick up your work.  At the very least, ensure your
+work can be continued where you left off.
+
+After you've informed other maintainers, create a pull request to
+remove yourself from the MAINTAINERS file.
+"""
+
+        [Rules.inactive-maintainers]
+
+        title = "Removal of inactive maintainers"
+
+        text = """
+Similar to the procedure for adding new maintainers, existing
+maintainers can be removed from the list if they do not show
+significant activity on the project. Periodically, the maintainers
+review the list of maintainers and their activity over the last three
+months.
+
+If a maintainer has shown insufficient activity over this period, a
+neutral person will contact the maintainer to ask if they want to
+continue being a maintainer. If the maintainer decides to step down as
+a maintainer, they open a pull request to be removed from the
+MAINTAINERS file.
+
+If the maintainer wants to remain a maintainer, but is unable to
+perform the required duties they can be removed with a vote of at
+least 66% of the current maintainers.  The voting period is five
+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.
+"""
+
+        [Rules.DCO]
+
+        title = "Helping contributors with the DCO"
+
+        text = """
+The [DCO or `Sign your work`](
+https://github.com/linuxkit/linuxkit/blob/master/CONTRIBUTING.md#sign-your-work)
+requirement is not intended as a roadblock or speed bump.
+
+Some LinuxKit contributors are not as familiar with `git`, or have
+used a web based editor, and thus asking them to `git commit --amend
+-s` is not the best way forward.
+
+In this case, maintainers can update the commits based on clause (c)
+of the DCO.  The most trivial way for a contributor to allow the
+maintainer to do this, is to add a DCO signature in a pull requests's
+comment, or a maintainer can simply note that the change is
+sufficiently trivial that it does not substantially change the
+existing contribution - i.e., a spelling change.
+
+When you add someone's DCO, please also add your own to keep a log.
+"""
+
+        [Rules."no direct push"]
+
+        title = "I'm a maintainer. Should I make pull requests too?"
+
+        text = """
+Yes. Nobody should ever push to master directly. All changes should be
+made through a pull request.
+"""
+
+        [Rules.tsc]
+
+        title = "Conflict Resolution and technical disputes"
+
+        text = """
+LinuxKit defers to the [Technical Steering
+Committee](https://github.com/moby/tsc) for escalations and resolution
+on disputes for technical matters."
+"""
+
+        [Rules.meta]
+
+        title = "How is this process changed?"
+
+        text = "Just like everything else: by making a pull request :)"
+
+
+# Current project organization
 [Org]
 	[Org."Core maintainers"]
 		people = [