1This document describes how maintainership works on GNOME Settings. It is intended to be a guideline
2for future reference.
3
4The list of current maintainers can be found at the [gnome-control-center.doap][doap] DOAP file.
5
6# General Rules
7
8The purpose of the shared maintainership model in GNOME Settings is to avoid as much as possible
9pushing unreviewed code in the main repository. Not only it is a good engineering practice, but it
10also increases the code quality and reduces the number of bugs.
11
12GNOME Settings has two types of maintainers:
13
14 * **General Maintainer**: take care of the whole codebase and of panels without a specific maintainer.
15 * **Panel Maintainer**: take care of a specific panel with a stronger authority over General
16   Maintainers.
17
18
19## For Contributors
20
21Panel Maintainers have a stronger authority over their panels than a General Maintainer. If you are
22contributing to a specific panel, and that panel has a dedicate maintainer, they should be the main
23point of contact.
24
25In the rare case of Panel Maintainers not being responsive, it is allowed to contact General
26Maintainers.
27
28## For Maintainers
29
30If you are a Panel Maintainer, your merge requests will be reviewed by General Maintainer. The
31opposite is true as well - General Maintainers contributing to a specific panel will have their
32merge requests reviewed by the Panel Maintainer of that panel.
33
34If you are a General Maintainer contributing to an unmaintained panel, or to the main codebase, your
35merge requests will be reviewed by another General Maintainer.
36
37Avoid pushing commits without an explicit review, except in the following cases:
38
39 * The commit is a translation commit
40 * The commit is trivial
41 * The commit is urgent and no reviewers were available in time
42
43When accepting a merge request and allowing the other maintainer to merge, avoid misunderstandings
44by being explicit. Suggested acceptance phrase:
45
46`I approve this merge request. You are allowed to merge it.`
47
48### Urgency Commits
49
50Urgency commits should never happen, but in case they're needed, they are defined by the following
51criteria:
52
53 * On stable branches (or master right after a stable release)
54 * Symptoms:
55   * Always OR often reproducible; AND
56   * Crash; OR
57   * Data loss; OR
58   * System corruption
59 * Quickly followed by an emergency release (at most 2 days after the commit)
60
61
62[doap]: https://gitlab.gnome.org/GNOME/gnome-control-center/blob/master/gnome-control-center.doap
63