| *** dasm is now known as dasm|off | 04:51 | |
| *** akahat|ruck is now known as akahat|ruck|lunch | 08:39 | |
| noonedeadpunk | gmann: yes, thanks a lot for onboarding email. I was already looking through current state and revising policies in memory) | 09:19 |
|---|---|---|
| *** akahat|ruck|lunch is now known as akahat|ruck | 09:31 | |
| *** frenzyfriday is now known as frenzyfriday|food | 11:11 | |
| *** frenzyfriday|food is now known as frenzyfriday | 12:00 | |
| *** dasm|off is now known as dasm | 14:17 | |
| gmann | noonedeadpunk: cool, thanks | 14:50 |
| opendevreview | Kristi Nikolla proposed openstack/governance master: Add nomination for chair for Kristi Nikolla https://review.opendev.org/c/openstack/governance/+/858947 | 14:54 |
| gmann | tc-members: need one review in the election results https://review.opendev.org/c/openstack/governance/+/858539 | 14:58 |
| gmann | #startmeeting tc | 15:00 |
| opendevmeet | Meeting started Thu Sep 22 15:00:12 2022 UTC and is due to finish in 60 minutes. The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'tc' | 15:00 |
| gmann | tc-members meeting time | 15:00 |
| dansmith | o/ | 15:00 |
| noonedeadpunk | o/ | 15:00 |
| gmann | #topic Roll call | 15:00 |
| JayF | o/ | 15:00 |
| gmann | o/ | 15:00 |
| rosmaita | o/ | 15:00 |
| slaweq | o/ | 15:00 |
| opendevreview | Kristi Nikolla proposed openstack/governance master: Add nomination for chair for Kristi Nikolla https://review.opendev.org/c/openstack/governance/+/858947 | 15:01 |
| knikolla | o/ | 15:01 |
| gmann | jungleboyj: and arne_wiebalck mentioned they will not be present today | 15:02 |
| gmann | #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions | 15:02 |
| gmann | today agenda ^^ | 15:02 |
| gmann | #topic Follow up on past action items | 15:02 |
| gmann | None from previous meeting | 15:02 |
| gmann | #topic Gate health check | 15:03 |
| gmann | any news on gate? | 15:03 |
| slaweq | nothing new from me | 15:03 |
| slaweq | things are still running pretty good AFAICT | 15:03 |
| dansmith | I have no gate info :( | 15:04 |
| rosmaita | no news is good news | 15:04 |
| rosmaita | if there was bad news, i think we would hear it | 15:05 |
| gmann | one update, py3.10 job is becoming voting now with the new template change and few projects might have it failing. | 15:05 |
| slaweq | rosmaita++ | 15:05 |
| gmann | projects need to fix that first like nova did | 15:05 |
| spotz__ | o/ | 15:05 |
| gmann | nothing else form me too on gate. going smooth | 15:05 |
| gmann | Bare 'recheck' state | 15:05 |
| gmann | #link https://etherpad.opendev.org/p/recheck-weekly-summary | 15:06 |
| gmann | slaweq: go ahead | 15:06 |
| slaweq | things are good | 15:06 |
| slaweq | I emailed PTLs of some projects which were constantly on 100% of bare rechecks | 15:06 |
| slaweq | but I did it just today morning | 15:06 |
| slaweq | so I will need to wait a bit for effects | 15:06 |
| slaweq | that's basically all update for today | 15:06 |
| gmann | +1, thanks | 15:07 |
| noonedeadpunk | I was actually thinking about reaching PTL during previous meeting, but decided not to chime in too much | 15:07 |
| noonedeadpunk | so thanks for that! | 15:07 |
| gmann | yeah, its good to spread the awareness more and more. | 15:08 |
| fungi | be aware that we're dropping support for ansible versions less than 5 in jobs this weekend | 15:08 |
| noonedeadpunk | that might be interesting actually | 15:09 |
| fungi | i sent a reminder to the ml already, but i expect it to be a no-op for most projects since we switched our default to 5 months ago and told people then this would be happening eventually | 15:09 |
| gmann | +1 | 15:09 |
| fungi | noonedeadpunk: it doesn't affect nested ansible in jobs, just the ansible versions available on the executors for job definitions | 15:09 |
| fungi | i think clarkb found a few places tripleo needed to drop some old version pins, but they're looking into that today supposedly | 15:10 |
| noonedeadpunk | fungi: yeah I do understand that. I'm jsut wondering what sdk version is there, as if it's from u-c that will conflict with openstack collection | 15:10 |
| fungi | codesearch doesn't really turn up anything else overriding it at this point | 15:10 |
| noonedeadpunk | or ansible-opsnatck-collection might be needed to pinned somewhere at master if sdk is 0.101 or smth | 15:11 |
| fungi | i don't think this would intersect with places where you're installing python packages. the ansible installs are in their own immutable venvs on the executors and you don't get the ability to install things in those | 15:11 |
| noonedeadpunk | nah, for osa it doesn't matter at all | 15:11 |
| JayF | Sounds like to me the best approach is to push the change and see if anyone screams, then? Shouldn't be a real concern? | 15:12 |
| clarkb | right we don't install the openstack collection unless it is part of the `ansible` package install | 15:12 |
| clarkb | we do install openstacksdk though | 15:12 |
| fungi | well, the change already got approved, but won't take effect until our automated restarts kick in early utc saturday | 15:12 |
| gmann | let's wait for this weekend when it happen and see if any fail | 15:12 |
| noonedeadpunk | IIRC venvs are not really immutable with zuul 6.0 +? | 15:12 |
| noonedeadpunk | anyway agree, let's try out and see | 15:12 |
| gmann | yeah | 15:12 |
| gmann | anything else on gate health or rechecks | 15:13 |
| gmann | #topic Zed cycle tracker checks | 15:13 |
| gmann | #link https://etherpad.opendev.org/p/tc-zed-tracker | 15:14 |
| gmann | seems like we are left with 5 items to finish | 15:14 |
| gmann | Technical guidlines for logging levels with more example or scenarios | 15:14 |
| gmann | Drive the OSC as community-wide goals, be or find champion | 15:14 |
| gmann | 2021 user survey analysis: | 15:14 |
| gmann | Recognize the new contributor work in some way: | 15:15 |
| gmann | basically 4 as i18 SIG things we will discussing in PTG | 15:15 |
| gmann | please update on those if you have any? | 15:15 |
| noonedeadpunk | I can say that for i18 I beleive most important are translations for horizon and it's plugins | 15:15 |
| noonedeadpunk | And I did consumed them for public clouds | 15:16 |
| rosmaita | does horizon pass through exception messages? | 15:16 |
| gmann | yeah but we are still collecting data who all using what all language translation | 15:16 |
| gmann | if no update, moving next | 15:19 |
| noonedeadpunk | rosmaita: well, I actually not sure about last 2 releases | 15:19 |
| gmann | let's discuss it in PTG based on some data about usage if we can get that | 15:20 |
| gmann | #topic 2023.1 cycle PTG Planning | 15:20 |
| gmann | TC + Leaders interaction sessions | 15:21 |
| gmann | #link https://etherpad.opendev.org/p/tc-leaders-interaction-2023-1 | 15:21 |
| gmann | ^^ this is etherpad for TC+Leaders session | 15:21 |
| gmann | schedule details are in etherpad which is Monday 15-17 UTC | 15:21 |
| gmann | TC PTG etherpad | 15:22 |
| gmann | #link https://etherpad.opendev.org/p/tc-2023-1-ptg | 15:22 |
| gmann | on TC slots, we discussed in last meeting that we want to use Thursday-Friday 15-17 UTC and 17-19 UTC slots | 15:22 |
| gmann | JayF: noonedeadpunk: as you were not in the discussion, are those slots ok for you both? | 15:23 |
| JayF | Absolutely; we're already planning around it in the (unfortunately, simultaneous) Ironic PTG planning meeting. | 15:23 |
| opendevreview | Merged openstack/governance master: Close Antelope Elections https://review.opendev.org/c/openstack/governance/+/858539 | 15:24 |
| noonedeadpunk | Should be fine for me | 15:24 |
| gmann | ohk, yeah it is difficult to avoid 100% conflict | 15:24 |
| spotz__ | Yeah Iput the OPS Meetup on Tuesday to avoid the TC and the ops related placeholders | 15:25 |
| gmann | spotz__: cool | 15:25 |
| JayF | (I don't mean conflicting with Ironic PTG; I mean literally I'm in a PTG planning call while doing this IRC meeting at the same time) | 15:25 |
| gmann | ack | 15:25 |
| gmann | and for 17-19 UTC slots which are out of PTG schedule. I checked with PTG organizer and diablo_rojo_phone replied on that. | 15:26 |
| gmann | it is difficult to update these timing in ptg bot at this stage as it need to upload the new json file resetting everything | 15:26 |
| JayF | Do we generally post .ics files for PTG sessions; similar as to for IRC meetings? If not, I suggest someone own sending out calendar invites to ensure there's clarity in scheduling | 15:26 |
| JayF | (and I volunteer to do it if folks think it's a good idea) | 15:27 |
| gmann | what we can do to publish these slot - update on ML, infra-event channel and ptg bot as 'next' thing | 15:27 |
| knikolla | that's a really good idea on the calendar invite | 15:27 |
| slaweq | ++ | 15:27 |
| gmann | JayF: that is good idea | 15:27 |
| JayF | I trust calendar software to make timezone calculations better than me, especially since that's near DST flip time in some juristictions. | 15:27 |
| dansmith | yeah ++ for ics files | 15:28 |
| knikolla | ice cream sandwich? :) | 15:28 |
| fungi | if someone wants to add that to the ptgbot code, we could presumably publish them on ptg.opendev.org | 15:28 |
| JayF | Unless we have a standard way of publishing ICS files, I was tempted to implement this with an actual-meeting-invite | 15:28 |
| fungi | seems like it would be a pretty straightforward feature | 15:28 |
| JayF | I do not want to volunteer to do what fungi suggests without looking at the code myself first :) | 15:28 |
| fungi | you, sir, are a wise man | 15:29 |
| gmann | sure, ics invite is always helpful | 15:29 |
| noonedeadpunk | but I do really like fungi idea | 15:29 |
| JayF | ack; I will put down an action for myself to investigate and either do it or come next week with something concrete to propose | 15:29 |
| gmann | JayF: thanks | 15:30 |
| knikolla | considering there's less(?) than a month for the ptg, let's only do it if it seems really easy | 15:30 |
| gmann | so on slots, let's continue on the thursday-friday 15-19 UTC slots for TC and we can spread the 17-19 slots to community in multiple way. | 15:30 |
| JayF | knikolla: that's pretty much exactly waht I had in mind, but don't want to punt something based on assumed difficulty, I want to find out for sure it's hard first :D | 15:30 |
| rosmaita | i think attaching the ics file to an email saying when the TC will be meeting should be fine for this PTG | 15:31 |
| knikolla | ++ | 15:31 |
| gmann | +1 | 15:31 |
| JayF | rosmaita: oh, to the mailing list, that's a good idea, and the obvious solution | 15:32 |
| gmann | and in next PTG, we can feedback about opening more slots to minimize the conflicts | 15:32 |
| JayF | Yeah, lets do that. Easy, simple, and I can duplicate it for Ironic :D | 15:32 |
| rosmaita | fungi: or does the mailer scrub attachments? | 15:32 |
| gmann | cool | 15:32 |
| fungi | rosmaita: it does not, attachments to the ml are fine but may end up getting moderated if the message encoded exceeds 40kb | 15:32 |
| gmann | I think ics cal are sent in many emails | 15:32 |
| rosmaita | cool, i think ics are pretty small | 15:33 |
| JayF | gmann: I'd assume if it's going out with the announcement email; you'll likely send it with the ICS? | 15:33 |
| JayF | gmann: just making sure I'm clear about what action is ahead of me :D | 15:33 |
| fungi | even if it does trip the limit, i moderate the messages at least daily most of the time | 15:33 |
| gmann | let's send on ML then | 15:33 |
| fungi | and if you do get it stuck in moderation, feel free to give me a heads up and i'll try to process it sooner | 15:33 |
| gmann | JayF: yes, I will post the final slots on ongoing thread and then you can send the ics file on that. is it fine? | 15:34 |
| JayF | gmann: ack; that works for me. I'll look for that email | 15:34 |
| knikolla | could we also put in on the main ptg page? https://openinfra.dev/ptg/ | 15:34 |
| gmann | #action JayF to send the ics file on TC PTG ML thread | 15:35 |
| gmann | knikolla: you mean ics or TC slots info? | 15:35 |
| JayF | knikolla: (if you mean ICS files) that would be what would require the change to ptgbot; we shouldn't IMO upload ics files to that webpage unless we are going to have them for all sessions | 15:36 |
| knikolla | meetings that we want to have a wider reach for. tc + community being the primary i can think of. | 15:36 |
| knikolla | Perhaps even a link to the mailing list message message is fine :) | 15:36 |
| rosmaita | well, we're kind of a special case because we're meeting out of the scheduled times | 15:37 |
| gmann | that is difficult as it need fresh json file to upload but yes we can put this info on ML and in channel | 15:37 |
| rosmaita | i think we could link to JayF's posting on the ML in the "next" message for the ptg bog | 15:37 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/governance master: [goal] Propose to use Ubuntu 22.04 for CI/CD https://review.opendev.org/c/openstack/governance/+/858690 | 15:37 |
| rosmaita | *bot | 15:37 |
| gmann | yeah | 15:37 |
| JayF | Sounds like there's a lot of interest in getting support for this in ptgbot in the longer-ish term. I'll follow up on that generally, see if I can assess difficulty and find a volunteer :D | 15:38 |
| gmann | ok | 15:38 |
| gmann | next thing - Schedule 'operator hours' | 15:38 |
| gmann | I see 5 projects booked the operator hours | 15:38 |
| noonedeadpunk | I haven;t seen much activity unfortunatelly | 15:39 |
| gmann | I will send reminder in next week or so for other projects | 15:39 |
| slaweq | I talked with lajoskatona about it this week | 15:39 |
| gmann | +1 | 15:39 |
| slaweq | and he was going to book some slot | 15:39 |
| slaweq | I didn't check if he did it already | 15:39 |
| gmann | please reachout to known projects/PTL to book it if they want | 15:39 |
| JayF | There is a little confusion in the PTG meeting I'm in right now for Ironic: are the placeholder meetings, e.g. like the one 1400 UTC on Weds, intended for projects to take ownership of | 15:40 |
| JayF | or are those cross-project? | 15:40 |
| JayF | **1300 UTC, not 1400 | 15:40 |
| noonedeadpunk | yeah, you should unschedule slot first | 15:41 |
| gmann | JayF: you can book them with new track like ironic-operator-hour and book slot either from placeholder which will help to avoid conflict from other ops sessions or book as per your schedule | 15:41 |
| JayF | ack; we want to take that 1300 UTC Wednesday session, we'll book it via that placeholder for Ironic | 15:41 |
| gmann | steps are 1. ask to book new track <project>-operator-hours 2. unbook placeholder slot 3. book that slot with new track | 15:41 |
| gmann | thanks | 15:42 |
| noonedeadpunk | fwiw step 2 was missing from original email | 15:42 |
| gmann | yeah, I missed that to mention | 15:42 |
| gmann | thought it is part of 3rd one but should have mentioned as separate | 15:43 |
| gmann | anything else on PTG things? | 15:43 |
| gmann | #topic 2023.1 cycle Technical Election & Leaderless projects | 15:44 |
| gmann | election results are merged #link https://review.opendev.org/c/openstack/governance/+/858539 | 15:44 |
| gmann | first thanks to election official spotz[m] knikolla jungleboyj ianychoi[m] for your help and smooth election | 15:44 |
| gmann | and welcome to the returning and new members noonedeadpunk JayF | 15:45 |
| JayF | o/ thank you | 15:45 |
| knikolla | welcome :) | 15:45 |
| slaweq | Welcome :) | 15:45 |
| noonedeadpunk | \o/ | 15:45 |
| noonedeadpunk | thanks | 15:45 |
| gmann | also thanks to chandan and jamespage for their nomination | 15:46 |
| spotz__ | congrats all | 15:47 |
| gmann | also we need to select chair for the next term | 15:47 |
| gmann | I saw knikolla nomination for that. its great | 15:48 |
| gmann | if anyone else also would like to raise hand for chair, please do | 15:48 |
| gmann | I will also would like to continue. will raise the nomination today | 15:48 |
| gmann | on PTL: we had 9 projects left without nomination and good news we found leaders for all of them | 15:49 |
| gmann | #link https://etherpad.opendev.org/p/2023.1-leaderless | 15:49 |
| gmann | I will raise their PTL appointment patches and there we can discuss about it | 15:49 |
| gmann | anything else on election ? | 15:49 |
| rosmaita | that's good news about the leaderless projects | 15:50 |
| rosmaita | i mean, not leaderless | 15:50 |
| gmann | yeah | 15:50 |
| gmann | #topic Meeting time check | 15:51 |
| gmann | as we have new members in TC, let's check the weekly meeting time | 15:51 |
| JayF | This time is extremely convienient for me. | 15:51 |
| gmann | we usually check in PTG but that is 4 meeting far | 15:51 |
| rosmaita | JayF: even after the time change? | 15:51 |
| JayF | I work 7a-4p most days, PT | 15:51 |
| rosmaita | i mean from DST | 15:51 |
| JayF | so either side of DST this is in my normal daily working hours | 15:52 |
| gmann | cool | 15:52 |
| gmann | noonedeadpunk: how about you? | 15:52 |
| JayF | (not to say I'm unwilling to go outside of that if needed :D) | 15:52 |
| gmann | we can discuss that in PTG especially on daylight things\ | 15:52 |
| rosmaita | i'm going to have a conflict after the USA time change, i think | 15:52 |
| gmann | just want to make sure those 4 meetings time until PTG are ok or not | 15:53 |
| noonedeadpunk | current time works for me nicely gmann | 15:53 |
| gmann | ok | 15:53 |
| rosmaita | oh, ok, should be fine until PTG | 15:53 |
| gmann | rosmaita: ack. let's do that daylight check in PTG | 15:53 |
| rosmaita | makes sense, sorry for the noise | 15:54 |
| gmann | one more update: I have moved to PST timezone (was in CST). | 15:54 |
| gmann | #topic Open Reviews | 15:54 |
| gmann | #link https://review.opendev.org/q/projects:openstack/governance+is:open | 15:54 |
| gmann | please review those when you have time. | 15:55 |
| gmann | noonedeadpunk: thanks for volunteering on CI/CD migration goal #link https://review.opendev.org/c/openstack/governance/+/858690 | 15:55 |
| gmann | that is all for today meeting, anything else anyone would like to discuss ? | 15:56 |
| noonedeadpunk | I actually don't know if that's a valid goal given there's already reference in place | 15:56 |
| noonedeadpunk | https://governance.openstack.org/tc/reference/runtimes/2023.1.html | 15:56 |
| noonedeadpunk | * #link https://governance.openstack.org/tc/reference/runtimes/2023.1.html | 15:56 |
| fungi | the goal provides extra visibility to remind projects they'll need to do work to transition | 15:56 |
| gmann | noonedeadpunk: that is valid goal. this migration is big task and need lot of testing and coordination | 15:57 |
| gmann | testing in advance before we switch base devstack and tox jobs to new version | 15:57 |
| noonedeadpunk | but I guess I will bug you gmann on how it was done before if get stuck somewhere | 15:57 |
| gmann | noonedeadpunk: sure, will help you on this. | 15:57 |
| gmann | anything else ? 2 min left | 15:58 |
| JayF | I'll say generally, as a new TC member I'm looking for input and am willing to chat with anyone who wants to chat. If you wanna chat virtually, reach out. If you're in Puget Sound, WA metro area, lets have lunch sometime. I'm going to be dedicating my first bit of time on TC to factfinding/expanding and these chats would feed into that. This goes triple-y so for my | 15:58 |
| JayF | co-TC-members. | 15:58 |
| spotz__ | Just a reminder we need to pull the AUC list before elections next time to include them | 15:58 |
| rosmaita | oops | 15:58 |
| gmann | ack. | 15:59 |
| gmann | 'AC' list | 15:59 |
| knikolla | this election cycle had a fair number of lessons learned. | 15:59 |
| gmann | anyone can propose to be in AC list and TC can review it | 15:59 |
| spotz__ | Yeah, and some repos likke governance, meetings, etc don't count apparently | 15:59 |
| gmann | knikolla: good, let's collect those in retrospective in PTG. it will be good for new members helping in future | 16:00 |
| knikolla | ++, i can work on that. | 16:00 |
| * noonedeadpunk totally missed all elections mess details | 16:00 | |
| spotz__ | knikolla: Lets do that in election channel to get everyone's comments | 16:00 |
| fungi | spotz__: the tc-repos.yaml uses the same schema as sigs-repos.yaml so could be trivially added to the election tooling | 16:00 |
| gmann | added it in etherpad in case we forget | 16:00 |
| knikolla | spotz__: ++ | 16:00 |
| gmann | spotz__: +1 | 16:00 |
| spotz__ | fungi: I personally think any patch should count especially as we're now AC vs ATC only for voting | 16:01 |
| gmann | ok, thanks all for joining. our next week meeting will be on sept 29 | 16:01 |
| spotz__ | Thanks gmann, everyone | 16:01 |
| slaweq | thx gmann for leading it | 16:01 |
| slaweq | thx everyone o/ | 16:01 |
| gmann | spotz__: let's discuss it in PTG | 16:01 |
| gmann | spotz__: this is god point | 16:01 |
| JayF | o/ | 16:01 |
| gmann | *good | 16:02 |
| gmann | #endmeeting | 16:02 |
| opendevmeet | Meeting ended Thu Sep 22 16:02:05 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:02 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2022/tc.2022-09-22-15.00.html | 16:02 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2022/tc.2022-09-22-15.00.txt | 16:02 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2022/tc.2022-09-22-15.00.log.html | 16:02 |
| fungi | spotz__: i agree. someone just needs to patch the election repo to add it (and get the tc to okay that addition, maybe via a very simple resolution) | 16:02 |
| fungi | i think there was a similar resolution when we added support for sigs-repos.yaml, but i don't have time to go hunting for it just now | 16:02 |
| gmann | spotz__: knikolla: added the election things, feel free to add other points in etherpad https://etherpad.opendev.org/p/tc-2023-1-ptg#L34 | 16:04 |
| opendevreview | Ghanshyam proposed openstack/governance master: Add Ghanshyam nomination as chair https://review.opendev.org/c/openstack/governance/+/858957 | 16:33 |
| gmann | tc-members: need on more vote on CI/CD migration goal https://review.opendev.org/c/openstack/governance/+/858690/2..3 | 16:35 |
| gmann | tc-members: for Chair: we have two nomination now 1. knikolla : https://review.opendev.org/c/openstack/governance/+/858947 2. gmann: https://review.opendev.org/c/openstack/governance/+/858957 | 16:36 |
| noonedeadpunk | question: shouldn't gerrit ACLs be re-applied for governance repo with voting closure? | 16:37 |
| gmann | let's keep it open till Tuesday in case anyone else would like to raise hand | 16:37 |
| noonedeadpunk | Or it's manual thing? | 16:37 |
| gmann | noonedeadpunk: yeah, I am updating that right now. | 16:37 |
| gmann | I was waiting for the election patch merge | 16:37 |
| gmann | thanks for reminder | 16:37 |
| noonedeadpunk | yeah, fair enough. I just thought there's some post-merge job present but then realized there's nothing there :) | 16:38 |
| gmann | noonedeadpunk: JayF done, please check | 16:39 |
| noonedeadpunk | yep, works for me now, thanks! | 16:39 |
| JayF | wfm | 16:40 |
| gmann | perfect | 16:41 |
| dansmith | gmann: are we to vote by +1ing the nomination we think is best, or do we land both noms and then have an election? | 17:29 |
| dansmith | (or a knock-out drag-out fight in a jello pit?) | 17:30 |
| gmann | dansmith: we can go with the election voting and based on the result we will merge one of the nomination. | 17:36 |
| gmann | tc-members ^^ | 17:36 |
| gmann | that is how we did in past | 17:36 |
| gmann | May be on Tuesday we can start the election open for a week or until all TC members vote | 17:37 |
| noonedeadpunk | +1 on CR on rollcall? | 17:38 |
| noonedeadpunk | *or | 17:38 |
| JayF | https://governance.openstack.org/tc/reference/charter.html#election-systems concorcet style is dictated by policy | 17:38 |
| noonedeadpunk | I'm not sure we can merge both this way to be fair | 17:39 |
| JayF | although if we only have two candidates, the difference between that and usual fptp voting is nil; but it might be worthwhile to use CIVS to enforce anonymity, unless it's intended to be a public vote | 17:39 |
| noonedeadpunk | As then we're gonna have 3 chairs until election ends | 17:39 |
| noonedeadpunk | s/3/2/ | 17:39 |
| gmann | yeah, we should not merge both. after we decide/elect one then only | 17:39 |
| noonedeadpunk | I'd say using election would be more proper way, but kind of more problematic. Though good for history | 17:40 |
| gmann | and yes CIVS to enforce anonymity | 17:40 |
| noonedeadpunk | Question - shouldn't be nominations be merged somewhere at least for the record? | 17:41 |
| dansmith | yeah my thought was that we merge both, but then wasn't sure when I went to go +1 the other | 17:42 |
| gmann | it will be private election among TC members with 9 electorate | 17:42 |
| gmann | noonedeadpunk: we need separate nomination way then, merging both will show two 'chair' in tc page which can be confusing | 17:43 |
| JayF | noonedeadpunk: gmann: Isn't an open review in gerrit sufficient documentation? | 17:43 |
| gmann | adding nomination in gerrit should be enough for history also? | 17:43 |
| gmann | JayF: yeah | 17:43 |
| noonedeadpunk | JayF: one will be abandoned? | 17:43 |
| gmann | noonedeadpunk: yes | 17:43 |
| gmann | 1. nomination on gerrit 2. election 3. based on result merge one and abandon other nomination | 17:44 |
| noonedeadpunk | I'd say it depends if we wanna go easy or proper way | 17:44 |
| JayF | I'd just be curious if we've had, in the history of the tc, a need for that historical data and pain felt not being able to find it. | 17:44 |
| gmann | these are example of previous such election - https://review.opendev.org/c/openstack/governance/+/680414 https://review.opendev.org/c/openstack/governance/+/681285 | 17:44 |
| JayF | I don't think we have; and I'm not opposed to making it more formal, I just do not want us to make-work when there's a lot of work to do :D | 17:45 |
| noonedeadpunk | As proper would be having some TC-chair election and nominations pushed/merged there | 17:45 |
| gmann | https://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_e6963bddd2f49d57&algorithm=beatpath | 17:45 |
| gmann | sure | 17:46 |
| gmann | let's go with the current way (nomination in gerrit) this time and later we can discuss about proper way to record nomination/election etc. is it fine? | 17:47 |
| noonedeadpunk | but yeah, I don't have really strict opinion on that as don't have right today time to work on that | 17:47 |
| noonedeadpunk | yes, that's great plan! | 17:47 |
| fungi | if there is some future question about it, the gory details will be covered in recorded tc meetings anyway | 17:48 |
| gmann | and we can update it in CHAIR.rst also https://github.com/openstack/governance/blob/master/CHAIR.rst#around-tc-elections | 17:48 |
| fungi | and will link to the relevant changes (abandoned or merged) and poll results | 17:48 |
| gmann | noonedeadpunk: JayF : added it in PTG etherpad to discuss/implement https://etherpad.opendev.org/p/tc-2023-1-ptg#L39 | 17:50 |
| opendevreview | Ghanshyam proposed openstack/governance master: Appoint Dale as Adjutant PTL https://review.opendev.org/c/openstack/governance/+/858967 | 18:16 |
| JayF | gmann: do normal requirements still apply to appointed PTLs? e.g. member of foundation and AC on project in question? If so, should we put those reciepts on the review? | 18:20 |
| JayF | trying to answer my own question -> https://governance.openstack.org/tc/resolutions/20141128-elections-process-for-leaderless-programs.html looks like no requirements other than TC vetting | 18:22 |
| gmann | JayF: yes, no requirement on appointment. It is only TC voting. | 18:24 |
| JayF | In the past, has there historically been any bar at all? Or, maybe better to ask: has TC ever chosen to not appoint someone PTL who volunteered | 18:26 |
| JayF | Just trying to get the balance between how much time to spent while not becoming a human rubber stamp :) | 18:26 |
| fungi | yes, the idea is that it's entirely up to the tc how openstack is governed. the tc decides that it's structured as a set of teams each with their own distinct leadership and that there's an electoral process by which contributors to those teams can qualify to lead them. if that process fails, it's back to the tc to decide who serves as leaders of those teams (they were the ones who chose | 18:26 |
| fungi | the voting process as the first line selection mechanism anyway) | 18:26 |
| JayF | fungi: ack; thanks. That mostly fits with what I expected and understood ... I guess I'm trying to wrap my head around precedent or "common law" things that have been done in the past. I want to know where things are so if I buck the trend, it's done deliberately rather than accidentally. | 18:28 |
| fungi | it's basically a self-imposed process (via the tc charter, which the tc can vote to amend as required) | 18:28 |
| gmann | JayF: no AFAIK, usually PTL appointment comes when there is no one else to volunteer and we vote on it based on their volunteer | 18:28 |
| knikolla | I don't remember there being a time that the TC rejected a nomination | 18:28 |
| JayF | Bluntly, it just seemed a little strange to me to appoint someone to PTL a project they likely are not an AC on (I only have done a cursory check). That's mainly why I was asking. | 18:28 |
| fungi | agreed, the precedent has been "if there's no qualified candidate, but there's a volunteer, they're welcome to it" | 18:29 |
| gmann | yeah, even in some cases, people volunteer to be PTL as very new member/contributor to the project even they are not core in that | 18:29 |
| fungi | similarly, sometimes we've had ptls who were so focused on meta-tasks that they didn't technically qualify to run for the position any longer | 18:29 |
| gmann | JayF: and most cases, there are no other AC in that project or they do not want to be PTL | 18:30 |
| JayF | So basically a situation of -- once a project is understaffed enough to have no PTL nominations for election; appointing anyone expressing a willingness to pull it forward is the best of unfortunate options | 18:30 |
| fungi | granted, the workaround for that is to have them proposed as an extra-atc in that team prior to the extra-atc deadline | 18:30 |
| fungi | JayF: precisely | 18:30 |
| gmann | when they become PTL they usually become AC except one case I think Zun | 18:30 |
| knikolla | it's that or retiring the project. | 18:31 |
| knikolla | or turning it into a dpl model. | 18:31 |
| gmann | Basically we do not want to reject anyone volunteering to help as leader. that project is how active and merging incoming request/bugs etc are different thing to discuss | 18:31 |
| gmann | turning to DPL model is not much different, it is retiring in many cases in past | 18:32 |
| JayF | That makes a lot of sense. Basically if the project was so stagnant that even a volunteer-ptl isn't making contributions, we have a separate discussion about future of that project | 18:32 |
| fungi | one interesting implication of the earlier discussion to add non-team/non-sig repo contributors as part of the electorate: you can qualify to vote in the tc election "simply" by running for ptl in the previous cycle (since you'll have had a commit merged to the election repo) | 18:32 |
| JayF | but until that discussion happens it makes everyone's life easier to have a ptl | 18:32 |
| opendevreview | Ghanshyam proposed openstack/governance master: Appoint Dave as Keystone PTL https://review.opendev.org/c/openstack/governance/+/858969 | 18:32 |
| JayF | fungi: if someone cares enough about it to run to get their vote; they care more than some of the ACs who didn't turn out for the last election. I don't see that as a problem (at least until/unless we /actually/ see a DoS attack on the electorate via massive nomination spam) | 18:33 |
| fungi | yep, i didn't mean to say it was a bad thing | 18:33 |
| fungi | just an interesting side effect | 18:34 |
| knikolla | a question i hadn't considered before: does someone being elected ptl of a project confer core to the project? | 18:34 |
| knikolla | on* | 18:34 |
| JayF | knikolla: I think, by policy, they get to decide that :) | 18:34 |
| fungi | knikolla: yes, effectively | 18:34 |
| JayF | Also it's hard to do some required things as PTL if you didn't have core | 18:34 |
| fungi | they can choose not to be, but it's up to them how the team is structured and whether there even is a core reviewer team | 18:34 |
| gmann | knikolla: it depents. and not all the repo of that project but few they can be core | 18:35 |
| knikolla | I guess I'll ask Dave | 18:35 |
| gmann | and after PTL they can be core in other repo also as they contribute | 18:35 |
| fungi | voting for ptl is an escape hatch in situations where the contributors to the project are dissatisfied with the current core review team and want to elect someone who can replace them | 18:35 |
| gmann | like glance current PTL, I think not core in glance repo but in other glance repo | 18:35 |
| gmann | anyways being Core is also separate discussion within team and does require PTL to be core everywhere | 18:36 |
| fungi | does _not_ require, i assume you mean | 18:36 |
| gmann | :) yeah * does not | 18:36 |
| gmann | same mistake again | 18:37 |
| knikolla | that was my assumption, that they have the authority to decide who becomes core, including themselves. | 18:37 |
| knikolla | But that it doesn't inherently grant that. | 18:38 |
| JayF | gmann: see my feedback on the first of these appointment PRs; they are all going to fail CI unless 2023.1 is quoted in that list | 18:38 |
| gmann | team has authority actually not just PTL | 18:38 |
| JayF | gmann: looks like it's interpreting it as a json float, not as a json string, and the schema requires strings | 18:38 |
| gmann | JayF: ack, fixing | 18:39 |
| knikolla | "A successful appointment can be made solely by the PTL, however it is encouraged to hear the opinions of the existing core team." | 18:39 |
| knikolla | https://docs.openstack.org/project-team-guide/ptl.html | 18:39 |
| noonedeadpunk | imo that's a bit wrong... It does cover case when no other cores are available | 18:39 |
| gmann | yeah, usually PTL coordinate but usually team agreement. I have not seen case where majority of team deny Core to anyone and PTL force it | 18:40 |
| gmann | noonedeadpunk: yes , in that case there is no choice | 18:40 |
| gmann | like Adjutant | 18:40 |
| noonedeadpunk | I have seen cases when PTL grants Core without asking anybody which results in a surprise in team about having new core... | 18:41 |
| knikolla | with great power comes great responsibility | 18:41 |
| JayF | Like fungi said -- it being written that way acts as a release valve where contributors can change the core group via voting for a new ptl | 18:42 |
| noonedeadpunk | Which why I said that phrasing to my taste is a bit meh | 18:42 |
| JayF | and for the case noonedeadpunk mentions; imo the election *is* the check and balance for that | 18:42 |
| noonedeadpunk | well yeah, that's true | 18:43 |
| noonedeadpunk | So basically ptl also can decide on policy when to revoke core roles I guess? | 18:44 |
| fungi | exactly | 18:44 |
| JayF | In the current model, afaict, core team is mostly PTL discretion, and in practice in openstack, we usually get unanimous consent before doing it. | 18:44 |
| gmann | yes, same way they add. after team consultation | 18:44 |
| JayF | a PTL can violate that practice at their own peril next election cycle :) | 18:44 |
| gmann | true | 18:44 |
| fungi | core reviewers are essentially delegates of the ptl, and the ptl can delegate that work to anyone they choose (including delegating the process by which that delegation is made) | 18:45 |
| * noonedeadpunk start thinking about freenode for some reason | 18:45 | |
| JayF | noonedeadpunk: remember in this case: TC and foundation are an ultimate pressure release valve | 18:45 |
| JayF | noonedeadpunk: I don't imagine we would sit around and permit a hostile takeover of a project, even if a duly elected PTL was doing it. | 18:46 |
| fungi | in reality, ptls have generally delegated the decision of who serves as a core reviewer to the other core reviewers with some degree of final oversight, but the process varies by team | 18:46 |
| fungi | also, yes, ptls and dpls serve at the discretion of the tc, who in turn serves at the discretion of the tc electorate | 18:46 |
| gmann | and PTL cannot force the things it needs to be agreed in team even technical matters or process | 18:46 |
| noonedeadpunk | yeah, I was always acting according to that, as appears, unwritten rule. But was sure it's written somewhere... | 18:47 |
| fungi | inability to force people to do specific work is more of a natural law of the choice to participate, of course | 18:47 |
| JayF | I like that we operate on a trust, but verify model instead of dictating exact, detailed process to each underlying project. | 18:47 |
| noonedeadpunk | nah, exact processes close to never bring intended results | 18:49 |
| noonedeadpunk | because it's quite impossible to make process really precise | 18:49 |
| knikolla | and it's hard to change them once you get them wrong. | 18:49 |
| noonedeadpunk | and there always be flaws on top | 18:50 |
| fungi | if you try to dictate every last detail, you end up crushed under the weight of the bureaucracy you've created | 18:50 |
| JayF | I also strongly thing one size does not fit all. | 18:50 |
| JayF | So like, it's not just "more bureaucracy can crush you" for me, and more "trust the project to know what's best in most cases" | 18:51 |
| gmann | well, it is not about PTL but core members also can go wrong in same way. | 18:52 |
| noonedeadpunk | Yeah. That all true. I'm just thinking about case some PTL will come and bring whooooole new core team to some project. Yes, TC will sort this out and revert things back, but media effect it can take can be... interesting | 18:53 |
| gmann | its on let project do the way they want and with common agreement. it cannot be same in such large projects list like 50 in OpenStack | 18:53 |
| knikolla | it used to be the case where each of those teams was 20+ people, now teams are significantly smaller on average. | 18:54 |
| knikolla | enacting processes under those conditions it's even harder. | 18:54 |
| knikolla | for a month or so i was the only active core in keystone, haha. | 18:55 |
| gmann | knikolla: and when we use to have event party for Core member only :) I remember one in Vancouver, I think that was last | 18:55 |
| fungi | don't discount that there may be times where a ptl wholesale replacing existing core reviewers may be the best way to deal with a situation | 18:55 |
| * JayF == fungi | 18:56 | |
| JayF | Also, that's the kind of problem that'd be great to have. "I have an army of python devs I want to point at this openstack project" | 18:56 |
| JayF | I'd hope if something like that happened, we could teach folks how to operate in good faith and bring them into the fold :) | 18:56 |
| noonedeadpunk | and that doesn't make things easier at all to judge upon such situations | 18:56 |
| fungi | more like "rotten borough" type situations | 18:56 |
| noonedeadpunk | as we're having not only open source, but also open design, which is quite important | 18:58 |
| noonedeadpunk | and bringing army of devs will likely neglect open design | 18:58 |
| fungi | though the tc can always step in and appoint a ptl contradictory to the will of the official contributors to that project, if necessary (that would likely require a supermajority of the tc to amend the charter to do so, but it's possible) | 18:58 |
| gmann | I think its all a great discussion and thought and we should have that in charter. | 18:59 |
| JayF | noonedeadpunk: the situation you describe maps very closely to when my team at Rackspace started getting involved in Ironic. We dropped in 4-5 devs, added a project (ironic-python-agent), and all got core on that project immediately. It took months for us to get the driver for that agent merged, the entire time Aeva Black was teaching us, with tough love, how to properly do | 18:59 |
| JayF | design in the open. | 18:59 |
| fungi | we've definitely had the situation before that a core reviewer was accused of padding the ptl electorate just before an election. thankfully those days are far in the rear view mirror now | 19:00 |
| gmann | any volunteer to start it to update it in charter? | 19:00 |
| JayF | noonedeadpunk: I would hope that in the future, if that kind of problem happened, it'd look more like that than someone trying for some sort of power grab | 19:00 |
| knikolla | update what specifically? | 19:01 |
| gmann | similarly we have for TC also in the Board bylawys | 19:01 |
| fungi | i take an approach to governance similar to software development: don't prematurely optimize (the results of doing so are often quite similar). make sure your governance gives you pressure valves you can turn to solve these problems, even if they're "2/3 majority of tc votes to adjust the charter so it can solve a problem" | 19:02 |
| noonedeadpunk | JayF: oh yes, totally agree. that would be extremely nice :) | 19:02 |
| gmann | update to have some way to replace/remove PTL based on majority of core member ? | 19:02 |
| JayF | I would not be in favor of a change to our charter in that way, for mostly the reason fungi indicates. If such an extreme case happened, we could deal with it with a charter change at that point in time. | 19:03 |
| knikolla | I don't think that change is necessary. The cores can reach out to the TC which can investigate and take appropriate action. | 19:03 |
| knikolla | If TC can't take a decision, the question can be brought to the board by 3 TC members. | 19:03 |
| gmann | sure but there is no harm to have something in advance if that situation occur | 19:04 |
| fungi | basically, anything that isn't already baked into the foundation bylaws is up to the tc to decide, so make some basic declarations about how things work and make sure you have the option to vote to change how those things work if they become problematic for some reason | 19:04 |
| gmann | of course we can do that time also but updating the charter at specific situation can have some question | 19:05 |
| fungi | amending the bylaws once you decide there's a situation which warrants it is fine, unless you're worried that a third of the tc will vote against the interests of the project when it comes time to amend the charter | 19:05 |
| noonedeadpunk | I have no opinion if that should be in board bylaws (probably not?) but likely won't hurt if some statement will be done in governance | 19:05 |
| gmann | yeah, not in Board Bylaw but having one line or two in TC charter can clarify it in better way | 19:06 |
| fungi | also be aware that anything you put in the charter now can be removed by the tc in 6 months if 2/3 of them agree it's a good idea to do so | 19:06 |
| JayF | Isn't this basically how the PTL appointment policy got written? We needed one, it was created, \o/ | 19:06 |
| gmann | and it would not be like, 'oh I as PTL wanted to do these change and now you are removing me by charter change such a trick :)' | 19:06 |
| knikolla | Is there anything today preventing the TC from removing a PTL if such a case occurs? | 19:06 |
| * JayF afk for a while, but will read scrollback | 19:07 | |
| gmann | I think we do not have anything written on how to remove PTL or can TC do or not? | 19:07 |
| noonedeadpunk | Which means technically TC can. But again, in nasty cases there will be media/reputational risks involved. | 19:08 |
| gmann | yeah that one mainly. to avoid that i was thinking to have some line written | 19:09 |
| noonedeadpunk | yup | 19:09 |
| gmann | we do not need to define the whole criteria but instead just writing something like "In some circumstances, TC can remove the PTL of project with a formal-vote motion" | 19:10 |
| gmann | and TC can take that decision based on various factor like consulting the Core, any odd activity if PTL is only core in that..... | 19:11 |
| noonedeadpunk | +1 | 19:12 |
| opendevreview | Ghanshyam proposed openstack/governance master: Appoint Dale as Adjutant PTL https://review.opendev.org/c/openstack/governance/+/858967 | 19:12 |
| gmann | JayF: ^^ fixed the schema validation | 19:12 |
| knikolla | sure, something vague like that which just reiterates that the TC can works. | 19:13 |
| gmann | yeah | 19:13 |
| knikolla | but I don't quite see how the reputational risk is bigger if we don't have that line there? | 19:14 |
| fungi | i'm pretty sure that regardless of whether the charter encodes explicit provisions/process for the tc replacing a ptl, the media response will be the same when it happens | 19:22 |
| * JayF == fungi | 19:24 | |
| knikolla | ++ | 19:25 |
| opendevreview | Ghanshyam proposed openstack/governance master: Appoint Dave as Keystone PTL https://review.opendev.org/c/openstack/governance/+/858969 | 19:27 |
| JayF | I'll also note that I explicitly appreciate that taking that kind of action (PTL removal) would take a 2/3rds vote, and wouldn't want it to be reduced to usual TC voting mechanisms either. | 19:30 |
| fungi | which encoding it in the charter would result in (unless the charter specified a 2/3 majority for that vote as well) | 19:31 |
| JayF | That's exactly what I mean. | 19:32 |
| gmann | sure but we will avoid situation saying "for my case you are updating charter now and there was no such rule before" | 19:33 |
| JayF | TBH I think this entire discussion is looking away from the absolute mess that would be happening in the mailing list, gerrit, and other platforms we frequent before it got to this point. | 19:33 |
| gmann | it is not about how many TC vote we want, it is about putting something in advance not at the time of situation occur | 19:33 |
| opendevreview | Ghanshyam proposed openstack/governance master: Appoint Alex as OpenStack_Charms PTL https://review.opendev.org/c/openstack/governance/+/858973 | 19:34 |
| JayF | I'd rather operate under the assumption we'd never need it, and that it falls under a litany of other unlikely-but-extreme cases where we can't (and shouldn't) dictate a solution ahead of time for every possibility. | 19:36 |
| dansmith | are we purely talking about hypothetical things here or are we in need of some decision for a pending situation? | 19:36 |
| JayF | dansmith: I think I started this by accident when asking about what the historical bar was for an appointment of a PTL | 19:36 |
| fungi | i'd argue it's a case of "premature optimization" adding more policy just in case you think you might need it in the future, even though you can still add it in the future when you actually need it | 19:36 |
| JayF | dansmith: all 10000% theoretical | 19:36 |
| dansmith | fungi: yeah I'd rather not do that without at least one real example, as I think the details of real life will always be different than what you think up during exercises like this | 19:37 |
| dansmith | "cross that bridge when we come to it" is the approach I'd favor for stuff like this | 19:37 |
| dansmith | years ago we never thought we'd be in this sort of situation and I kinda expect if we wrote rules then we'd have gotten them wrong | 19:37 |
| knikolla | ++ | 19:38 |
| opendevreview | Ghanshyam proposed openstack/governance master: Appoint yoctozepto as Masakari PTL https://review.opendev.org/c/openstack/governance/+/858974 | 19:39 |
| opendevreview | Ghanshyam proposed openstack/governance master: Appoint Qiu as Sahara PTL https://review.opendev.org/c/openstack/governance/+/858975 | 19:45 |
| opendevreview | Ghanshyam proposed openstack/governance master: Appoint Liu as Senlin PTL https://review.opendev.org/c/openstack/governance/+/858976 | 19:47 |
| opendevreview | Ghanshyam proposed openstack/governance master: Appoint Tim as Swift PTL https://review.opendev.org/c/openstack/governance/+/858978 | 19:50 |
| opendevreview | Ghanshyam proposed openstack/governance master: Appoint Zhang as Venus PTL https://review.opendev.org/c/openstack/governance/+/858979 | 19:54 |
| opendevreview | Ghanshyam proposed openstack/governance master: Appoint Feng as Zun PTL https://review.opendev.org/c/openstack/governance/+/858980 | 19:58 |
| gmann | tc-members ^^ raised patch for all 9 projects PTL appointment ad ready to vote. | 20:05 |
| *** dasm is now known as dasm|off | 22:33 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!