openstack/governance
Code Issues Proposed changes

Add a house rule about how to signal appointed PTLs

Browse Source 
We've been dealing with how to make appointed PTLs official and
documented in a rather ad hoc fashion: something different each
cycle.

This change provides a house rule which puts the responsibility
and the documentation in the combined hands of the appointed PTL
and the TC that appointed them and not election handling (where
it doesn't make sense since no election happened).

Change-Id: Idf78e00c59d10528a2b4950f8baa93c6731973ea
This commit is contained in:
Chris Dent 2018-08-10 16:10:12 +01:00
parent 859aac9a28
commit e783b307ea
2 changed files with 24 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
reference/house-rules.rst
View File

@ -72,6 +72,24 @@ If a TC member feels that one of these responses needs to be discussed
by the entire TC, they should bring it up on the mailing list and the change
should not be approved until after the discussion is completed.
Appointing PTLs
---------------
In a resolution regarding :ref:`leaderless programs`, the TC was granted
authority to appoint a Project Team Lead to any official project where the
`election`_ process failed to produce a leader. When this happens,
``reference/projects.yaml`` in the ``governance`` repository should be updated
to indicate the new PTL and their appointment by adding their name and contact
details and updating an ``appointed`` key with the cycle during which they will
be the PTL. If the ``appointed`` key is already present, add the cycle to the
list. If the key is not present, add it and set the cycle as a single member of
a list. This format is used for two reasons: to track all the cycles for which
there has been an appointment and to require a comprehensible change for review
by the TC. The ``appointed`` key should only be changed when the PTL was not
chosen by the election process.
These changes are subject to the standard review and approval guidelines.
Rolling back fast-tracked changes
---------------------------------
@ -79,3 +97,6 @@ As a safety net, if any member disagrees with any change that was fast-tracked
under one of those house rules, that member can propose a revert of the
change. Such revert should be directly approved by the chair and the change
be discussed on the mailing list or on the re-proposed change in gerrit.
.. _election: http://docs.openstack.org/project-team-guide/open-community.html#technical-committee-and-ptl-elections

3
resolutions/20141128-elections-process-for-leaderless-programs.rst
View File

@ -1,3 +1,6 @@
.. _leaderless programs:
===========================================
2014-11-28 Process for Leaderless Programs
===========================================