| TheJulia | And to make that change now, the “business” view consequences may be undesirable. | 06:31 |
|---|---|---|
| stephenfin | cardoe: You may have got to this conclusion already, but I took a shortcut and has nova-core ~= nova-approvers. The ideal course of action would be to rename nova-core to nova-approvers but I don't think that's possible on the Gerrit side | 11:28 |
| * stephenfin reads through the rest of the convo | 11:29 | |
| fungi | stephenfin: cardoe: yes, i also saw there was already a wip change that would implement the nova-approvers group if desired: https://review.opendev.org/c/openstack/project-config/+/1003848 | 12:51 |
| opendevreview | Stephen Finucane proposed openstack/governance master: doc: Add PTL doc https://review.opendev.org/c/openstack/governance/+/1005080 | 16:02 |
| stephenfin | tc-members: that's my attempt to address bauzas' comment that many of the responsibilities of the PTL are not documented in the Governance docs. Please feel free to review/rip it apart as necessary | 16:04 |
| opendevreview | Stephen Finucane proposed openstack/governance master: doc: Add PTL doc https://review.opendev.org/c/openstack/governance/+/1005080 | 16:08 |
| gouthamr | ty stephenfin | 16:21 |
| opendevreview | Ghanshyam Maan proposed openstack/governance master: Add frickler as QA release liaison https://review.opendev.org/c/openstack/governance/+/1005091 | 16:56 |
| gouthamr | frickler: will get this in once you +1 ^ | 18:04 |
| opendevreview | Stephen Finucane proposed openstack/governance master: doc: Add PTL doc https://review.opendev.org/c/openstack/governance/+/1005080 | 18:29 |
| opendevreview | Stephen Finucane proposed openstack/governance master: Update location of liaison reference https://review.opendev.org/c/openstack/governance/+/1005109 | 18:29 |
| sean-k-mooney | from my peresecite the scope of the PTL is the union of the already documented laison roles | 18:56 |
| sean-k-mooney | although it is good to clarify that | 18:56 |
| sean-k-mooney | so PTL == release + tact-sig + secuirty +event + Project Update/Onboarding liasion | 18:58 |
| sean-k-mooney | and in those roels they also act as Meeting Facilitator, Bug Deputy and RFE Coordinator | 18:59 |
| sean-k-mooney | tehre shoudl not be a role or capablity in the PTL model that is not reflected in the DPL model via teh decomposed roles | 19:00 |
| sean-k-mooney | the only real diffent is that in the PTL model there is a default for those roles to be assgiend to the PTL unless a liason is nominated by them | 19:00 |
| fungi | sean-k-mooney: agreed, and that's the approach the new revision more or less seems to take (though i'm not done rereading it yet) | 19:01 |
| JayF | sean-k-mooney: fungi: One thing that's always bugged me: if an Ironic contributor was unhappy we were DPL and wanted to change, how does that happen mechanically in our model? | 19:10 |
| sean-k-mooney | so it revert before the election each cycle today | 19:11 |
| sean-k-mooney | so they could technially nominate for the ptl role | 19:11 |
| sean-k-mooney | at which point there woudl be an election, at least that is my understnading | 19:12 |
| fungi | teams only revert to ptl if there are insufficient dpl volunteers expressing interest in covering the next cycle | 19:12 |
| sean-k-mooney | obvioulsy you could run agaisnt them on the plantform of "readdopt dpl" | 19:12 |
| fungi | i think the question is how to handle a situation where there are dpls and a majority of the contributors to the project is unhappy with them | 19:13 |
| JayF | Yeah, we flipped that so that DPL teams wouldn't technically be considered leaderless | 19:13 |
| JayF | I think the answer in practice would likely be a -1 on the DPL renewal by someone outside the DPL team | 19:13 |
| JayF | to force an election | 19:13 |
| JayF | but a situation we might wanna consider if stephenfin ^ is trying to close holes in the documentation | 19:13 |
| sean-k-mooney | ya that the pargmtic approch | 19:13 |
| fungi | yes, basically it's something that doesn't have an established process today so would be escalated to the tc | 19:14 |
| fungi | keep in mind that the tc is the backstop for all of this anyway, so that not every rare scenario has to be described in governance documents | 19:14 |
| fungi | the thing to ask yourself is, "how often will it come up and is it worth adding to the growing pile of governance information everyone has to read and keep updated?" | 19:15 |
| JayF | fungi: I was asking a similar but slightly different oriented question: "How clear is it to someone with less veterancy in the project?" | 19:16 |
| fungi | usually, unless something like that comes up often enough to create undue burden on the tc members, the answer is "no" | 19:16 |
| fungi | the "process" is that someone brings up these concerns with the tc and someone goes looking for earlier precedent (if any exists) to inform the tc's decision on the matter, and if it comes up again and again then someone writes that down and the tc votes to make it an official process | 19:17 |
| sean-k-mooney | via the resolution proces right and a formal role call vote to adopt or reject it | 19:19 |
| gouthamr | +1 | 19:19 |
| fungi | right now we do have a described process for a team's liaisons voluntarily switching it to ptl model, but no process for the contributors doing it against the will of at least one current liaison | 19:20 |
| fungi | mainly because the latter has never happened. there are countless things that have never happened that we could document processes for, but it's a waste of time and effort and creates unnecessary maintenance burden | 19:22 |
| sean-k-mooney | i think if we ever got to that point there is a larger problem with the health of teh porject driving that | 19:22 |
| fungi | yes exactly, the tc is going to want to be involved in that situation regardless | 19:24 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!