Add DPL model & liaison reset policy

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

reference/distributed-project-leadership.rst

@@ -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,9 +174,6 @@ 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.
 
@@ -183,6 +185,11 @@ including the :repo:`openstack/releases/src/branch/master/data/release_liaisons.
 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

reference/tc-chair-responsibilities.rst

@@ -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