| *** bauzas_ is now known as bauzas | 00:55 | |
| *** bauzas_ is now known as bauzas | 06:15 | |
| *** bauzas_ is now known as bauzas | 06:43 | |
| *** bauzas_ is now known as bauzas | 11:48 | |
| *** elodilles is now known as elodilles_ooo | 12:31 | |
| opendevreview | Jens Harbott proposed openstack/contributor-guide master: Update IRC document https://review.opendev.org/c/openstack/contributor-guide/+/926511 | 12:59 |
|---|---|---|
| opendevreview | Merged openstack/governance master: Reset the DPL model for Oslo project https://review.opendev.org/c/openstack/governance/+/925834 | 16:26 |
| *** bauzas_ is now known as bauzas | 18:39 | |
| gmann | gouthamr: I do not think there will be any conflict if we have -1 from a few of the liaison on DPL reset state and we need to hold to merge that. If so then our main goal of DPL model is gone and we can remove this policy itself. if we would like to handle this situation with 'do not reset state' then I will prefer we modify/add this situation handling in our policy | 18:55 |
| gmann | otherwise it create confusion to all of us on 'what and when to merge the things' | 18:55 |
| gmann | and about oslo PTL, this is the change where we can discuss about it https://review.opendev.org/c/openstack/governance/+/926154/1 | 18:55 |
| gmann | that is why I think merging DPL reset state will create any issue. | 18:56 |
| gmann | it can be blocked/abandon only if all liaison are -1 so that we can get confirmation that all liaisons are active and would like to stay as DPL otherwise reset state and then team decide the further leadership model is right way to do | 18:57 |
| gmann | gouthamr: I think you are mixing two things together, and that is why there is confusion 1. reset DPL state 2. what is next leadership model. IMO, if we keep these two tasks separate, then it will be easy to implement the policy. | 19:10 |
| gmann | if we hold the reset state until the next leadership is decided then we are stuck in the situation of unmonitored DPL leadership/role | 19:13 |
| JayF | This can have a ternary outcome, yeah? | 19:18 |
| JayF | Option 1: All liasons actively affirm DPL, state is kept. | 19:18 |
| JayF | Option 2: One or more liasons actively reject DPL, project goes up for election | 19:18 |
| JayF | Option 3: No response by end of PTL nomination period, (potentially?) project goes to leaderless and is handled that way. | 19:19 |
| JayF | Just saying we can differentiate yes/no/[timeout] cases | 19:19 |
| JayF | and the goal if for us to hit that "timeout" as the TC before a user or securtiy-bug-reporter does | 19:19 |
| JayF | so in that case, going DPL->Leaderless instead of DPL->PTL election would still be a MASSIVE improvement over the year-ago status quo IMO | 19:20 |
| gmann | yeah, and that is what our current policy cover these three options | 19:20 |
| fungi | option 4: new liaison volunteer(s) edit the proposed change to satisfy dpl requirements and that merges | 19:20 |
| gmann | we have to be keeping DPL only if all liaisons are ok with that in any other situation either PTL or leaderless | 19:20 |
| gmann | sure but no harm is proposing the new change with new liaisons but editing reset change is also not bad idea | 19:21 |
| fungi | option 4 is basically just option 1 if worded a little differently | 19:21 |
| JayF | fungi: I've always been weirded out by that, because it bypasses any election. | 19:22 |
| gmann | I am more concerned of we wait to reset/adopt state which is nothing but the same as before 'unmonitored DPL projects' | 19:22 |
| JayF | fungi: leaderless->DPL implies "nobody wanted to step up, so now we have to fill the seat". DPL changing doesn't have that same implication. | 19:23 |
| fungi | JayF: dpls already bypass electing because they can change at any time | 19:23 |
| JayF | fungi: not saying it's wrong, or that I disagree with it in practice today, just htat it's a gap that *could be* exploited | 19:23 |
| fungi | the transition from ptl to dpl is well documented, but there's no real process laid out for liaison replacement | 19:24 |
| JayF | Yeah. I think there's an unwritten understanding that leadership in OpenStack is less "power" and more "responsibility" so to speak | 19:25 |
| fungi | "The process by which each project team chooses these liaisons is left to the 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." | 19:25 |
| fungi | https://governance.openstack.org/tc/reference/distributed-project-leadership.html#liaison-selection | 19:25 |
| fungi | so, yeah, i guess it would still be typical for the team to run a poll to replace a liaison when someone steps down, though short-circuiting that if there is only one volunteer | 19:26 |
| gmann | I am not sure what is missing in this process? 'liaison replacement' is by update the projects.yaml with new liaison +1 | 19:26 |
| JayF | gmann: Prefacing this with: I don't think we need to action it; just an observation -- when changing DPL liasons, there's no "loop in the contributors" moment | 19:27 |
| gmann | and there can be mulitple liaisons allowed for single role so team do not need to select only one or so | 19:27 |
| fungi | i think what JayF is concerned about is when a project is entirely inactive, no liaisons are responding, and someone steps up volunteering to replace them with no active team to confirm they're a fit | 19:27 |
| JayF | fungi: and/or active contributors being locked out of core and leadership groups | 19:27 |
| JayF | which as I mentinoed: not things happening in real life today, just a theoretical exploit | 19:27 |
| JayF | today if a PTL was abusing power to keep people out of core groups, the election acts as a "check" on that | 19:28 |
| gmann | sure, that is where TC can check and decide like we do for PTL appointment case | 19:28 |
| fungi | if there are active contributors then they should be consulted on the fitness of the new liaison volunteer(s) according to the dpl guidelines i quoted above | 19:28 |
| gmann | and sometime we have to handover the project to new set of people but yes we need to check those carefully with various factor | 19:28 |
| JayF | Yeah like I said, just an observation of a theoretical exploit not really something to be concerned about except maybe as a thing low on the list to consider as we ponder DPL-related policies | 19:29 |
| fungi | lack of volunteers for ptl/liaisons can act as a strong signal that the project is inactive, but presence of them does not itself indicate a project is active (cf. murano) | 19:31 |
| fungi | active status is more based on what actual work those volunteers keep up with | 19:32 |
| fungi | we've certainly had cases in the past with projects we probably should have called inactive where someone volunteered to be the ptl and then vanished until the next election | 19:33 |
| gmann | yeah and like PTL election, DPL reset can act as cleanup of inactive presence at least it filter out most of them but yes 'project activity status' is another thing to monitored along with these leadership monitor | 19:33 |
| gmann | fungi: +1, last cycle 5-6 projects retirement cleaned up most of such projects where we used to see PTL but not much activity by them | 19:34 |
| fungi | also thanks to everyone who put in the work to clean those up | 19:36 |
| gmann | at least current set of such projects and in this election we will get to know if there are more. 3-4 out of those retired projects were repeatedly asking for PTL appointment for many cycles and less actual activity in projects | 19:36 |
| JayF | August 28 is when nominations close, and we have 0 TC nominations: https://releases.openstack.org/dalmatian/schedule.html#e-election-nominations | 20:08 |
| JayF | If you're planning on running again, please put in a nomination or try to find someone to take your place :D | 20:08 |
| opendevreview | Merged openstack/contributor-guide master: Remove deprecated Extended Maintenance state https://review.opendev.org/c/openstack/contributor-guide/+/925122 | 20:17 |
| opendevreview | Merged openstack/contributor-guide master: Some minor docs fixes https://review.opendev.org/c/openstack/contributor-guide/+/926510 | 20:18 |
| fungi | and most importantly, please don't force me to be on the tc again ;) | 20:22 |
| clarkb | fungi: what about opendev service coordinator? | 20:23 |
| JayF | fungi: how could you have known that was the third line of my message I ended up deleting ;) | 20:24 |
| opendevreview | Jens Harbott proposed openstack/election master: Add Jens Harbott candidacy for TC 2025.1 https://review.opendev.org/c/openstack/election/+/926581 | 20:25 |
| JayF | ++ Thanks :D | 20:25 |
| fungi | clarkb: technically i've never been the opendev service coordinator since you had the distinction of leading us out of openstack to the promised land | 20:26 |
| spotz[m] | So the TC session at Summit won't help recruit for E but might help for F | 20:33 |
| JayF | IME the best approach to TC recruiting has been individual conversations. | 20:36 |
| JayF | Find someone who is at a point where they could make the leap, and sell them on it. | 20:36 |
| JayF | but I'm also clearly biased towards the contributors who use more traditional comm methods like IRC (and I suspect we have some who just ... aren't in IRC and basically aren't being represented) | 20:36 |
| opendevreview | Ian Y. Choi proposed openstack/contributor-guide master: [IRC] Improve with reflecting open protocol and global community https://review.opendev.org/c/openstack/contributor-guide/+/926584 | 20:55 |
| opendevreview | Vladimir Kozhukalov proposed openstack/election master: Add Vladimir Kozhukalov candidacy for 2025.1 TC https://review.opendev.org/c/openstack/election/+/926585 | 21:44 |
| *** bauzas_ is now known as bauzas | 22:38 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!