| opendevreview | Ian Y. Choi proposed openstack/governance master: Add PTL results from the 2024.2/Dalmatian election https://review.opendev.org/c/openstack/governance/+/913939 | 00:00 |
|---|---|---|
| frickler | tc-members: after some internal discussion I have changed my mind in regards to possibly having an exception on the diversity requirement, so maybe if the affiliated candidates haven't decided on some other solution yet, maybe submit a resolution and we can vote on it? | 12:48 |
| frickler | my reasoning: let's face reality, the vote simply reflects how the community as a whole looks like currently. so it might not make sense to try and hide that situation. also I have some trust in the individuals still having their own opinion despite being paid from a common source | 12:50 |
| JayF | I think that we have about one quarter of our community participating in elections, and that makes me question how well they map to our community. We have candidates who reflect the affiliation diversity of our community, who were not elected potentially due to only one quarter of our electorate being able to vote. While it's the only voting process we have now, I hesitate to say that it's the will of the overall openstack | 13:11 |
| JayF | community that we have no affiliation diversity in the TC | 13:11 |
| JayF | In fact, I would argue that the way we currently run our elections make it extremely difficult for new contributors to jump through all the hoops necessary to vote. | 13:11 |
| JayF | All this is to say, we are a large diverse community and the TC should be diverse as well as long as there's a path to continue that happening. The only way that doesn't happen here is this the five red hatters on the TC want to keep their seat more than they want to keep the tradition of a diversely affiliated TC. | 13:12 |
| frickler | since we have no data on who actually votes this is difficult to judge, but my assumptions is that this is mostly the difference between "core" and "drive-by" contributors, one of the interesting stats made on the bitergia dashbaord | 13:23 |
| frickler | I'm also open to discussing other voting procedures, but IMO if someone managed to setup things to submit a patch in gerrit, setting up for voting should be pretty easy in comparison | 13:25 |
| rosmaita | i think it would be a good PTG topic, to brainstorm ways to remove roadblocks/encourage the electorate to vote | 13:28 |
| dansmith | Counterpoint is that I think the bar you have to meet in order to vote is extremely low, in that a lot of people have the "right" to vote for pretty little actual contribution or interaction with the community | 13:31 |
| dansmith | I don't think the hoops you have to jump through to vote are unreasonable (at all), and I think any friction at all means someone who doesn't really care about it won't do it | 13:32 |
| dansmith | I think frickler's point is that, of the people that care, these are the candidates they chose, which is correct (IMHO) and worth honoring | 13:33 |
| dansmith | however, I also like the diversity requirement | 13:33 |
| dansmith | my "face reality" bit is that I just don't think it's going to be sustainable in the future, just like other diversity requirements we had in nova, which we're unable to satisfy anymore | 13:33 |
| rosmaita | well, the current process is not friction free, and the emails are confusing about when/if you need to re-register at the condorcet site, etc | 13:34 |
| frickler | iiuc you only need to register once (unless your email changes)? | 13:35 |
| fungi | please help make them less confusing. you can opt into ballot delivery at any time (before the election, even doing it while the poll is underway will trigger your ballot to be delivered), and you should only ever need to do it once unless you change your preferred e-mail address in gerrit | 13:35 |
| fungi | if the current announcement templates in the election repo don't seem to convey that, proposals of improved wording are happily accepted | 13:36 |
| rosmaita | ok, point taken, i will action item myself to re-read the templates | 13:37 |
| fungi | i agree we should make it as clear as possible. i have doubts people read those announcements, but at least trying to communicate is no less effective than not doing so | 13:38 |
| dansmith | right and I mean, if people aren't even willing to read an announcement, I mean, maybe their vote is random.choice() anyway | 13:40 |
| bauzas | do we know how many people actually did read the election email ? | 13:43 |
| fungi | we don't have any way of knowing who reads posts to the mailing list (that would be invasive if we did) | 13:45 |
| frickler | I think we had data on how many people actually registered to vote | 13:45 |
| fungi | well, on how many people opted into ballots (vs how many people qualified to vote) | 13:46 |
| fungi | though whether they opted in during this cycle or previously, we have no idea | 13:46 |
| frickler | 91 voters out of 298 did opt-in. so having 57 votes out of 91 looks like a reasonably expected outcome | 13:47 |
| fungi | and actually we really only know how many of the people who qualified to receive a ballot opted into delivery at some point, not how many may have opted into delivery and not qualified to receive a ballot | 13:47 |
| fungi | the sets overlap but there are certainly people in each who are not in the other | 13:48 |
| bauzas | fungi: thanks for the numbers :) | 13:49 |
| fungi | technically frickler provided the numbers, i was just providing additional context | 13:49 |
| frickler | well actually I just copied what ianychoi posted in the election channel at the start of the election | 13:50 |
| fungi | there's also the number of people who would have qualified to receive a ballot if they had a matching foundation member profile associated with their gerrit preferred e-mail address | 13:51 |
| fungi | i don't have that handy but it could be counted from the _all_owners.yaml which the election tooling produced | 13:51 |
| fungi | my guess is it's at least as many as those who did, just based on other recent contributor analysis | 13:52 |
| fungi | basically to vote you need: 1. to have contributed a change that merged in the qualifying time frame, 2. a foundation profile that can be deduced from your qualifying contribution, 3. to join the foundation as an individual member, 4. to opt into receive your ballot from civs, 5. to cast that ballot you received | 13:54 |
| fungi | each of those successive requirements implies a set of decreasing size | 13:54 |
| fungi | for this election, set #5 is 57, #4 is 91, #3 is 298, we can get the numbers for #2 and #1 if they're of interest (they're successively larger but i don't know by how much) | 13:56 |
| fungi | #2 would be determined by adding up the number of change owners from _all_owners.yaml who have either a "member" or "nonmember" field, and #1 would be all entries in the _all_owners.yaml file | 13:57 |
| dansmith | AFAIK #2 and #3 are non-negotiable right? They're the hardest hoops to jump through, AFAIK | 13:57 |
| dansmith | meaning if I submit a drive-by patch and then get a "oh you can vote now, but you have to go sign up for this account thing" I'm much less likely to do it unless I really care | 13:58 |
| fungi | they were non-negotiable per the foundation bylaws, but now they're merely non-negotiable per the tc charter | 13:58 |
| fungi | #3 is because the tc charter asserts active contributors are foundation individual members, #2 is because the election tooling has to have some way to confirm that | 13:59 |
| bauzas | but I always thought you needed to be a foundation individual member in order to propose a patch to gerrit | 14:01 |
| bauzas | as you need to sign off the CLA | 14:01 |
| fungi | that hasn't been required since ~2015 | 14:02 |
| dansmith | I didn't think so, but maybe | 14:02 |
| bauzas | but I may look at the contributor guide | 14:02 |
| bauzas | fungi: ah ah ok, thanks for reminding me the time is flying :) | 14:02 |
| bauzas | then, maybe #3 is a bit harsh | 14:03 |
| fungi | gerrit changed how its cla feature worked, and the foundation wasn't doing much with the callback we previously had to try to match up to a membership during cla signing (and also there was no legal requirement for it in the bylaws) | 14:03 |
| fungi | so currently you just indicate that you've read and agree to the cla text, and then gerrit allows you to propose changes to openstack | 14:03 |
| fungi | gerrit no longer collects contact information for the cla, nor does it call any external systems when you agree | 14:04 |
| bauzas | gotcha | 14:04 |
| fungi | about the only reason i can think of to keep the foundation individual member requirement for the electorate is that it might provide a stronger legal deterrent to contributing under multiple gerrit accounts in order to receive multiple ballots | 14:12 |
| fungi | though if the tc wants to lift that requirement, it would probably be worth talking to foundation executives/legal/board just to make sure there's not other reasons we've collectively failed to consider | 14:13 |
| dansmith | personally, I'm not worried about us not getting a representative sample due to the small amount of friction required to vote | 14:15 |
| dansmith | just like I don't want to lower the bar for submissions to "dump something in a google form" I also don't think _just_ having more votes is a solution to anything | 14:16 |
| dansmith | more people voting that don't know the candidates or the issues or the community are not valuable to me | 14:16 |
| bauzas | fwiw, having our elections with low number of voters is pretty usual | 14:21 |
| bauzas | iirc, this was already the case since Victoria at least | 14:21 |
| bauzas | but that's easy to check the numbers | 14:21 |
| bauzas | if we really want to solve that problem now, I'm cool but I don't want to mix that with the current problem we have | 14:22 |
| JayF | I only brought it up because it was implied that the election result comes with some kind of mandate | 14:24 |
| JayF | When in reality, I think it's just a viewport into the cross-section of people who have been in the community a long time | 14:24 |
| JayF | Inherently a non-diverse TC is a status-quo TC, and our status quo is not awesome right now. | 14:25 |
| dansmith | it's also just reality, but I know we don't want to reinforce a negative either | 14:32 |
| JayF | We have a candidate with (I believe?) a net-unique affiliation who has volunteered their time to help govern things. The reality is that more RH employees than the capacity of the TC can hold chose to run and caused this issue pretty directly. I agree it'd be a sad reality if we were forced into this situation; but we're not: there are enough volunteers. | 14:34 |
| dansmith | If I extend that logic, assuming redhat employees will be the dominant set of candidates in the future, anyone can force their way onto the tc at each election by being the one and only non-redhat candidate, effectively subverting the will of the electorate right? | 14:38 |
| dansmith | I mean, maybe you think that's better "because diversity" but I don't if the community isn't actually choosing that person | 14:38 |
| rosmaita | dansmith: that is not the case we have before us right now | 14:38 |
| rosmaita | the two candidates in the bottom ranking are perfectly legitimate contributors active in the community | 14:39 |
| JayF | and such a scenario is comical to consider given right now we have little to no interest in OpenStack governance outside of the 5 dozen people who voted, give or take | 14:39 |
| JayF | what is such a threat model of a single actor being on the TC? What threat does that hold? | 14:39 |
| JayF | I have lots of valid threat models around a TC that is run by a single company. | 14:39 |
| dansmith | rosmaita: no totally, I realize that I'm just talking about in the future if we'll always have to choose the non-redhat person in the list | 14:39 |
| rosmaita | well, we can worry about that next time | 14:40 |
| JayF | Exceptional situations are taken on a case by case basis; I'm judging this case today. I will judge next election next time. | 14:40 |
| fungi | it's also possible that 50 people from another organization could all run for tc and end up taking every available seat through sheer statistical distribution of votes, so having some ideas for how to address it would still be good | 14:40 |
| rosmaita | i just don't think irc is a good forum for working this kind of stuff out | 14:40 |
| JayF | rosmaita: I disagree vehemently. I think this entire discussion must be done in the light, in logged channels. | 14:40 |
| fungi | (yes probably most/all of those 50 would lose to candidates with established reputations, but that depends on voter behavior) | 14:41 |
| JayF | rosmaita: maybe gerrit is an alternative, but that requires someone be willing to put pen-to-paper around the exception; which I'm certainly not going to do | 14:41 |
| dansmith | I think that thinking about how this decision affects the future is prudent.. yes, we're not up against the wall right now, but we know how things are going | 14:41 |
| rosmaita | well, i will up your disagreement and say that i disagree even more, because the discussion is being dominated by a particular time zone | 14:41 |
| JayF | rosmaita: touche | 14:42 |
| knikolla | i am trying to keep up with the conversation but due to scheduling conflicts I will be unavailable until 2 hours from now. | 14:44 |
| fungi | this is the closest the tc has ever come to having to make a decision about whether it will enforce its affiliation diversity requirement, and i'm not surprised that the majority seats under contention are for red hat affiliates given their current involvement in openstack governance, but i wouldn't want to assume it will always be this way and it could just as easily be some other | 14:44 |
| fungi | organization the tc faces similar decisions for in 5 years time | 14:44 |
| bauzas | tbc, and I'm aware this is a public logged channel, no intent was made to arrive into that situation and force the TC to accept the waiver | 14:45 |
| bauzas | the votes are anonymous and I can't tell the reasons that led to those results, but the fact is that we now have a problem to solve and I reinstate my take which is that I'd prefer the TC to not accept a waiver | 14:46 |
| fungi | yes, i'm not aware of anyone who has suggested this outcome was intentional | 14:46 |
| bauzas | fungi: I'm not pointing anyone, I'm just explicitely telling that this wasn't an intent | 14:47 |
| fungi | it has seemed fairly accidental to me, at any rate | 14:47 |
| JayF | I don't read any intent into any of it; but that does not mitigate any of the negative effects should it stand. | 14:47 |
| knikolla | ++, this is a great and long overdue discussion about balancing the will of the electorate with the consequences of enforcing/partially subverting it for valid reasons. | 14:48 |
| bauzas | people read this channel and can interpret what they think | 14:48 |
| bauzas | so I wanted to say it loud, for the records | 14:48 |
| rosmaita | i have a question for someone who knows the TC charter better than me ... the diversity requirement is stated, but I don't see that the charter states how the situation should be resolved? | 14:49 |
| rosmaita | https://governance.openstack.org/tc/reference/charter.html#tc-diversity-requirement | 14:49 |
| bauzas | fwiw, the affiliates require a bit of time in order to reach to a conclusion | 14:49 |
| bauzas | rosmaita: nothing is said there, that's the problem | 14:50 |
| fungi | rosmaita: as far as i've found, the charter does not describe any specific solution | 14:50 |
| rosmaita | ok, just wanted to make sure i wasn't missing something | 14:50 |
| fungi | which means the current tc members are stuck here forever, or until they arrive at a solution ;) | 14:50 |
| dansmith | do we have a definition of "affiliation"? | 14:51 |
| bauzas | fungi: some unrelated and unexpected event requires us to defer our discussion until next week | 14:51 |
| knikolla | BTCFL :) | 14:51 |
| bauzas | dansmith: probably in the bylaws | 14:51 |
| dansmith | I don't use my redhat email address, I regularly vote against their desires, and my employment records are not public.. just curious what the definition is | 14:51 |
| rosmaita | yes, affiliation is defined in the bylaws | 14:51 |
| dansmith | the foundation bylaws you mean yeah? | 14:51 |
| rosmaita | yeah, the link is in the charter | 14:52 |
| bauzas | yeah 4.15 (b) | 14:52 |
| dansmith | obviously it doesn't matter, I'm just kinda curious | 14:52 |
| bauzas | https://openinfra.dev/legal/bylaws | 14:52 |
| JayF | hberaud just pinged me, asking again for TC members to review https://review.opendev.org/c/openstack/governance/+/902585 | 14:52 |
| hberaud | Votes for or against are welcome. | 14:54 |
| JayF | rosmaita: as TC chair, I would think that indicates we'd have to pass a resolution to make an exception or change the charter **with the current TC** before we can merge the election results as-is. | 14:56 |
| JayF | rosmaita: mainly saying: just 2/3s vote on https://review.opendev.org/c/openstack/governance/+/913912 is not a sufficient override IMO | 14:57 |
| rosmaita | i agree | 14:57 |
| rosmaita | i was just asking about whether there was a procedure already in place for what to do if no exception to affiliation diversity is made | 14:58 |
| fungi | it could be seen as an implicit waiver, but yes an explicit waiver would be preferable to clearly signal that intent | 14:58 |
| rosmaita | as a python shop, we should all agree that explicit is better than implicit! | 14:58 |
| JayF | fungi: I think that could be acceptable to some chairs, given it's kinda my responsibility to workflow it, I'm saying I *will not +A* any election results until another, explicit exception is landed. | 14:58 |
| fungi | yep, makes sense to me | 14:59 |
| rosmaita | me too | 14:59 |
| frickler | dansmith: one thing that hasn't been mentioned yet, iiuc the affiliation of a candidate is to be taken from their foundation profile, which means they control that information themselves. in fact one candidate didn't specify anything there yet last time I checked, so I was just guessing their affiliation from other data like github profile | 15:05 |
| dansmith | that's kinda why I'm asking yeah | 15:06 |
| dansmith | I wasn't thinking the charter referenced the definition in the bylaws directly, but it does | 15:06 |
| dansmith | so yeah, you could change the info yourself, but you'd be in violation of those bylaws and I 100% believe the other redhatters wouldn't let such an offense go unchecked :) | 15:07 |
| bauzas | :) | 15:07 |
| dansmith | the reason I'm asking is that I don't eve know all the redhatters that run in a given cycle and sometimes I think people are (or are still redhat) that aren't and the opposite | 15:07 |
| frickler | since nobody has yet questioned the stated assumption that 5 of the to-be-TC-members would be affiliated, I have assumed that to be true | 15:08 |
| dansmith | heh, yeah | 15:08 |
| bauzas | this situation happened because we mostly work in separate teams internally and all the potential candidates from the same company never discussed or claimed they'd run for TC | 15:09 |
| bauzas | that's also probably something our company needs to address | 15:09 |
| dansmith | when artem commented about being "soon unaffiliated" on the results patch, I thought maybe he was redhat and just left or something | 15:09 |
| rosmaita | frickler: the Affiliation definition in the Bylaws doesn't mention anything about foundation profile, it mentions actual real-world connections between individuals and entities | 15:10 |
| frickler | yes, it is an added assumption to expect the profile to be correct and up to date | 15:12 |
| JayF | Honestly, given the foundation definition, it could be argued that I'm technically affiliated with Insight Softmax Consulting rather than G-Research | 15:12 |
| JayF | doesn't matter in my case but it's interesting :) | 15:12 |
| * bauzas goes check if my profile says I'm working for Bull | 15:14 | |
| rosmaita | well, when we moved the affiliation stuff out of the bylaws and into the TC charter, we kept the reference to the bylaws definition because it is kind of complicated and we didn't want to restate it | 15:15 |
| gmann | rosmaita: yes, that was done very carefully to have clear an centeric definition of affiliation. | 16:27 |
| gmann | rosmaita: on your previous question on 'charter does not state that how to resolve the situation', yes that is actual part we are missing in our process. that is why I am trying to fill that for future situation. feelf ree to add you ideas there and we can discuss in PTG https://etherpad.opendev.org/p/apr2024-ptg-os-tc#L43 | 16:28 |
| rosmaita | gmann: ack | 16:28 |
| gmann | tc-memebrs: IMO, if we are going for waiver then do it temporarly only for this election which is as per the current charter. and in PTG we can think how to manage and handle the diversity. instead of changing the charter for diversity in between of election process | 16:31 |
| gmann | i might have missed the log but bauzas dansmith can you remind/update me if RH candidates discussed it internally and did not come to any agreemnt OR it is not yet discussed OR RH candidates want TC to resolve this? | 16:34 |
| bauzas | the second point | 16:34 |
| gmann | ok | 16:34 |
| bauzas | I'd want the rh folks to come up with a conclusion in order to the tc to not vote for a waiver | 16:35 |
| bauzas | I don't want this election to be part of https://governance.openstack.org/tc/reference/election-exceptions.html | 16:35 |
| gmann | well, it is not so bad if we waive off (temporary only for this election) too because it will be 5 RH and 4 Non RH in TC so any change in charter need 6 TC to vote (2/3 of total TC) so it is not possible that RH can hijack the TC :). | 16:38 |
| bauzas | gmann: I won't let this situation occur, tbc | 16:40 |
| fungi | dansmith: frickler: the affiliation which matters is what's defined in the bylaws. we ask candidates to declare their affiliation(s) in their foundation profile for convenience, so yes it's self-asserted but it's a stretch to imply that means your affiliation is whatever you want to claim it to be | 16:41 |
| bauzas | please give us just some time in order to discuss between ourselves | 16:41 |
| gmann | tc-members: Considering the below things I am kind of OK for the temporary waive off for this election and let's discuss in PTG on how to handle it better in future. | 16:44 |
| gmann | 1. The current waive off will make only 5 members from the same affiliation so they cannot change the charter by themself | 16:44 |
| gmann | 2. It is a temporary waive off so we can always take care of it in the next election if members from the same affiliation increase to the number of members needed for TC charter change | 16:44 |
| gmann | 3. last but most important, considering all of you 5 members have been part of the community for so long and with the community-first mindset. so no doubt about their intention of doing anything wrong. | 16:44 |
| gmann | bauzas: sure. | 16:44 |
| bauzas | gmann: we never discussed that btw. but how can a candidate officially declare he drops off the election ?. | 16:44 |
| bauzas | does he need to revert his candidacy patch ? | 16:45 |
| gmann | bauzas: we never been in this situation so no official process to do that but it can be done via informing TC chair about that and we pass the resolution to record it officially. | 16:45 |
| gmann | bauzas: not to revert candidate patch but ^^. JayF what you say? | 16:46 |
| bauzas | gmann: how a TC member then can drop a seat ? | 16:46 |
| gmann | bauzas: that is when they propose to remove their name from this file https://github.com/openstack/governance/blob/master/reference/members.yaml | 16:46 |
| bauzas | actually, I'm reading the vacancy rule https://governance.openstack.org/tc/reference/charter.html#election-for-tc-seats | 16:46 |
| gmann | and that will be consider a vacant seat. and handle with ^^ process | 16:47 |
| bauzas | gmann: but that would require https://review.opendev.org/c/openstack/governance/+/913912 to be merged, then a waiver to be voted | 16:47 |
| bauzas | that's a chicken-and-egg problem | 16:47 |
| gmann | bauzas: no, waiver will be done with the current seated TC members which is affiliated diverse. we should not allow new tc-members to do it as that can be against the process. | 16:48 |
| bauzas | gmann: I got it, I'm asking what can be done for someone recently elected to drop from the election | 16:49 |
| gmann | this is like "current diverse affiliated TC approved the temporary waive off for coming TC for non diverse" | 16:49 |
| bauzas | I'd rather prefer the candidate to officially declare his resignation by notifying the TC chair, honestly | 16:50 |
| bauzas | I'm very against that waiver, even very temporarly | 16:50 |
| gmann | bauzas: we can do 1. pass a resolution either to "waive off" OR "a candidate drop from RH + new non-RH candidate to select" and once that is merged then update 913912 as per passed resolution and merge it | 16:50 |
| bauzas | sounds then correct to me | 16:51 |
| bauzas | but we need the current TC to vote a resolution providing both alternatives | 16:51 |
| gmann | bauzas: sure, I am not against of that if that can be resolved within RH candidates. though it might be no so fair for elected candidates to drop but ok as agreed within that affiliation candidates | 16:52 |
| gmann | bauzas: yes. | 16:52 |
| bauzas | this seems even required to pass such resolution, even if we figure out some candidate voluteer to resign | 16:53 |
| gmann | the current TC should approve any solution we find and which builds the new TC | 16:53 |
| bauzas | s/should/needs to | 16:54 |
| bauzas | right? | 16:54 |
| frickler | IMO a resolution is not needed. a -1 on 913912 stating the drop should be fine and then the patch can be amended according to the "vacant seat" rules | 16:54 |
| gmann | yes, bcz we should pass it officially as a fair process and official recording. | 16:54 |
| frickler | and that patch needs to be approved by the current TC anyway before the new members get seated | 16:54 |
| gmann | frickler: but there will not be vacant seat in this case. | 16:54 |
| bauzas | frickler: I leave the current TC to decide on the approach, but we need some clear path | 16:55 |
| gmann | IMO. resolution will be a clear official recording. and then update and merge the 913912 | 16:55 |
| gmann | bauzas: yes, first we need what is the solution and based on how we can be fair and official record it that is something we can discuss | 16:56 |
| knikolla | I don’t think a resolution is needed for the case of someone dropping from the race before the election results are confirmed and merged. | 16:56 |
| gmann | basically TC chair can handle it after discussing with current TC memebrs | 16:56 |
| gmann | knikolla: how to do that? | 16:56 |
| gmann | just updating the 913912 will not be clear enough on that process that is why I feel resolution is clear path/official record. | 16:57 |
| gmann | this is first time we are in this situation so to be little careful from all possibility including legal I feel resolution is safe way | 16:58 |
| knikolla | perhaps reverting the candidacy? | 17:08 |
| gmann | it could have been done before voting but after voting removing the candidacy does not seem right because that might have impacted the overall election voting if done before electiohn | 17:10 |
| bauzas | not exactly true | 17:10 |
| bauzas | condorcet gives a ranking based on 1:1 votes | 17:10 |
| knikolla | it would create a written gerrit change that is timestamped and approved by election officials | 17:10 |
| bauzas | I mean, competition against each candidate | 17:11 |
| knikolla | and as bauzas said, all condorcet results are head to head | 17:11 |
| bauzas | I checked the figures and the results wouldn't have changed if one from the list was missing | 17:11 |
| gmann | that is true aas per the current votes but I am saying the voting weightage could be different when electorates see the final candidates before voting | 17:12 |
| gmann | I am not sure how to calculate but that is possible. i will prefer to have re-election after candidate drop that will be fair for electorates also | 17:13 |
| knikolla | It's ranked voting. So if I pick X as number two, and they drop off, number 3 becomes number 2. The ranking is preserved therefore it doesn't impact the results. | 17:13 |
| bauzas | that ^ | 17:14 |
| bauzas | a 3 becomes a 2 etc. | 17:14 |
| bauzas | and even numbers don't change | 17:14 |
| bauzas | tc-members (not sure I can use the alias) : I hereby officially declare I resign from the TC election | 17:22 |
| bauzas | JayF: ^ | 17:22 |
| bauzas | I'm just proposing a patch against my nomination patch as a testimony and I'll drop a comment on 913912 | 17:23 |
| opendevreview | Sylvain Bauza proposed openstack/election master: Revert "Sylvain Bauza candidacy for TC" https://review.opendev.org/c/openstack/election/+/914001 | 17:24 |
| dansmith | man, this is frustrating and not a great signal to new people wanting to join the TC | 17:26 |
| dansmith | me giving my seat up also isn't very fair to artem, who would only get a half a term | 17:27 |
| bauzas | the very last hours showed me how critical this is for us to solve this problem as soon as we can | 17:27 |
| gmann | at least for process wise, I am -1 on that. As we do not have any process defined for this situation. I will suggest TC members pass the resolution to drop the elected candidates and work on making it process for future situations. | 17:27 |
| bauzas | and I'm decided to unblock this before the weekend | 17:28 |
| gmann | it is fine, until new TC are selected current TC are in their term so I do not think it is a very urgent to solve within 1-2 days especially when we do not have process defined for that. in that case, resolution is safe bet. | 17:29 |
| knikolla | gmann: i do find it a bit untasteful for the current tc to approve a resolution to drop off one of the elected people and would prefer this be dealt by election officials rather than the tc (except for approving a waiver as defined by charter) | 17:29 |
| knikolla | if you think this is too undefined, i'm okay with passing a resolution that approves a "general process" for a tc candidate to drop off. | 17:31 |
| gmann | knikolla: of course it will be agreed by the dropping candidates. but when we do not have process then i feel resolution make sense | 17:31 |
| knikolla | and then let be the process used in this instance. | 17:31 |
| bauzas | gmann: I would be okay to let election officials to approve my resignation | 17:32 |
| gmann | sure, that also work. but I really want to avoid situation where someone can raise question on elected candidate drop proces | 17:32 |
| frickler | so how about: just drop bauzas from 913912 then according to that resignation, approve that patch. then we have an official vacancy that can be filled according to the process defined in the charter | 17:33 |
| gmann | i mean resolution to define process also work | 17:33 |
| knikolla | gmann: i understand your concern, hence why i proposed defining the process of dropping off. Which to be honest should be codified, so why not now. I just don't want the tc to have anything to do or creating the precedent where the tc approves or denies someone canceling their candidacy. | 17:34 |
| gmann | dansmith: agree, I hope bauzas discussed it among RH candidates and there was agreement. my understanding was that. I think that is why yesterday also we were not agree on anyone dropping bcz they just want to solve the situation. it should be agreed/discussed first | 17:36 |
| bauzas | gmann: tbh, nope | 17:37 |
| bauzas | gmann: but my decision is clear | 17:37 |
| bauzas | I wish we would have sorted out this situation was earlier but we didn't | 17:38 |
| bauzas | way* | 17:38 |
| dansmith | gmann: nope, no discussion amongst the candidates really, that I've seen | 17:40 |
| dansmith | gmann: also to be clear, one of the candidates isn't really available to discuss because of extenuating circumstances, which is kinda part of it I think | 17:41 |
| gmann | ohk then it seem we are in same situation what we were yesterday | 17:41 |
| gmann | yeah | 17:41 |
| dansmith | gmann: I'm also happy to give up my seat to solve the problem, but it isn't a great solution to me as mentioned | 17:42 |
| bauzas | dansmith: no, that's not a solution | 17:42 |
| dansmith | sure it is, it's just not ideal | 17:43 |
| * dansmith will brb | 17:43 | |
| gmann | yeah, that will lead to uneven election timing or short term for a candidate which is not fair | 17:43 |
| gmann | honestly saying to be fair to everyone, I am now more of 'let's waive off the diversity for this term' given the things i considered in my earlier msg. | 17:44 |
| JayF | bauzas: thank you for doing that -- the diversity rule being maintained is the original reason I ran 1.5 yrs ago in the first place, and it would've been sad to see it stumble | 17:45 |
| gmann | should we make resolution up for waive off and we can see clear voting on that as many members were in favor of that (if i read log correctly) ? | 17:46 |
| knikolla | there are no good solutions, we need to reach consensus on the more desirable outcome. waiving the diversity requirement creates a precedent that may become sticky and therefore I'm strongly opposed. Though I really hate for that to penalize someone that is newly elected. | 17:46 |
| bauzas | I'm also against a waiver | 17:47 |
| bauzas | (fwiw, as I'm not part of the TC) | 17:48 |
| gmann | sure, let's have a clear disagreement or agreement on that. at least we will narrow down the possible solution that way. I am proposing to get voting there | 17:49 |
| JayF | gmann: there is no reason for that resolution to go into effect, with bauzas stepping aside. | 17:49 |
| JayF | There's no longer an issue on the table to resolve, unless tc-members feel https://review.opendev.org/c/openstack/governance/+/913912/3#message-73a24ceef90a67768ecb95aeca0e378a63e1ecc3 is insufficient process for him to resign | 17:49 |
| knikolla | I defer to JayF on what the chair considers an official resignation. | 17:50 |
| gmann | which i think not fair solution especially since it is not discussed among same-affiliation candidates | 17:50 |
| JayF | I could resign tomorrow and nobody on the TC would have any say in it beyond me. | 17:51 |
| knikolla | gmann: resignation should be a personal decision. | 17:51 |
| bauzas | which it is | 17:52 |
| gmann | JayF: that is after you are TC and it consider as vacant seat | 17:52 |
| rosmaita | what would the process be if a candidate decided to withdraw because of illness? | 17:53 |
| rosmaita | i mean, how could they do it? | 17:53 |
| knikolla | i'm guessing a governance proposal to change members.yaml | 17:53 |
| gmann | knikolla: sure, I am not against of regination, I am saying follow the process. and when we do not have process, we always pass the resolution to be on safe side for example stopping the monasca release and many in past | 17:53 |
| ianychoi | As en election official, 1/ it will be great if we better identify TC candidates' affiliation - this time, I couldn't check all candidates' affiliation with some personal e-mail address / even through Foundation profile. 2/ Thank you @bauzas for the decision, while we also need to respect who voted for you so I prefer not to accept your resign now. | 17:54 |
| gmann | yes, any current TC can drop its seat to remove themself from members.yaml and current TC vote on that | 17:54 |
| gmann | that is why a TC resolution will be fair to the electorate also and for everyone. | 17:55 |
| JayF | I see two potential ways forward; I have no strong preference on either: | 17:55 |
| JayF | 1) We revise https://review.opendev.org/c/openstack/governance/+/913912/3#message-73a24ceef90a67768ecb95aeca0e378a63e1ecc3 in light of bauzas's decision and refer to https://governance.openstack.org/tc/reference/charter.html#election-for-tc-seats which says "the candidates who did not win seats in the most recent previous TC election will be consulted in the order they appear in the results until a candidate who is capable of | 17:55 |
| JayF | serving agrees to serve out the partial term" (for the third bullet point case, which is valid here) | 17:55 |
| JayF | 2) We pass an explicit resolution, indicating that under ^^ that clause in the charter, we're naming [candidate] to the TC. | 17:55 |
| JayF | I will note if bauzas is reconsidering he needs to do it rapidly, as I feel https://review.opendev.org/c/openstack/governance/+/913912/3#message-73a24ceef90a67768ecb95aeca0e378a63e1ecc3 already represents a completed resignation. | 17:56 |
| gmann | we are favor or against of any candidate drop is a very different thing,. I am just more concern of a official recording of what current TC accept which impact building the incoming TC | 17:56 |
| bauzas | JayF: my statement in gerrit is the reflect of my actual commitment | 17:56 |
| JayF | gmann: so it sounds like you would prefer option #2, where we are more explicit about the situation. I have no objection to taking this route. Explicit and well-communicated is a good thing :) | 17:57 |
| bauzas | but I indeed beg the TC to do some kind of post-mortem and identify the gaps they need to solve | 17:57 |
| dansmith | bauzas: post mortem of what exactly? having a more specific procedure on how to handle the conflict? | 17:58 |
| gmann | JayF: yes, especially for a official record and better communication | 17:58 |
| JayF | It absolutely seems like, at a minimum, we can cleanup the charter around these processes. | 17:58 |
| ianychoi | On process perspective, please also consider how candidates' affiliation is well checked so that we can encourage more discussion - e.g., campaign period. Currently, there are two parts 1) when candidacy is submitted and 2) when election voting is finished. | 17:58 |
| JayF | There's absolutely follow-ups from a TC standpoint to make this less sticky and to ensure the steps are known | 17:58 |
| dansmith | AFAIK, the current charter is loosely defined in hopes that it will self-resolve (i.e. someone stepping aside) but it would certainly be easy to just say "bottom n candidates that conflict will be excluded" or something | 17:58 |
| gmann | ianychoi: ++, good point | 17:59 |
| bauzas | dansmith: 1/ preventing the conflict by at least identifying the affiliations during the nomination campaign, 2/ define a process that clearly avoids the TC to vote a waiver | 17:59 |
| dansmith | bauzas: I don't think #1 is really a thing.. I mean it just gives us more warning that ti might happen, but we won't exclude candidates right? | 18:00 |
| knikolla | JayF: rather than a resolution nominating X to TC, would you be in favor of a resolution stating that a candidate can drop off by -1 on the governance patch confirming the election results into the members.yaml file? | 18:00 |
| JayF | knikolla: I was writing this as a one-time resolution for this case, allowing for time around debate for charter updates to ensure this is the only oneoff. | 18:00 |
| dansmith | #2 is maybe what I discussed above, although it doesn't offer the opportunity for something like the longest-serving member to step aside for new people (unless we write it that way) | 18:00 |
| bauzas | dansmith: no, but the TC shouldn't be discovering the risks when the election is over | 18:00 |
| rosmaita | well, we all knew it was a possibility given the number of | 18:01 |
| rosmaita | RH candidates, we just weren't ready | 18:01 |
| dansmith | this was not a surprise to me, but perhaps it was to others | 18:01 |
| bauzas | not sure we all knew, that's the point | 18:01 |
| knikolla | JayF: sure, sounds good to me. | 18:02 |
| bauzas | anyway, ship has sailed now, we just need to close this election on the best possible way | 18:02 |
| gmann | well, I am seeing this situation in every election especially when we are at edge on numbers for diversity | 18:02 |
| JayF | I don't agree with that when the two candidates who were not elected have different affiliations. | 18:02 |
| gmann | that was true in this election also | 18:03 |
| JayF | My opinion of the situation would be drastically different if it was, as it almost was when I initially ran, a situation where there were not enough valid candidates to ensure a diverse outcome. | 18:03 |
| knikolla | ++, this time around we had a larger pool of candidates than the average election in the last 2 years. | 18:03 |
| gmann | I have been rasing that alert since last year in Board when it was in bylaws and in TC also. but we did not work on the process in advance | 18:04 |
| dansmith | rosmaita: by "not ready" do you mean RH people didn't pre-arrange the outcome of what would happen or whatever? | 18:04 |
| gmann | and seeing possibilities of it occur in future also, we should discuss it thoroughly in PTG and build up a process/rules to handle all possible casesa | 18:05 |
| dansmith | I definitely don't want to border on cabal behavior by trying to pre-negotiate that as an org | 18:05 |
| dansmith | individual discussions sure, but I don't want us to start telling people they can't run without approval to make sure we don't run over the limit | 18:05 |
| rosmaita | dansmith: no i mean the TC was not ready to deal with this situation in a smooth way | 18:05 |
| JayF | It's interesting, at rackspace we sometimes would explicitly coordinate *to avoid* behavior that even appeared like a cabal. It's one of those things where either direction can look improper depending on perspective. | 18:05 |
| dansmith | rosmaita: oh okay I thought you meant the "RH candidates" weren't ready | 18:05 |
| rosmaita | no, i had to finish my sentence in a hurry because i fat-fingered the middle of it | 18:06 |
| dansmith | ohh, I see, I missed it was one statement, I gotcha | 18:06 |
| rosmaita | yeah, what i was trying to say was, the TC kind of knew in advance that it was possible that too many RH candidates would be elected, and we now know that we should have discussed a plan for dealing with it earlier | 18:08 |
| rosmaita | but now we know | 18:08 |
| opendevreview | Jay Faulkner proposed openstack/governance master: [resolution] Adjudication of 2024.2 TC Election https://review.opendev.org/c/openstack/governance/+/914024 | 18:09 |
| dansmith | rosmaita: well even still, I feel like every time we (especially I) try to talk about "what would happen if.." I get told we'll cross that bridge when we come to it.. here we are on the bridge | 18:09 |
| dansmith | maybe we should all push resignations (myself included) and let the TC vote on which one they like best? :) | 18:12 |
| opendevreview | Jay Faulkner proposed openstack/governance master: [resolution] Adjudication of 2024.2 TC Election https://review.opendev.org/c/openstack/governance/+/914024 | 18:12 |
| JayF | TC doesn't get to choose when someone resigns | 18:12 |
| gmann | Actually here the situation is different, this regulation reason is because of TC requirement which is a little different than self-regulation | 18:14 |
| knikolla | We can follow the John Oliver method of bribery for resignations | 18:15 |
| gmann | resignation , self-resignation | 18:15 |
| opendevreview | Merged openstack/election master: Close 2024.2 Election Results (TC/PTL) https://review.opendev.org/c/openstack/election/+/913854 | 18:15 |
| opendevreview | Jay Faulkner proposed openstack/governance master: [resolution] Adjudication of 2024.2 TC Election https://review.opendev.org/c/openstack/governance/+/914024 | 18:15 |
| gmann | it is kind of force resignation by TC requirements | 18:15 |
| rosmaita | well, it's more of a withdrawl of candidacy before the TC has ratified the election results | 18:16 |
| bauzas | if you want MHO, I'd wish the charter to have some automatic way to resolve that conflict rather than asking folks to find a solution by themselves | 18:16 |
| JayF | As far as I can tell, there's no forcing function at all. In fact, one of the key items I'll be considering for RCA is that, if we did not have votes to waive, and nobody was willing to resign, we could have been in a deadlocked situation. | 18:16 |
| bauzas | THAT ^ is what I ask the TC to work on | 18:16 |
| gmann | bauzas: ++ agree, we must do that | 18:16 |
| bauzas | and tbc, while I account my resignation, I'm still doing it a little heart-broken | 18:16 |
| gmann | waive off is there so not deadlock actually | 18:17 |
| knikolla | bauzas: ++, but that would come out to two possible paths with tradeoffs. either based on votes, or based on length of term up to that point. | 18:17 |
| bauzas | so please don't take that election as 'yay, we eventually found a solution, we'll come to a conclusion again next time' | 18:17 |
| gmann | bauzas: that is the key and it reflect your resignation is actually not self-resignation | 18:17 |
| bauzas | this is self in the terms of someone clearly minded about it | 18:18 |
| gmann | and same for anyone else resigning and that is why I feel waive off is best way to move in this situation | 18:19 |
| dansmith | gmann: I don't think the votes are there for the waive-off | 18:20 |
| JayF | I've W-1'd that resolution until at least Monday, but I wanted something to be in place for us to talk about concretely instead of just considering what it'd look like. | 18:20 |
| gmann | that was my suggestion to record those in gerrit. I think frickler was in favor of that and me too, JayF and knikolla not in favor. those i can count from IRC but those are not official | 18:21 |
| dansmith | if there were no other candidates, I'd be in favor of that.. since there are, I'm more in abstain territory, even though I think this is a pill we're going to have to swallow eventually | 18:21 |
| JayF | gmann: I've done a count, we do not have a supermajority to pass it. | 18:21 |
| JayF | gmann: unless further votes change | 18:21 |
| dansmith | JayF: you're assuming my vote now? | 18:21 |
| dansmith | please don't do that | 18:21 |
| JayF | dansmith: I have personally talked to three other TC members who indicated they are unlikely to vote for such a change. | 18:22 |
| gmann | JayF: that is my point, I was not in favor of that but how this is going I am now in favor. so my humble suggestion is to record in gerrit | 18:22 |
| JayF | dansmith: that's all I'm saying, and I'm not counting you :) | 18:22 |
| gmann | sure abstaining is all ok, at least we get the clear view | 18:22 |
| gmann | and for community also to tell we considered this option and it did not get agreed or agreed by TC | 18:23 |
| JayF | Someone can feel free to propose such a change to gerrit. I have no desire to propose a change that I would -1 myself :) | 18:23 |
| JayF | I'm happy to record a vote there. | 18:23 |
| gmann | ok, let me propose that at least we will narrow down the solutions and can do better handling the remaining solution next week | 18:24 |
| JayF | I'll note in addition to such a waiver, we'd also need bauzas to un-resign, which he has at no point indicated a desire to do. | 18:24 |
| opendevreview | Jay Faulkner proposed openstack/governance master: [resolution] Adjudication of 2024.2 TC Election https://review.opendev.org/c/openstack/governance/+/914024 | 18:24 |
| JayF | I will administrate whatever the decision of the TC is under the charter, but you are right that we need to ensure we have it extremely clearly documented. | 18:25 |
| bauzas | JayF: man, you're putting myself in a strain | 18:25 |
| bauzas | don't ask me to choose whether I want to take over a seat or not | 18:25 |
| gmann | JayF: ++ | 18:25 |
| bauzas | we're in this situation because something wasn't in the charter, so I'm offering to quit | 18:25 |
| JayF | bauzas: I don't mean to put pressure on you, I'm sorry. I'm trying to just view this in terms of actions to take and boxes to check. | 18:26 |
| bauzas | but please don't ask me to choose myself over artem, that's too much for me to do | 18:26 |
| bauzas | TC is TC | 18:26 |
| bauzas | whatever their decision is (and I expressed my opinion on the waiver), it has to be respected | 18:27 |
| gmann | sure, we are not saying accept or deny anything but at least record and have a clear views on each possible solution. and we will see where the majority are. | 18:28 |
| gmann | mainly for communication and recording. I have seen in past such un-recorded things has setback TC in past. I remember the U release naming thing | 18:29 |
| opendevreview | Jay Faulkner proposed openstack/governance master: [resolution] Adjudication of 2024.2 TC Election https://review.opendev.org/c/openstack/governance/+/914024 | 18:30 |
| knikolla | Whatever the outcome is, we're all human. I sincerely hope this doesn't discourage bauzas or anyone else from running in the next election cycle. | 18:31 |
| bauzas | well, that experience is a bit hard to digest, so I sincerely hope the TC amends the charter with the necessary bits that wouldn't force someone to resign next time | 18:33 |
| bauzas | anyway, late here, bye \o | 18:38 |
| knikolla | o/ | 18:38 |
| opendevreview | Ghanshyam proposed openstack/governance master: Resolution to waive off the affiliation diversity in 2024.2 TC election https://review.opendev.org/c/openstack/governance/+/914026 | 19:05 |
| gmann | tc-members ^^ proposal for waive off option. please cast your vote/feedback | 19:06 |
| JayF | gmann: I'd ask that, similar to what I did, you W-1 that until Monday at least to allow time for discussion before considering anything a binding vote | 19:06 |
| gmann | JayF: done | 19:09 |
| spotz[m] | I'm trying real hard to catch up on the discussion | 19:09 |
| JayF | Thanks gmann | 19:10 |
| spotz[m] | Ok I think I've caught up and have a few things. We had not discussed things internally as mentioned already due to a personal issue currently taking place. I don't think you can have folks discuss who is running ahead of time because with different votes we wouldn't be in this situation so you would artificially lower your voting pool. I think we do need governance in place for this in the future, I honestly though we had the same | 19:26 |
| spotz[m] | procedure in place as the Board. Lastly to not affect the next election and temporary fix would need to be for a year or it's not fair to anyone who would want to run in 6 months. | 19:26 |
| spotz[m] | Did I miss anything major with that? | 19:26 |
| spotz[m] | s/though/thought/, s/and/any/ | 19:27 |
| spotz[m] | s/voting/candidate/, s/though/thought/, s/and/any/ | 19:28 |
| opendevreview | Merged openstack/governance master: Add PTL results from the 2024.2/Dalmatian election https://review.opendev.org/c/openstack/governance/+/913939 | 22:16 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!