[ironic][elections][ptl] Leaving the PTL role
Hello ironicers! It's been a pleasure and an honor to serve as PTL for 2 cycles. I've decided to not be a candidate for the next cycle, mainly because of time constraints. Huge thanks to the community for having me, I hope in the future I'll be able to repeat the experience. Ciao! Riccardo #irc rpittau
Thanks Riccardo for your service as PTL over the last year. I will say here that I do not intend on running for Ironic PTL this cycle. If we have no volunteers, we may be a good candidate for DPL since typically in reality we all pitch in for PTL-like tasks anyway. -Jay Faulkner On 2/6/25 7:27 AM, Riccardo Pittau wrote:
Hello ironicers!
It's been a pleasure and an honor to serve as PTL for 2 cycles. I've decided to not be a candidate for the next cycle, mainly because of time constraints. Huge thanks to the community for having me, I hope in the future I'll be able to repeat the experience.
Ciao! Riccardo
#irc rpittau
At today's Ironic meeting, many cores were around to discuss a potential move to the DPL model. This allows the project to continue our practice of distributed leadership without having to have a song and dance every six months about who will bear the PTL title :). https://governance.openstack.org/tc/reference/distributed-project-leadership... documents required and optional roles for DPL model. These are listed below for clarity: (required) - Release liason - tact-sig liason (CI) - Security liason - TC liason (optional) - Events liason - Project Update/Onboarding liason - Meeting Facilitator - Bug Deputy - RFE Coordinator I'd suggest that for Ironic purposes, we obviously need someone in each of the required roles; but I'd strongly suggest we also assign an events liason so we have a single point of responsibility for PTG signup and planning. Along these lines, if we'd like Ironic to go to DPL, I will volunteer to be the Security liason. One concern raised in the Ironic meeting is that the DPL is traditionally associated with low-activity projects; Ironic is an extremely active project with multiple senior developers working on it -- our move to DPL is simply meant to model our actual working mode with everyone pitching in as needed. What do folks think? If you are in favor of a move to DPL, I'd suggest volunteering for a liason role. Thanks, Jay Faulkner On 2/6/25 7:27 AM, Riccardo Pittau wrote:
Hello ironicers!
It's been a pleasure and an honor to serve as PTL for 2 cycles. I've decided to not be a candidate for the next cycle, mainly because of time constraints. Huge thanks to the community for having me, I hope in the future I'll be able to repeat the experience.
Ciao! Riccardo
#irc rpittau
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. [*] https://governance.openstack.org/tc/reference/distributed-project-leadership... -- Jeremy Stanley
---- 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. -gmann
[*] https://governance.openstack.org/tc/reference/distributed-project-leadership...
-- Jeremy Stanley
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
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. 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 >
---- 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? -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 >
---- 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 >
On 2025-02-10 18:59:07 +0000 (+0000), Sean Mooney wrote: [...]
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. [...]
Liaisons are tracked in the governance repository, so any adjustment to the list of liaisons for a project would require a change there. The (more recent) process of requesting liaisons to re-opt-in was introduced to solve the problem where DPL projects would set liaisons and then never update them, even when those individuals ceased to actively participate in the community for years. This becomes relevant when, for example, the VMT is getting no response from a security review team on a report of a suspected vulnerability and wants to escalate to the security liaison for the project. Allowing the TC to discover in advance that there is no active security liaison helps OpenStack side-step such situations before they become a bigger problem. There are a number of possible ways to go about it, but for now the workflow the TC has adopted is to propose a change reverting the project to the PTL model and then get its liaisons to -1 the change if they intend to continue serving in that role. If they all -1 then the change is abandoned; if only some -1 and others can't be reached then a different change is needed in order to replace the inactive liaisons with active volunteers. If no liaisons -1 the change prior to the start of PTL elections then the team reverts to PTL model, and if it subsequently gets no PTL nominations then the TC has good reason to consider the entire project inactive and proceed with its retirement. -- Jeremy Stanley
hi Jay, Thank you for starting this thread, I think Ironic has already moved silently to a structure similar to DPL recently, so I'm ok with giving that a try. As discussed on IRC I'm happy to keep my role as Release liaison. I'm also up to help on other aspects as I did in the past, but I'll let others weigh in before proposing myself for more roles! Ciao! Riccardo On Mon, Feb 10, 2025 at 5:36 PM Jay Faulkner <jay@gr-oss.io> wrote:
At today's Ironic meeting, many cores were around to discuss a potential move to the DPL model. This allows the project to continue our practice of distributed leadership without having to have a song and dance every six months about who will bear the PTL title :).
https://governance.openstack.org/tc/reference/distributed-project-leadership... documents required and optional roles for DPL model. These are listed below for clarity:
(required)
- Release liason
- tact-sig liason (CI)
- Security liason
- TC liason
(optional)
- Events liason
- Project Update/Onboarding liason
- Meeting Facilitator
- Bug Deputy
- RFE Coordinator
I'd suggest that for Ironic purposes, we obviously need someone in each of the required roles; but I'd strongly suggest we also assign an events liason so we have a single point of responsibility for PTG signup and planning.
Along these lines, if we'd like Ironic to go to DPL, I will volunteer to be the Security liason.
One concern raised in the Ironic meeting is that the DPL is traditionally associated with low-activity projects; Ironic is an extremely active project with multiple senior developers working on it -- our move to DPL is simply meant to model our actual working mode with everyone pitching in as needed.
What do folks think? If you are in favor of a move to DPL, I'd suggest volunteering for a liason role.
Thanks, Jay Faulkner
On 2/6/25 7:27 AM, Riccardo Pittau wrote:
Hello ironicers!
It's been a pleasure and an honor to serve as PTL for 2 cycles. I've decided to not be a candidate for the next cycle, mainly because of time constraints. Huge thanks to the community for having me, I hope in the future I'll be able to repeat the experience.
Ciao! Riccardo
#irc rpittau
Hello ironicers, Sorry I couldn't join the meeting yesterday (I'm on PTO). I'm more than happy to help in liaisons, I think I can help as either in any of this three: Release liaison , tact-sig liaison, Events liaison Em ter., 11 de fev. de 2025 às 06:24, Riccardo Pittau <elfosardo@gmail.com> escreveu:
hi Jay,
Thank you for starting this thread, I think Ironic has already moved silently to a structure similar to DPL recently, so I'm ok with giving that a try.
As discussed on IRC I'm happy to keep my role as Release liaison. I'm also up to help on other aspects as I did in the past, but I'll let others weigh in before proposing myself for more roles!
Ciao! Riccardo
On Mon, Feb 10, 2025 at 5:36 PM Jay Faulkner <jay@gr-oss.io> wrote:
At today's Ironic meeting, many cores were around to discuss a potential move to the DPL model. This allows the project to continue our practice of distributed leadership without having to have a song and dance every six months about who will bear the PTL title :).
https://governance.openstack.org/tc/reference/distributed-project-leadership... documents required and optional roles for DPL model. These are listed below for clarity:
(required)
- Release liason
- tact-sig liason (CI)
- Security liason
- TC liason
(optional)
- Events liason
- Project Update/Onboarding liason
- Meeting Facilitator
- Bug Deputy
- RFE Coordinator
I'd suggest that for Ironic purposes, we obviously need someone in each of the required roles; but I'd strongly suggest we also assign an events liason so we have a single point of responsibility for PTG signup and planning.
Along these lines, if we'd like Ironic to go to DPL, I will volunteer to be the Security liason.
One concern raised in the Ironic meeting is that the DPL is traditionally associated with low-activity projects; Ironic is an extremely active project with multiple senior developers working on it -- our move to DPL is simply meant to model our actual working mode with everyone pitching in as needed.
What do folks think? If you are in favor of a move to DPL, I'd suggest volunteering for a liason role.
Thanks, Jay Faulkner
On 2/6/25 7:27 AM, Riccardo Pittau wrote:
Hello ironicers!
It's been a pleasure and an honor to serve as PTL for 2 cycles. I've decided to not be a candidate for the next cycle, mainly because of time constraints. Huge thanks to the community for having me, I hope in the future I'll be able to repeat the experience.
Ciao! Riccardo
#irc rpittau
-- *Att[]'s* *Iury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Ironic Core* *Senior Software Engineer at Red Hat Brazil* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory@gmail.com <iurygregory@gmail.com>*
I'm happy to become the tact-sig liaison if there are no better takers. I think I still have a pretty solid mental model of our CI jobs, as well as hands-on experience in fixing them :) As an aside, the Bug Deputy role is distributed itself in our case, right? Dmitry On 2/10/25 5:35 PM, Jay Faulkner wrote:
At today's Ironic meeting, many cores were around to discuss a potential move to the DPL model. This allows the project to continue our practice of distributed leadership without having to have a song and dance every six months about who will bear the PTL title :).
https://governance.openstack.org/tc/reference/distributed-project-leadership... documents required and optional roles for DPL model. These are listed below for clarity:
(required)
- Release liason
- tact-sig liason (CI)
- Security liason
- TC liason
(optional)
- Events liason
- Project Update/Onboarding liason
- Meeting Facilitator
- Bug Deputy
- RFE Coordinator
I'd suggest that for Ironic purposes, we obviously need someone in each of the required roles; but I'd strongly suggest we also assign an events liason so we have a single point of responsibility for PTG signup and planning.
Along these lines, if we'd like Ironic to go to DPL, I will volunteer to be the Security liason.
One concern raised in the Ironic meeting is that the DPL is traditionally associated with low-activity projects; Ironic is an extremely active project with multiple senior developers working on it -- our move to DPL is simply meant to model our actual working mode with everyone pitching in as needed.
What do folks think? If you are in favor of a move to DPL, I'd suggest volunteering for a liason role.
Thanks, Jay Faulkner
On 2/6/25 7:27 AM, Riccardo Pittau wrote:
Hello ironicers!
It's been a pleasure and an honor to serve as PTL for 2 cycles. I've decided to not be a candidate for the next cycle, mainly because of time constraints. Huge thanks to the community for having me, I hope in the future I'll be able to repeat the experience.
Ciao! Riccardo
#irc rpittau
On 2/11/25 10:14 AM, Dmitry Tantsur wrote:
I'm happy to become the tact-sig liaison if there are no better takers. I think I still have a pretty solid mental model of our CI jobs, as well as hands-on experience in fixing them :)
As an aside, the Bug Deputy role is distributed itself in our case, right?
Yeah, I would suggest we keep this as a rotating role; even if lately CID has been picking it up more often than not :). By my calculations we have the following volunteers: - Release Liason: Riccardo - tact-sig Liason: Dmitry - Security Liason: Jay (me) - TC Liason: likely Doug (cardoe) but need to check with him - Events Liason: Iury I think this sounds like enough consensus to move forward; we can add more liasons if needed later. I suggest a plan where we expect Ironic to go through the leaderless process to get DPL. Unless there is objection, I will monitor and if anyone unexpectedly runs for Ironic PTL, I will also submit my nomination for PTL on a platform of "make Ironic DPL". I doubt that will be needed though. Does this ound OK to everyone? -Jay
Dmitry
On 2/10/25 5:35 PM, Jay Faulkner wrote:
At today's Ironic meeting, many cores were around to discuss a potential move to the DPL model. This allows the project to continue our practice of distributed leadership without having to have a song and dance every six months about who will bear the PTL title :).
https://governance.openstack.org/tc/reference/distributed-project-leadership... documents required and optional roles for DPL model. These are listed below for clarity:
(required)
- Release liason
- tact-sig liason (CI)
- Security liason
- TC liason
(optional)
- Events liason
- Project Update/Onboarding liason
- Meeting Facilitator
- Bug Deputy
- RFE Coordinator
I'd suggest that for Ironic purposes, we obviously need someone in each of the required roles; but I'd strongly suggest we also assign an events liason so we have a single point of responsibility for PTG signup and planning.
Along these lines, if we'd like Ironic to go to DPL, I will volunteer to be the Security liason.
One concern raised in the Ironic meeting is that the DPL is traditionally associated with low-activity projects; Ironic is an extremely active project with multiple senior developers working on it -- our move to DPL is simply meant to model our actual working mode with everyone pitching in as needed.
What do folks think? If you are in favor of a move to DPL, I'd suggest volunteering for a liason role.
Thanks, Jay Faulkner
On 2/6/25 7:27 AM, Riccardo Pittau wrote:
Hello ironicers!
It's been a pleasure and an honor to serve as PTL for 2 cycles. I've decided to not be a candidate for the next cycle, mainly because of time constraints. Huge thanks to the community for having me, I hope in the future I'll be able to repeat the experience.
Ciao! Riccardo
#irc rpittau
Yes. I volunteer as the TC liaison for Ironic. — Doug
On Feb 11, 2025, at 12:36 PM, Jay Faulkner <jay@gr-oss.io> wrote:
On 2/11/25 10:14 AM, Dmitry Tantsur wrote:
I'm happy to become the tact-sig liaison if there are no better takers. I think I still have a pretty solid mental model of our CI jobs, as well as hands-on experience in fixing them :)
As an aside, the Bug Deputy role is distributed itself in our case, right?
Yeah, I would suggest we keep this as a rotating role; even if lately CID has been picking it up more often than not :).
By my calculations we have the following volunteers:
- Release Liason: Riccardo
- tact-sig Liason: Dmitry
- Security Liason: Jay (me)
- TC Liason: likely Doug (cardoe) but need to check with him
- Events Liason: Iury
I think this sounds like enough consensus to move forward; we can add more liasons if needed later.
I suggest a plan where we expect Ironic to go through the leaderless process to get DPL. Unless there is objection, I will monitor and if anyone unexpectedly runs for Ironic PTL, I will also submit my nomination for PTL on a platform of "make Ironic DPL". I doubt that will be needed though.
Does this ound OK to everyone?
-Jay
Dmitry
On 2/10/25 5:35 PM, Jay Faulkner wrote:
At today's Ironic meeting, many cores were around to discuss a potential move to the DPL model. This allows the project to continue our practice of distributed leadership without having to have a song and dance every six months about who will bear the PTL title :).
https://governance.openstack.org/tc/reference/distributed-project-leadership... documents required and optional roles for DPL model. These are listed below for clarity:
(required)
- Release liason
- tact-sig liason (CI)
- Security liason
- TC liason
(optional)
- Events liason
- Project Update/Onboarding liason
- Meeting Facilitator
- Bug Deputy
- RFE Coordinator
I'd suggest that for Ironic purposes, we obviously need someone in each of the required roles; but I'd strongly suggest we also assign an events liason so we have a single point of responsibility for PTG signup and planning.
Along these lines, if we'd like Ironic to go to DPL, I will volunteer to be the Security liason.
One concern raised in the Ironic meeting is that the DPL is traditionally associated with low-activity projects; Ironic is an extremely active project with multiple senior developers working on it -- our move to DPL is simply meant to model our actual working mode with everyone pitching in as needed.
What do folks think? If you are in favor of a move to DPL, I'd suggest volunteering for a liason role.
Thanks, Jay Faulkner
On 2/6/25 7:27 AM, Riccardo Pittau wrote:
Hello ironicers!
It's been a pleasure and an honor to serve as PTL for 2 cycles. I've decided to not be a candidate for the next cycle, mainly because of time constraints. Huge thanks to the community for having me, I hope in the future I'll be able to repeat the experience.
Ciao! Riccardo
#irc rpittau
(this time sent from the right address) Yes! I would be happy to volunteer as the TC liason. — Doug
On Feb 11, 2025, at 12:36 PM, Jay Faulkner <jay@gr-oss.io> wrote:
On 2/11/25 10:14 AM, Dmitry Tantsur wrote:
I'm happy to become the tact-sig liaison if there are no better takers. I think I still have a pretty solid mental model of our CI jobs, as well as hands-on experience in fixing them :)
As an aside, the Bug Deputy role is distributed itself in our case, right?
Yeah, I would suggest we keep this as a rotating role; even if lately CID has been picking it up more often than not :).
By my calculations we have the following volunteers:
- Release Liason: Riccardo
- tact-sig Liason: Dmitry
- Security Liason: Jay (me)
- TC Liason: likely Doug (cardoe) but need to check with him
- Events Liason: Iury
I think this sounds like enough consensus to move forward; we can add more liasons if needed later.
I suggest a plan where we expect Ironic to go through the leaderless process to get DPL. Unless there is objection, I will monitor and if anyone unexpectedly runs for Ironic PTL, I will also submit my nomination for PTL on a platform of "make Ironic DPL". I doubt that will be needed though.
Does this ound OK to everyone?
-Jay
Dmitry
On 2/10/25 5:35 PM, Jay Faulkner wrote:
At today's Ironic meeting, many cores were around to discuss a potential move to the DPL model. This allows the project to continue our practice of distributed leadership without having to have a song and dance every six months about who will bear the PTL title :).
https://governance.openstack.org/tc/reference/distributed-project-leadership... documents required and optional roles for DPL model. These are listed below for clarity:
(required)
- Release liason
- tact-sig liason (CI)
- Security liason
- TC liason
(optional)
- Events liason
- Project Update/Onboarding liason
- Meeting Facilitator
- Bug Deputy
- RFE Coordinator
I'd suggest that for Ironic purposes, we obviously need someone in each of the required roles; but I'd strongly suggest we also assign an events liason so we have a single point of responsibility for PTG signup and planning.
Along these lines, if we'd like Ironic to go to DPL, I will volunteer to be the Security liason.
One concern raised in the Ironic meeting is that the DPL is traditionally associated with low-activity projects; Ironic is an extremely active project with multiple senior developers working on it -- our move to DPL is simply meant to model our actual working mode with everyone pitching in as needed.
What do folks think? If you are in favor of a move to DPL, I'd suggest volunteering for a liason role.
Thanks, Jay Faulkner
On 2/6/25 7:27 AM, Riccardo Pittau wrote:
Hello ironicers!
It's been a pleasure and an honor to serve as PTL for 2 cycles. I've decided to not be a candidate for the next cycle, mainly because of time constraints. Huge thanks to the community for having me, I hope in the future I'll be able to repeat the experience.
Ciao! Riccardo
#irc rpittau
Side note inline On 2/11/25 7:36 PM, Jay Faulkner wrote:
On 2/11/25 10:14 AM, Dmitry Tantsur wrote:
I'm happy to become the tact-sig liaison if there are no better takers. I think I still have a pretty solid mental model of our CI jobs, as well as hands-on experience in fixing them :)
As an aside, the Bug Deputy role is distributed itself in our case, right?
Yeah, I would suggest we keep this as a rotating role; even if lately CID has been picking it up more often than not :).
By my calculations we have the following volunteers:
- Release Liason: Riccardo
- tact-sig Liason: Dmitry
- Security Liason: Jay (me)
- TC Liason: likely Doug (cardoe) but need to check with him
- Events Liason: Iury
I think this sounds like enough consensus to move forward; we can add more liasons if needed later.
I suggest a plan where we expect Ironic to go through the leaderless process to get DPL. Unless there is objection, I will monitor and if anyone unexpectedly runs for Ironic PTL, I will also submit my nomination for PTL on a platform of "make Ironic DPL". I doubt that will be needed though.
I doubt it too, but that's an interesting shortcoming of the DPL model: even if the team decides to go DPL, anyone qualifying can force their PTL-ship on the team. Like, literally a random contributor can get this important role and the team can do nothing about it? Needs improving IMO. Dmitry
Does this ound OK to everyone?
-Jay
Dmitry
On 2/10/25 5:35 PM, Jay Faulkner wrote:
At today's Ironic meeting, many cores were around to discuss a potential move to the DPL model. This allows the project to continue our practice of distributed leadership without having to have a song and dance every six months about who will bear the PTL title :).
https://governance.openstack.org/tc/reference/distributed-project-leadership... documents required and optional roles for DPL model. These are listed below for clarity:
(required)
- Release liason
- tact-sig liason (CI)
- Security liason
- TC liason
(optional)
- Events liason
- Project Update/Onboarding liason
- Meeting Facilitator
- Bug Deputy
- RFE Coordinator
I'd suggest that for Ironic purposes, we obviously need someone in each of the required roles; but I'd strongly suggest we also assign an events liason so we have a single point of responsibility for PTG signup and planning.
Along these lines, if we'd like Ironic to go to DPL, I will volunteer to be the Security liason.
One concern raised in the Ironic meeting is that the DPL is traditionally associated with low-activity projects; Ironic is an extremely active project with multiple senior developers working on it -- our move to DPL is simply meant to model our actual working mode with everyone pitching in as needed.
What do folks think? If you are in favor of a move to DPL, I'd suggest volunteering for a liason role.
Thanks, Jay Faulkner
On 2/6/25 7:27 AM, Riccardo Pittau wrote:
Hello ironicers!
It's been a pleasure and an honor to serve as PTL for 2 cycles. I've decided to not be a candidate for the next cycle, mainly because of time constraints. Huge thanks to the community for having me, I hope in the future I'll be able to repeat the experience.
Ciao! Riccardo
#irc rpittau
On 2025-02-13 09:20:23 +0000 (+0000), Dmitry Tantsur wrote: [...]
I doubt it too, but that's an interesting shortcoming of the DPL model: even if the team decides to go DPL, anyone qualifying can force their PTL-ship on the team. Like, literally a random contributor can get this important role and the team can do nothing about it?
Needs improving IMO. [...]
Note that this is only the case if the team waits until *during* a PTL election to decide they want to switch to a DPL model. If it had instead come up a couple of weeks back, Ironic would already be DPL by now with no risk that an active Ironic contributor nominates themselves to be the Ironic PTL following the rules for the election that's already underway. Paying attention to election schedules is important. The TC could also be asked to overturn the results of the election. While I don't think that's ever happened in the history of OpenStack, PTLs serve at the discretion of the TC, and it's the TC who sets the rules for how they're elected and when. At most, overturning a PTL election might require some new policy get added to the TC Charter, which would need a 2/3 majority to approve. -- Jeremy Stanley
On Thu, Feb 13, 2025 at 6:31 AM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2025-02-13 09:20:23 +0000 (+0000), Dmitry Tantsur wrote: [...]
I doubt it too, but that's an interesting shortcoming of the DPL model: even if the team decides to go DPL, anyone qualifying can force their PTL-ship on the team. Like, literally a random contributor can get this important role and the team can do nothing about it?
Needs improving IMO. [...]
Note that this is only the case if the team waits until *during* a PTL election to decide they want to switch to a DPL model. If it had instead come up a couple of weeks back, Ironic would already be DPL by now with no risk that an active Ironic contributor nominates themselves to be the Ironic PTL following the rules for the election that's already underway. Paying attention to election schedules is important.
++ This is 100% a drop on our part for not worrying about how Ironic is going to be led next cycle until the last minute. It's an easy trap to fall into for sure though.
The TC could also be asked to overturn the results of the election. While I don't think that's ever happened in the history of OpenStack, PTLs serve at the discretion of the TC, and it's the TC who sets the rules for how they're elected and when. At most, overturning a PTL election might require some new policy get added to the TC Charter, which would need a 2/3 majority to approve.
This would be my realistic expectation of what would happen if we got to that point; but also I'd try to avoid putting the TC into that situation (hence the "I'll run opposing if needed" statement). -Jay
-- Jeremy Stanley
participants (9)
-
Dmitry Tantsur
-
Doug Goldstein
-
Doug Goldstein
-
Ghanshyam Mann
-
Iury Gregory
-
Jay Faulkner
-
Jeremy Stanley
-
Riccardo Pittau
-
Sean Mooney