From bceddc51d568a2233d1eae43333d674344a038df Mon Sep 17 00:00:00 2001 From: Ghanshyam Mann Date: Tue, 3 May 2022 12:40:25 -0500 Subject: [PATCH] Update documentation to try DPL model for leaderless projects 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 --- reference/charter.rst | 8 +++++--- reference/house-rules.rst | 25 ++++++++++++++----------- 2 files changed, 19 insertions(+), 14 deletions(-) diff --git a/reference/charter.rst b/reference/charter.rst index 545fe0f2d..2f543315c 100644 --- a/reference/charter.rst +++ b/reference/charter.rst @@ -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 diff --git a/reference/house-rules.rst b/reference/house-rules.rst index 2b90e9e23..1bc658d4c 100644 --- a/reference/house-rules.rst +++ b/reference/house-rules.rst @@ -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