openstack/governance
Code Issues Proposed changes

Add DPL model & liaison reset policy

Browse Source 
We introduced the DPL model in 2020 and many projects tried and
continued this leadership model. One thing that lacked or did not
work out is the monitoring of liaisons activeness. We relied on
the project team liaisons to be active and if they are not or
they cannot serve in that role anymore, they modify the same
in project.yaml. Also, TC members are to keep monitoring the liaison's
status at regular intervals. But none of these things helped and
there were cases that liaisons were not active and so was the project.

To have an easy monitoring policy, this change proposes a TC liaison
as a required liaison for the DPL projects who will monitor the
project activities as well as reset the DPL model and liaison status.
This way we can explicitly know if DPL liaisons are active and if any
project would like to continue the DPL model they need to opt-in every
cycle.

Change-Id: I915e55f8e6175185658cb60d369b3f649e964db0
This commit is contained in:
Ghanshyam Mann 2024-04-29 20:21:22 -07:00
parent 7d2e526c9c
commit 0a7df7f5e0
2 changed files with 22 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
reference/distributed-project-leadership.rst
View File

@ -9,7 +9,7 @@ many responsibilities for managing the development and release process for the
project deliverables as well as representing the project team both internally and
externally.
This resolution outlines a process for OpenStack project teams to opt in to a
This document outlines the process for OpenStack project teams to opt in to a
"distributed leadership" model where there is no PTL. The responsibilities
normally held by the PTL are distributed to various liaisons, which may be held
by one or multiple contributors.
@ -22,7 +22,7 @@ teams can still contact the TC to resolve deadlocks in disputes.
How the PTL with liaisons works
-------------------------------
This resolution will not change how the PTL with liaisons work:
The DPL model will not change how the PTL with liaisons work:
the PTL is still encouraged to delegate responsibilities to
individuals. The PTL remains the single point of contact and responsibility for
all the duties.
@ -58,6 +58,11 @@ roles:
coordinate the development of patches, review proposed patches, and propose
any eventual backport(s).
* TC liaison: the TC liaison is one of the TC members who will follow the project
activities at regular intervals and make sure the DPL model is reset every cycle.
Project team who is planning to adopt the DPL model can reach out to the TC to
find the TC liaison for their project.
Additional recommended roles
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -108,15 +113,15 @@ discretion of the project teams, as long as it is public, open, and respectful
of the current TC guidelines. The TC advocates the use of consensus decisions,
with polls or elections when consensus can not be reached.
Liaison assignment duration
~~~~~~~~~~~~~~~~~~~~~~~~~~~
DPL model & liaison duration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
While the PTL is assigned to a single cycle, the duration of the assignment
for a team's liaison is unlimited in time. To avoid outdated information,
a TC member dedicated to follow a project team with distributed leadership
will query, at regular intervals (once per cycle), if the liaisons for the
team are still valid. It is expected to have the liaisons answer on the
mailing list thread to extend/validate their liaison status.
DPL liaisons are assigned for a single release cycle. The assigned TC liaison
will follow the project activities at regular intervals. Before the next cycle
PTL election nominations start, the TC liaison will reset the project team
leadership model to PTL and the project team needs to opt-in to the DPL model
explicitly with the same or new liaisons. This requires +1 from all the people
volunteering as liaisons.
Points of Concern
-----------------
@ -169,20 +174,22 @@ liaisons.
Technical notes:
* A follow-up patch on this resolution will change the "liaisons" field to adapt
its current structure, to add the new mandatory roles, next to the already
present list of TC members liaising for the team.
* The releases liaison will continue to be listed in the `releases` repository,
to not impact the current delivery of the releases.
Once a project team has moved to the distributed leadership model, they can
revert to the PTL model by creating a change to `projects.yaml` to remove the
"leadership_type: distributed" line in the team's configuration. This change
"leadership_type: distributed" line in the team's configuration. This change
should have at least a +1 from all the people currently serving as liaisons,
including the :repo:`openstack/releases/src/branch/master/data/release_liaisons.yaml`
for the project team, which might not be in the `governance` repo.
It must also get a +1 from the future PTL, listed in the same change.
.. note::
In every release cycle, The TC liaison will reset the DPL model & liaison (see
`DPL model & liaison duration`_).
A project team may change their opt-in status only once a release cycle, to
ensure that the elections officials have clarity on which project teams need PTL
elections. All requests should be merged before the election nominations start

1
reference/tc-chair-responsibilities.rst
View File

@ -39,6 +39,7 @@ Each Cycle
* Check on the active goals and, if there is no active goal, then ensure
that 2 TC members are signed up to manage the goal selection process.
* Ensure PTI and testing runtime update is done.
* Ensure the project's DPL model is reset before election nomination start.
* Election planning
* During PTG or at the start of cycle, select a TC member who is not standing