diff options
| author | Volker Hilsheimer <volker.hilsheimer@qt.io> | 2022-07-26 15:46:20 +0200 |
|---|---|---|
| committer | Volker Hilsheimer <volker.hilsheimer@qt.io> | 2022-09-14 09:11:59 +0000 |
| commit | d37c0efaaa6805a27141fcbd28b8224c4bc604d8 (patch) | |
| tree | 9a22a37df1a67de741c917d12f1067262648fb6e /quip-0002.rst | |
| parent | b26d6903ca7ed07fdb951d35ec87c270fcb47fda (diff) | |
Provide an easier process for replacing inactive maintainer
We need a lower-threshold process to replace maintainers that are
inactive and not reachable. This is based on the proposal made at
the Qt Contributors Summit 2022:
https://wiki.qt.io/Qt_Contributors_Summit_2022_-_Program/Ghost_Maintainers
Making it possible to retire and/or replace inactive maintainers
require that we define some criteria for "inactivity". List approval
of API/header reviews explicitly as a maintainer's responsibility.
It is a very observable activity, and critical to the release
process.
Maintainers that are not following up on that responsibility, and
in addition do not respond to emails in which at least one other
Maintainer is copied, can be considered inactive. In that situation,
a new Maintainer may be nominated, following the regular process,
which still allows the old Maintainer to object.
Change-Id: I944515f8acb449ef916612f4f3e457726a7f612b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Diffstat (limited to 'quip-0002.rst')
| -rw-r--r-- | quip-0002.rst | 17 |
1 files changed, 16 insertions, 1 deletions
diff --git a/quip-0002.rst b/quip-0002.rst index 47909a9..af398a5 100644 --- a/quip-0002.rst +++ b/quip-0002.rst @@ -3,9 +3,11 @@ Title: The Qt Governance Model Author: Thiago Macieira Lars Knoll Louai Al-Khanji + Volker Hilsheimer Status: Active Type: Process Post-History: https://lists.qt-project.org/pipermail/development/2016-September/027218.html + https://lists.qt-project.org/pipermail/development/2022-September/042922.html Created: 2016-09-03 Overview @@ -158,7 +160,10 @@ Maintainers are responsible for the overall quality and spirit fit of their component, so they need good visibility of Contributor and Approver activity. They ensure the smooth running of the Project and must always be aware of the current state of their component, normally ensuring it is ready for beta release -at any time. +at any time. Maintainers give the final approval to API and C++ header changes +for their component during the `API review process`_ that precedes releases, +and ensure that any third party code that is included in their components is +updated regularly in line with the `security policy`_. Maintainers are expected to participate in strategic planning, approve changes to the governance model, manage intellectual property rights discussions within @@ -169,6 +174,9 @@ The authoritative list of Maintainers, including the components they own, is `on the Qt project Wiki`_. .. _`on the Qt project Wiki`: https://wiki.qt.io/Maintainers +.. _`API review process`: quip-0010-API-review.html +.. _`security policy`: quip-0015-Security-Policy.html + How to become a Maintainer '''''''''''''''''''''''''' @@ -204,6 +212,13 @@ Once someone has been appointed Maintainer, they remain in that role until they choose to step down by informing the Chief Maintainer, preferably with one month's warning. +Maintainers that have stopped participating in the development of their +component, do not review changes, do not ensure that their component is ready +for beta release, and do not respond to emails from the Chief Maintainer in +which at least one other maintainer has been copied, may be considered as +retired. In such a case, a new Maintainer may be nominated, following the +process described above. + In extreme circumstances Maintainer privileges can be revoked by a vote of no confidence, proposed by an existing Maintainer and arranged by the Chief Maintainer. Privilege revocation requires a two-thirds majority vote of those |