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