project: Document maintainers and workflow

It is important that potential contributors know who
they should get in touch, who is supposed to review
their work, and maintainers to know how they should
introduce changes.

Thus, this commit documents the current maintainers
together with what they maintain, and the workflow
between maintainers as well.

[skip ci]

2 files changed, 71 insertions, 5 deletions

diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md
index 7e054da29..58fca48c1 100644
--- a/docs/CONTRIBUTING.md
+++ b/docs/CONTRIBUTING.md
@@ -7,10 +7,13 @@ Please note we have a Code of Conduct, please follow it in all your interactions
 
 ## Pull Request Process
 
-1. Ensure your code compiles and doesn't break anything. Run `meson test -C <builddir>` before creating
-   the pull request.
-2. If you're adding new API, it must be properly documented.
-3. The commit message is formatted as follows:
+1. Create a fork in GitLab and push your work to there
+2. Open a Merge Request
+  1. Always allow maintainer edits
+  2. Mark the Merge Request as WIP if your work is not ready to be reviewed
+3. Assign the correct maintainer to the Merge Request (see [`MAINTAINERS.md`][maintainers] to select
+   the correct maintainer)
+4. Format commit messages as follows:
    ```
    component: <summary>
    ‌
@@ -68,4 +71,5 @@ This Code of Conduct is adapted from the [Contributor Covenant][homepage], versi
 available at [http://contributor-covenant.org/version/1/4][version]
 
 [homepage]: http://contributor-covenant.org
-[version]: http://contributor-covenant.org/version/1/4/
\ No newline at end of file
+[version]: http://contributor-covenant.org/version/1/4/
+[maintainers]: https://gitlab.gnome.org/GNOME/gnome-control-center/blob/master/docs/MAINTAINERS.md
diff --git a/docs/MAINTAINERS.md b/docs/MAINTAINERS.md
new file mode 100644
index 000000000..cdcdf5f1d
--- /dev/null
+++ b/docs/MAINTAINERS.md
@@ -0,0 +1,62 @@
+This document describes how maintainership works on GNOME Settings. It is intended to be a guideline
+for future reference.
+
+The list of current maintainers can be found at the [gnome-control-center.doap][doap] DOAP file.
+
+# General Rules
+
+The purpose of the shared maintainership model in GNOME Settings is to avoid as much as possible
+pushing unreviewed code in the main repository. Not only it is a good engineering practice, but it
+also increases the code quality and reduces the number of bugs.
+
+GNOME Settings has two types of maintainers:
+
+ * **General Maintainer**: take care of the whole codebase and of panels without a specific maintainer.
+ * **Panel Maintainer**: take care of a specific panel with a stronger authority over General
+   Maintainers.
+
+
+## For Contributors
+
+Panel Maintainers have a stronger authority over their panels than a General Maintainer. If you are
+contributing to a specific panel, and that panel has a dedicate maintainer, they should be the main
+point of contact.
+
+In the rare case of Panel Maintainers not being responsive, it is allowed to contact General
+Maintainers.
+
+## For Maintainers
+
+If you are a Panel Maintainer, your merge requests will be reviewed by General Maintainer. The
+opposite is true as well - General Maintainers contributing to a specific panel will have their
+merge requests reviewed by the Panel Maintainer of that panel.
+
+If you are a General Maintainer contributing to an unmaintained panel, or to the main codebase, your
+merge requests will be reviewed by another General Maintainer.
+
+Avoid pushing commits without an explicit review, except in the following cases:
+
+ * The commit is a translation commit
+ * The commit is trivial
+ * The commit is urgent and no reviewers were available in time
+
+When accepting a merge request and allowing the other maintainer to merge, avoid misunderstandings
+by being explicit. Suggested acceptance phrase:
+
+`I approve this merge request. You are allowed to merge it.`
+
+### Urgency Commits
+
+Urgency commits should never happen, but in case they're needed, they are defined by the following
+criteria:
+
+ * On stable branches (or master right after a stable release)
+ * Symptoms:
+   * Always OR often reproducible; AND
+   * Crash; OR
+   * Data loss; OR
+   * System corruption
+ * Quickly followed by an emergency release (at most 2 days after the commit)
+
+
+[doap]: https://gitlab.gnome.org/GNOME/gnome-control-center/blob/master/gnome-control-center.doap