---- On Mon, 10 Feb 2025 11:05:36 -0800 Jay Faulkner wrote ---
Sean,
The structure of DPL was modified here: https://opendev.org/openstack/governance/commit/0a7df7f5e0c9e64fb4d60fde0808... (April 2024) to add a reset each cycle. Essentially there was a concern that while PTL had a recurring check-in point to ensure project activity; DPL had no such check-in. It was explicitly added to ensure nothing further would slip through the cracks.
Yes, DPL model reset process is mainly to check and maintain the active liaisons list. It did not mean to add election-like overhead to projects. Seeing the result of this cycle's DPL model reset[1], I feel this is a good process and keeps the DPL model liaisons list up to date.
To make it less overhead to DPl projects, maybe we can increase the duration of reset/checks from 1 cycle to 2 cycles (reset DPL model every 2 cycles). Opinion?
On 10/02/2025 19:13, Ghanshyam Mann wrote: perhaps i feel like the old way of do the checking in on the mailing list or a teams irc meeting should have been sufficient. if not then we need to document whose role it is to create all the patches required the reference implies it the responsibility of the TC liaison to do this which i would assume also includes opening the project for election nominations ectra as need for PTL project? the tc liasion was not one of the required or defiend roles based on the resolution eitehr so that was also kind of confusing. looking at https://opendev.org/openstack/governance/commit/0a7df7f5e0c9e64fb4d60fde0808... it update reference/distributed-project-leadership.rst <https://opendev.org/openstack/governance/commit/0a7df7f5e0c9e64fb4d60fde0808f8594d3d1f72#diff-91138d36a842f370e7f1997e53a31de19c590c92> but did not modify https://github.com/openstack/governance/blob/master/resolutions/20200803-dis... so the two are now inconsistent with each other in a number of ways. i personally woudl have voted agaisnt the wordign change but since it was made i feel it should be done consistently in both places given the existing resolution has not been superceeded. https://governance.openstack.org/tc/resolutions/20200803-distributed-project... is not in https://governance.openstack.org/tc/resolutions/superseded/index.html were the resolutions and reference differ i would always assume the resolution has precedence. that explains the confusion i was consulting the resolution only since we have normally updated them as process change and didn't expect to need to look at the reference section too for anything defiend in a governace resolution. can we consolidate these documents somehow? perhaps mark the resolution as superceeded? or perhaps reference the new document form the original resolution and basically say for future update follow the reference? it looks like the new docuemnt was added in https://github.com/openstack/governance/commit/7d2e526c9ccac2e9a1e7c812c88c4...
-gmann
Thanks, Jay Faulkner
On 2/10/25 10:59 AM, Sean Mooney wrote:
On 10/02/2025 18:26, Ghanshyam Mann wrote:
---- On Mon, 10 Feb 2025 09:09:56 -0800 Jeremy Stanley wrote --- > On 2025-02-10 08:35:38 -0800 (-0800), Jay Faulkner wrote: > > At today's Ironic meeting, many cores were around to discuss a > > potential move to the DPL model. > [...] > > As the process for opting into distributed leadership[*] specifies, > "All requests should be merged before the election nominations start > otherwise request will be postponed to the next cycle." Also, "If a > project team has no candidate for PTL, the TC will still evaluate > the future of the team and its deliverables, [...and possibly...] > convert the project to a distributed leadership." > > So from a process perspective, it's too late for the Ironic team to > officially opt into a DPL model for this election, but if nobody is > nominated for PTL then the TC could still switch it to DPL. > Alternatively, you could start the cycle with an interim PTL who > leads the process of of switching the team to DPL shortly after the > election concludes and the new TC is seated. The minimum timeframe > will probably be the same either way.
I think interim PTL might be a little overhead here. We can keep it simple, and TC can move Ironic to DPL after the election (if no PTL candidate). And if there is a PTL candidate, the ironic team can switch it to the DPL model anytime in the cycle. But yes, we cannot change it during the election period.
one other aside while the DPL model allow you to not have an election each year the process was of opting in to the DPL model has some conflicting requirements
specificaly the liasison assingment duration clauses
https://github.com/openstack/governance/blob/master/resolutions/20200803-dis...
``` Liaison assignment duration https://github.com/openstack/governance/blob/master/resolutions/20200803-distributed-project-leadership.rst#liaison-assignment-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.
```
it was a surprise to me tha twe had to opt in again for watcher 2025.2
so to me the way we have implemnted the liaison-assignment-duration section is not in keeping with the resolotion "rules as written"
in that its is not done by asking if the liasons are still valid on the mailing list
it was done by reseting watcher back to ptl model
https://github.com/openstack/governance/commit/11a7467147af5429703b36d312698...
and and readdopting the ptl model
https://github.com/openstack/governance/commit/8690a1ced8868d4bdd59f3c49d160...
with the rolecall votes ectra that requires in the governance repo.
this effectively creates a similar level of overhead as the election.
my personal recollection may be off but i thought one of the original motivation was to not require project to make change to the grovernace repo each cycle unless the the Liaison assignment needed to be modifed.
watcher did need to update them but updating liasons can happen at any poitn during the cycle and is not impacteed by the election and leadadeship model selection deadlines.
to this is in conflict with the process-for-opting-in-to-distributed-leadership section. that is only describing movign between models and it does not apply IMO if a project is maintaining the same model ether the DPL or PTL across release. so it would be good to calrify that if more proejct are considering moving to DPL since i don't think the current process is correct. i didnt push back on this too stronly this release because as i said we were updating the liasons anyway for wather.
the process-for-opting-in-to-distributed-leadership section does allow the TC to do the convertion if there is no candiate
https://github.com/openstack/governance/blob/master/resolutions/20200803-dis...
```
The distributed leadership model is only requested explicitly. If a project team has no candidate for PTL, the TC will still evaluate the future of the team and its deliverables, with now an extra option (on top of stopping the project or appointing a PTL): convert the project to a distributed leadership with the help of the project team members.
```
so i agree with gmann that if no one run the convertion could happen after the election
https://github.com/openstack/governance/commit/dd0168720be6eb201b22d231946fb... added the restriction that once an election has started it cant be changed
during the election period.
-gmann
> > [*] https://governance.openstack.org/tc/reference/distributed-project-leadership... > > -- > Jeremy Stanley >