openstack/governance
Code Issues Proposed changes

Update documentation to try DPL model for leaderless projects

Browse Source 
As discussed in PTG, we will try the DPL model first for
the leaderless projects or if PTL assignment is needed in between
of the cycle.

- https://etherpad.opendev.org/p/tc-zed-ptg#L109

Change-Id: Ie65553720247b585be94d53811a2ade20353f9cc
This commit is contained in:
Ghanshyam Mann 2022-05-03 12:40:25 -05:00 committed by Ghanshyam
parent 584e06b0c1
commit bceddc51d5
2 changed files with 19 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
reference/charter.rst
View File

@ -128,9 +128,11 @@ than 3 weeks prior to each cycle final release date (on or before 'R-3' week)
and should be held open for no less than four business days.
If a PTL seat is vacated before the end of the cycle for which the individual
was elected, the TC will appoint a new PTL, in consultation with the outgoing
PTL and any interested candidates, following the process for leaderless project
teams (see
was elected or after the election (means leaderless project), the TC will
appoint a new PTL or move that project to the Distributed Project Leadership
model (see :doc:`/resolutions/20200803-distributed-project-leadership`),
in consultation with the outgoing PTL and any interested candidates, following
the process for leaderless project teams (see
:doc:`/resolutions/20141128-elections-process-for-leaderless-programs`). An
email must be sent to the ``openstack-discuss at lists.openstack.org`` mailing
list announcing the change in leadership. A patch must also be submitted to the

25
reference/house-rules.rst
View File

@ -150,17 +150,20 @@ Appointing Project Leaders/Liaisons
-----------------------------------
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.
authority to appoint the leader to any official project where the
`election`_ process failed to produce a leader. The TC preference will
be to move such project to Distributed Project Leadership model
(see :doc:`/resolutions/20200803-distributed-project-leadership`) than
appointing the PTL. When this happens, ``reference/projects.yaml`` in the
``governance`` repository should be updated to indicate the DPL model
leadership liaisons or 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.
In the case of a project using, or moving to, Distributed Project Leadership
model (see :doc:`/resolutions/20200803-distributed-project-leadership`), the