| opendevreview | Masahito Muroi proposed openstack/election master: Adding Masahito Muroi candidacy for Masakari 2027.1 https://review.opendev.org/c/openstack/election/+/1001265 | 01:48 |
|---|---|---|
| opendevreview | Yasufumi Ogawa proposed openstack/election master: Add Yasufumi Ogawa candidancy for Tacker 2027.1 https://review.opendev.org/c/openstack/election/+/1001286 | 06:10 |
| gouthamr | spotz[m]: ty for letting me know | 06:11 |
| frickler | iiuc https://review.opendev.org/c/openstack/election/+/1001265 is going to end up in an appointment being needed, but our new rules wouldn't have helped either, since there was no core-reviewing activity. in retrospect this would likely have been a good extra-AC candidate, though | 07:30 |
| opendevreview | Merged openstack/election master: adding sean mooney's ptl candidacy for cyborg https://review.opendev.org/c/openstack/election/+/1001180 | 12:10 |
| opendevreview | Merged openstack/election master: Add Brian Haley (haleyb) candidacy for Neutron PTL https://review.opendev.org/c/openstack/election/+/1001188 | 12:11 |
| opendevreview | Merged openstack/election master: Add Takashi Kajinami candidacy for Heat https://review.opendev.org/c/openstack/election/+/1001197 | 12:16 |
| opendevreview | Merged openstack/election master: Add Taakshi Kajinami candidacy for Storlets https://review.opendev.org/c/openstack/election/+/1001198 | 12:16 |
| opendevreview | Merged openstack/election master: Add Artem Goncharov candidacy for TC https://review.opendev.org/c/openstack/election/+/1001199 | 12:16 |
| opendevreview | Merged openstack/election master: Adding Christian Berendt candidacy for TC https://review.opendev.org/c/openstack/election/+/1001203 | 12:16 |
| opendevreview | Merged openstack/election master: Add Douglas Viroel candidacy for Watcher 2027.1 PTL https://review.opendev.org/c/openstack/election/+/1001208 | 12:16 |
| opendevreview | Merged openstack/election master: Add Callum Dickinson candidacy for Adjutant (2027.1) https://review.opendev.org/c/openstack/election/+/1001234 | 12:23 |
| opendevreview | Merged openstack/election master: add Doug Goldstein's candidacy for the 2027.1 TC https://review.opendev.org/c/openstack/election/+/1001250 | 12:23 |
| opendevreview | Merged openstack/election master: Adding Brian Rosmaita candidacy for Cinder https://review.opendev.org/c/openstack/election/+/1001236 | 12:23 |
| opendevreview | Merged openstack/election master: Adding Rafael Weingärtner candidacy for Cloudkitty 2027.1 https://review.opendev.org/c/openstack/election/+/1001232 | 12:23 |
| opendevreview | Mauricio Harley proposed openstack/election master: Adding Mauricio Harley candidacy for Barbican https://review.opendev.org/c/openstack/election/+/1001338 | 13:31 |
| opendevreview | Takashi Kajinami proposed openstack/election master: Add Takashi Kajinami candidacy for Puppet OpenStack https://review.opendev.org/c/openstack/election/+/1001345 | 13:57 |
| opendevreview | ribaudr proposed openstack/election master: Adding René Ribaud candidacy for Nova 2027.1 PTL https://review.opendev.org/c/openstack/election/+/1001347 | 14:04 |
| opendevreview | Carlos Eduardo proposed openstack/election master: Add Carlos da Silva candidacy for Manila PTL https://review.opendev.org/c/openstack/election/+/1001357 | 14:17 |
| *** M00SE1 is now known as M00SE | 15:30 | |
| gouthamr | tc-members: a gentle reminder that our weekly meeting will be hosted here in ~35 minutes | 16:24 |
| gouthamr | #startmeeting tc | 17:00 |
| opendevmeet | Meeting started Tue Aug 18 17:00:25 2026 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
| opendevmeet | The meeting name has been set to 'tc' | 17:00 |
| gouthamr | Welcome to the weekly meeting of the OpenStack Technical Committee. A reminder | 17:00 |
| gouthamr | that this meeting is held under the OpenInfra Code of Conduct available at | 17:00 |
| gouthamr | https://openinfra.dev/legal/code-of-conduct. | 17:00 |
| gouthamr | Today's meeting agenda can be found at | 17:00 |
| gouthamr | https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 17:00 |
| gouthamr | #topic Roll Call | 17:00 |
| cardoe | o/ | 17:00 |
| cardoe | look at that I was in the right tab | 17:01 |
| gouthamr | :P | 17:01 |
| frickler | \o | 17:01 |
| noonedeadpunk | o/ | 17:02 |
| gouthamr | courtesy-ping: dansmith, mnasiadka | 17:02 |
| gouthamr | noted-absence: spo tz, ba uzas | 17:02 |
| dansmith | o/ | 17:02 |
| mnasiadka | o/ | 17:03 |
| gouthamr | alright, that's everyone, let's get started | 17:04 |
| gouthamr | #topic Last Week's Action Items | 17:04 |
| gouthamr | let's look at the AC/APC charter change to count active core reviewers.. fungi's been working on the changes to the election tooling | 17:05 |
| gouthamr | so far, we've not seen any active core reviewer that also needed to be qualified through the new rule when vetting PTL candidates | 17:06 |
| gouthamr | tangent: frickler pointed out that masakari's current PTL wouldn't have qualified, there are a lot of peripheral changes, including active participation in the team's meetings etc, but none in repos tracked as the masakari project team | 17:07 |
| fungi | yeah, the behavior change is on top of a growing stack of refactors so that we don't end up with a massive amount of code duplication. hoping to get the actual meat of it up later today | 17:07 |
| gouthamr | ack the "email deadline" - where the community's expected to confirm their gerrit emails/individual foundation membership is tomorrow (Aug 19, 2026 00:00 UTC) | 17:08 |
| opendevreview | Felipe Reyes proposed openstack/election master: Adding Felipe Reyes candidacy for OpenStack_Charms 2027.1 https://review.opendev.org/c/openstack/election/+/1001386 | 17:08 |
| fungi | to semi-quote douglas adams, that script wasn't so much designed as congealed | 17:08 |
| gouthamr | after which electoral rolls would be created, if elections are warranted, this is the place where we'd see some impact of the changes | 17:09 |
| gouthamr | ack, this is a project :) ty for working through the changes fungi | 17:09 |
| gouthamr | #link https://review.opendev.org/c/openstack/election/+/1000991 | 17:09 |
| gouthamr | #link https://review.opendev.org/c/openstack/election/+/1000992 | 17:09 |
| fungi | a little of the precursor refactoring has already merged too | 17:09 |
| gouthamr | #link https://review.opendev.org/c/openstack/election/+/1000976/ | 17:10 |
| gouthamr | in other news, i think candidacies are flowing in fine, do thank an election official too when you get a chance :) | 17:11 |
| gouthamr | nominations close Aug 19, 2026 23:45 UTC | 17:12 |
| gouthamr | is there anything else wrt the elections? | 17:12 |
| opendevreview | Merged openstack/election master: Add Yasufumi Ogawa candidancy for Tacker 2027.1 https://review.opendev.org/c/openstack/election/+/1001286 | 17:13 |
| gouthamr | alright, next action item | 17:13 |
| gouthamr | https://github.com/openstack/cursive now resolves! but, i assume mirroring hasn't taken effect yet? | 17:14 |
| fungi | yes i think it's just waiting for another commit or tag to trigger a refresh | 17:14 |
| fungi | the maintain-github-mirrors job has been succeeding since ~friday finally | 17:14 |
| gouthamr | great, thank you fungi | 17:14 |
| fungi | happy to help, sorry it was broken for 8+months | 17:15 |
| gouthamr | at the tail end of last week's meeting, we discussed CI issues and flagged pre-commit trying to fetch packages from pypi even when they were made available locally by zuul | 17:16 |
| gouthamr | sean-k-mooney did some work on this with cyborg, watcher and i copied the approach to manila repos... think we can use this pattern across, and hopefully flaky CI would spur some of this... do we need to do anything else? | 17:17 |
| fungi | it wasn't trying to fetch packages from pypi (that would have been fine), it was downloading git repositories over the internet | 17:18 |
| gouthamr | ^ oh yes | 17:18 |
| clarkb | from opendev or github | 17:18 |
| clarkb | github had a big outage yesterday which may have created more related errors | 17:18 |
| gouthamr | +1 | 17:18 |
| sean-k-mooney | fungi: so almost all the hook we use use packages on pipi | 17:19 |
| sean-k-mooney | so the soltion i added to watcher was to make them local hooks that jsut use pip to install the cli and invoke it | 17:19 |
| sean-k-mooney | that end up removign the git clone | 17:19 |
| fungi | in particular though, the main offender was precommit cloning openstack/hacking just to get the plugin file from it | 17:20 |
| sean-k-mooney | and useing our pip mirrors | 17:20 |
| sean-k-mooney | yep moving just that hook to a local one is quite simple | 17:20 |
| sean-k-mooney | and proably shoudl be copy pasted to the relevnet repos | 17:20 |
| sean-k-mooney | if anyone hwas issue with that specificly in there jobs | 17:21 |
| sean-k-mooney | https://github.com/openstack/watcher/blob/master/.pre-commit-config.yaml#L110-L119 | 17:21 |
| sean-k-mooney | they can repalce there current hacking hook with that | 17:21 |
| gouthamr | great, ty | 17:22 |
| gouthamr | noonedeadpunk: welcome back! when you were gone, we discussed that vitrage still needs a PTL.. would you nominate yourself? | 17:22 |
| noonedeadpunk | oh, yes, because it's deprecated | 17:22 |
| noonedeadpunk | will post a patch for that | 17:23 |
| gouthamr | thank you.. | 17:23 |
| noonedeadpunk | I somehow didn't acknoledge that it's the ptl required | 17:23 |
| gouthamr | me neither, i took venus off the list last week | 17:23 |
| noonedeadpunk | yeah, I thought it was an accident with late deprecation or smth... | 17:24 |
| gouthamr | nah, we pre-create election directories asap.. so we'd need to make adjustment when something changes in governance (retirements, dpl->ptl transitions) | 17:25 |
| gouthamr | alright, last thing on the action items is this one: | 17:26 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/996925 (Define testing runtime for 2027.1 release) | 17:26 |
| gouthamr | it has enough +1s, any objections with me merging it? | 17:26 |
| fungi | yes please, the release team had that and corresponding job templates on its list of reminders for the tc last week | 17:27 |
| gouthamr | ty for that | 17:27 |
| cardoe | merge it | 17:27 |
| gouthamr | ack | 17:27 |
| gouthamr | that's a wrap on action items for the week, was anyone working on anything else to note? | 17:27 |
| fungi | the sooner we have the job templates for indri too, the better | 17:28 |
| fungi | libs are gong to start branching soon | 17:28 |
| fungi | er, going to | 17:28 |
| gouthamr | +1 | 17:29 |
| gouthamr | can someone from the release team ack this: https://review.opendev.org/c/openstack/governance/+/1001024 | 17:29 |
| cardoe | gouthamr: there's a couple more items on the wiki | 17:29 |
| gouthamr | action items? | 17:29 |
| gouthamr | oh, new topics! | 17:30 |
| fungi | i don't mind +1'ing 1001024 but curious why the release team is a blocker on it | 17:30 |
| gouthamr | fungi: not a blocker, but, i'd like you to check for us in-case you see something we don't | 17:31 |
| fungi | i don't think the release team cares if release liaisons change their e-mail addresses | 17:31 |
| fungi | though the person proposing the address change is not the person being changed | 17:31 |
| gouthamr | yeah | 17:31 |
| fungi | is that normal? | 17:31 |
| mnasiadka | Well, shouldn’t we at least need an ack of the person that his email is being changed? | 17:31 |
| fungi | looks like they did +1 it | 17:32 |
| gouthamr | not really normal, no.. which is why i'm uncomfortable single-person approving it despite our new house rules | 17:32 |
| gouthamr | but, the email address was changed on gerrit too afaict, all of their old changes are reflecting with the new email | 17:33 |
| gouthamr | so maybe everything's fine | 17:33 |
| opendevreview | Bartosz Bezak proposed openstack/election master: Add Bartosz Bezak candidacy for 2027.1 TC https://review.opendev.org/c/openstack/election/+/1001391 | 17:33 |
| gouthamr | cardoe: ty for seeding these new topics.. they're bit too late though.. a >~24-hour heads up would bring more people in | 17:35 |
| cardoe | Just looking to start the convo. | 17:35 |
| cardoe | One week wasn't going to cut it for them anyway. | 17:35 |
| gouthamr | ack, thank you - will check in on the gate and get to those shortly.. we can treat them as open discussion today and add them as topics for next week | 17:36 |
| gouthamr | #topic A check on gate health | 17:36 |
| mnasiadka | Ah, I didn’t notice the person doing +1 is the person which email is being changed (seemed like a different first name, whatever) | 17:36 |
| opendevreview | Merged openstack/governance master: Define testing runtime for 2027.1 release https://review.opendev.org/c/openstack/governance/+/996925 | 17:36 |
| gouthamr | anything to note about the gate this week? | 17:37 |
| fungi | nothing critical. there was some confusion around a broken pbr release at the end of last week | 17:37 |
| fungi | no actual releases were approved while the broken pbr 7.1.0 was available on pypi, i yanked it within 4 hours, though there were some broken branch tarballs for a handful of projects | 17:38 |
| gouthamr | ++ | 17:38 |
| gouthamr | alright, let's move to Open Discussion and introduce the topics cardoe added | 17:40 |
| gouthamr | #topic Open Discussion | 17:40 |
| gouthamr | cardoe: the floor is yours | 17:40 |
| cardoe | So in light of us surveying different groups of people about their involvement and usage of OpenStack, one thing is clear to me. We present to the world a unified concept of OpenStack but then each project sets a lot of its own rules. | 17:42 |
| cardoe | The TC sets a ground floor of those project rules but we leave a lot up to individual projects. | 17:42 |
| mnasiadka | fungi: kolla already is building from zuul cached repos (using required-projects) - so hopefully that’s going to fix it (but we still use tarballs.opendev.org for end users, which I’m working on changing) | 17:42 |
| cardoe | One of the take aways I had from the surveys and our efforts here to meet weekly and openly is that we are trying to foster a community around the various projects that make up OpenStack. | 17:43 |
| cardoe | And as someone smarter than me has said, if we don't actually have a community then we don't have a project but just a git repo. | 17:44 |
| cardoe | So to that effect, I'd like to over the coming months talk about some of these ground floors for projects around fostering the community aspect. | 17:44 |
| cardoe | First one I've thrown out there is how do people progress within the project. How do they move from contributor to maintainer to core. | 17:45 |
| cardoe | We're already actively talking about how do we define that for electorate definitions. | 17:45 |
| cardoe | But let's include how to become someone with commit permissions as well. | 17:46 |
| cardoe | So I'm not saying the TC sets the rules on how to become a core but each project needs to include that information in their docs. | 17:46 |
| cardoe | So that's the first proposed item and I'm happy to stop there to discuss. | 17:47 |
| gouthamr | that's an interesting idea indeed, and the view you expressed about what the TC does stops here: | 17:47 |
| gouthamr | #link https://docs.openstack.org/project-team-guide/ptl.html#core-member-maintenance | 17:47 |
| gouthamr | and looking at nova, they have this: | 17:48 |
| gouthamr | #link https://docs.openstack.org/nova/latest/contributor/how-to-get-involved.html#how-do-i-become-nova-core | 17:48 |
| cardoe | That's not a clear set of steps to become a Core however. | 17:49 |
| cardoe | In either case. | 17:49 |
| cardoe | I'll use Nova as an example as well. | 17:49 |
| gouthamr | nova is one of several teams that runs an informal mentoring program where you're paired with an existing core reviewer to ramp up on the team's conventions, expectations | 17:49 |
| cardoe | The PTL in this case is not a Core. Has asked to become a Core and did not become a Core. | 17:49 |
| cardoe | How does he become a Core? | 17:50 |
| noonedeadpunk | I'd assume majority of existing core team must vote positively on it | 17:50 |
| fungi | to be clear, the ptl has the authority to make themselves a core reviewer and even revoke all the other core reviewer statuses. if he doesn't exercise that right then it's because of social pressures like not wanting to alienate the rest of that team | 17:50 |
| dansmith | surely you don't think that there should be a set of step to become a core and if you tick the boxes, you're magically a core right? | 17:50 |
| cardoe | noonedeadpunk: I agree a vote makes absolute sense. So let's write that down that a vote happens. Does the vote happen in secret? | 17:51 |
| JayF | dansmith: I think it's more that there's not a clear path to make core in many projects, and no mile-markers along the way to indicate to your managers that you are doing good work and making progress with it. | 17:51 |
| noonedeadpunk | but eventually yes, the PTL is having the last world to solve who's becoming a core and who's not. | 17:51 |
| fungi | but strictly speaking from a governance perspective, how and who becomes a core reviewer is the ptl's decision as delegated form the tc, the ptl in this case subdelegates that to others | 17:51 |
| JayF | dansmith: I can't speak for if cardoe thinks there should be a checklist like that, but it's apparent that it's hard to ask people to make that kinda commitment without a strong sense of what they are working towards (and some assurance they can achieve it) | 17:52 |
| dansmith | I mean, I just want to make sure we're not advertising that anyone/everyone should be a core and that you can tell your manager "I'm going to complete these steps and become core on $project" | 17:52 |
| noonedeadpunk | cardoe: so what we used to practice in osa previously, when we had more active ppl working on it, is replies in ML was counting as voting. So it was not anonymus | 17:52 |
| TheJulia | And even if there is a process and mile markers, the question then does eventually become "is it a path which is actively being managed/worked/evolved", which is currently a question for a project team, and some have as we have seen updated expectations and approaches. | 17:52 |
| noonedeadpunk | Which might make sense, as candidate might want to reach out for guidance and to get a feedback | 17:52 |
| noonedeadpunk | I'd love for this process to be as much transparent as possible, to manage expectations on both sides | 17:53 |
| cardoe | Exactly what JayF said. If we're asking companies to donate the time of their employees to OpenStack projects then there must be some way for those employee's managers to evaluate their performance in that contribution. If a manager can give someone a goal of becoming a community member of some stature then that would help. | 17:53 |
| JayF | (to be clear; I don't think Ironic does a good job of this either. We added the idea of a separate -reviewers group as a patch, but all new cores still generally followed a path of being mentored by a more experienced core) | 17:53 |
| TheJulia | cardoe: yeah, in a business sense, they have to be able to see there is a way to make an ROI on the employee's engagement. | 17:54 |
| dansmith | I mean, I really really think we should not be endorsing any sort of system where you have to be a core to get your ROI on contributing to the community... | 17:55 |
| fungi | the term "perverse incentive" comes to mind | 17:55 |
| dansmith | for Nova at least, it's basically all "do the other cores trust you to +2 things that should be _and_ (probably more importantly) shoot down the things that should not merged" | 17:56 |
| cardoe | I don't think there's a check list with a series of checkboxes to become a core fwiw. What I do think is that there should be something written down... For example "An existing core mentors a candidate and then when the candidate or the mentor thinks they are ready they should propose to the other cores this person then the cores all vote and majority rules. The result of the vote is public." | 17:56 |
| cardoe | Or whatever that project decides. | 17:56 |
| cardoe | But it should be written down. | 17:56 |
| dansmith | we've always done that in private because we're literally talking about why we think someone isn't there yet.. communicate it to the person, but FFS don't make that be on the mailing list | 17:57 |
| JayF | dansmith: one thing that we put into the calculation for ironic is the change of "Do we trust this person to know WHEN they can act as a core or not?" (e.g. to trust them to stay within their own knowledge bases) -- I think from a philosophical standpoint, this is a significant difference in "how high the bar is" | 17:57 |
| JayF | cardoe: in practice, we do it in ironic in private too -- we have the mail thread to existing cores where we propose folks, and only put them up for public vote when we know they will pass | 17:57 |
| dansmith | this ^ | 17:58 |
| gouthamr | i think that's social practice in all the teams | 17:58 |
| JayF | cardoe: we do that to protect the feelings of folks under evaluation, but realistically it comes with a transparency cost | 17:58 |
| cardoe | Sure. Private is fine. | 17:58 |
| gouthamr | praise and grow consensus publicly, criticize in private.. | 17:58 |
| dansmith | definitely | 17:58 |
| mnasiadka | I think Kubernetes had nice definition of some entry bar criteria somewhere… | 17:58 |
| cardoe | But let's just ask the projects to write down those steps. | 17:58 |
| mnasiadka | #link https://github.com/kubernetes/community/blob/main/community-membership.md | 17:58 |
| cardoe | mnasiadka: ah you jumped into my second topic :) | 17:58 |
| dansmith | so "If all goes well, and you seem like a good candidate, your mentor will contact the rest of the nova-core team to ask them to start looking at your reviews, so they are able to vote for you, if you get nominated for join nova-core." | 17:59 |
| TheJulia | cardoe: its a small, concrete, trust and transparency building step. Entirely reasonable in my opinion. | 17:59 |
| dansmith | I mean, I feel like that's what you're asking for (from the nova guidelines) | 17:59 |
| cardoe | dansmith: While we've been having fun using Nova as the example here, I'm focused on all OpenStack projects. | 17:59 |
| dansmith | cardoe: going based on: <cardoe> I'll use Nova as an example as well. | 18:00 |
| cardoe | Just cause Nova does one thing or another doesn't dismiss the conversation with regards to other projects under the OpenStack umbrella. | 18:00 |
| gouthamr | agreed | 18:01 |
| gouthamr | alright, could we dwell on these thoughts and reprise this discussion next week? | 18:01 |
| cardoe | Yep. | 18:01 |
| dansmith | for sure, I just thought you were using Nova as the example of where it's not well-documented, but ... cool, agree the others should do the same | 18:01 |
| gouthamr | thanks for bringing this up cardoe | 18:01 |
| JayF | cardoe: One thing that might be an interesting perspective on this issue would be some data. I wonder about quantity of core teams over time, as well as age-of-membership (e.g. Do we have projects with majority of cores at 5-10+ years? Do we have projects with majority of cores being new to the community? Do we have teams that are doing a better job sustaining numbers than others? | 18:01 |
| JayF | cardoe: taking this outta the realm of qualitative and into quanitative might help identify issues across the different projects | 18:02 |
| noonedeadpunk | tbh, company PKI on person on becoming a core is slightly.... unreasonable if you ask me... | 18:02 |
| cardoe | JayF: yeah good points. | 18:02 |
| JayF | cardoe: b/c I agree we need an openstack-sized approach, but I think the diagnosis across the different projects will be vastly different | 18:02 |
| cardoe | noonedeadpunk: absolutely agreed. | 18:02 |
| noonedeadpunk | First - it's not really motivating individual to perform well, just tick the box | 18:02 |
| TheJulia | JayF: that was something which did pop into my mind when reading the open discussion items, so definitely a worthwhile callout. | 18:02 |
| mnasiadka | noonedeadpunk: I worked in such a company, don’t get me started ;-) only about a year, but still :) | 18:02 |
| noonedeadpunk | second, it's not really depending on individual either | 18:03 |
| noonedeadpunk | mnasiadka: I was trying to fight this at some point as well | 18:03 |
| gouthamr | it feels like some of this can use a long-form discussion on the openstack-discuss ML.. if you'd like to make some strawman proposals, please do, cardoe | 18:03 |
| gouthamr | (and others) | 18:03 |
| noonedeadpunk | and then they also set a deadling to individual to become a core... | 18:03 |
| noonedeadpunk | so the goal of org is kinda clear, but eh... | 18:04 |
| cardoe | noonedeadpunk: but I have given some of my employees PKIs on being active reviewers in the projects they're assigned to be involved in ;) | 18:04 |
| gouthamr | alright, we're a bit over.. does anyone have anything else to note for the minutes today? | 18:04 |
| noonedeadpunk | cardoe: that is a good one indeed | 18:04 |
| gouthamr | going once.. | 18:04 |
| JayF | noonedeadpunk: I think we are *all* aligned in that we don't want our downstream benefactors keying behavior on "if you are core or not", but it's also not unreasonable for companies that invest a some % of an FTE to want to have a feeling that they have a voice in the project | 18:04 |
| cardoe | noonedeadpunk: and some of our recently changes with the electorate scripts will help me gather that data. | 18:04 |
| JayF | noonedeadpunk: so there's a balance there somewhere | 18:05 |
| gouthamr | going twice.. | 18:05 |
| noonedeadpunk | JayF: oh, sure, but I am not sure it can be really formalized, I think it will end up in "common sense" grounds anyway | 18:05 |
| gouthamr | alright, sorry for being a nag about the meeting time, we're 5 mins over and this is surely a hot topic that we'll reprise next week | 18:05 |
| gouthamr | please keep the chatter going | 18:05 |
| gouthamr | thank you all for attending | 18:06 |
| gouthamr | #endmeeting | 18:06 |
| opendevmeet | Meeting ended Tue Aug 18 18:06:08 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:06 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2026/tc.2026-08-18-17.00.html | 18:06 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2026/tc.2026-08-18-17.00.txt | 18:06 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2026/tc.2026-08-18-17.00.log.html | 18:06 |
| JayF | noonedeadpunk: yeah that's why I want metrics/statistics | 18:06 |
| dansmith | JayF: I don't think that's reasonable at all.. | 18:06 |
| dansmith | JayF: if I put forward my least community-aware person and push them to be core, and I have some expectation that they will scale some ladder and do it? no way... | 18:06 |
| dansmith | if there is some expectation that I can't just show up with any warm body an put them through the process to achieve some goal, suddenly if I want to have a voice in the project, I have to choose wisely.. pick/hire someone with some awareness, some community experience | 18:07 |
| mnasiadka | JayF: you usually can have a voice in the project without being a core, and exercising that voice plus rolling up your sleeves (on a semi-regular basis) gives you core | 18:08 |
| JayF | I think "any warm body" is doing a lot of work there: my comment is made under the assumption that there is engagement in good faith with qualified individuals. | 18:08 |
| cardoe | So I'll give you an example... Someone that I've got hired at a very senior level and tasked with being our SME on $PROJECT... I would expect after 18 months time that $PROJECT would for example value their review contributions... maybe even value their attendance at PTG sessions. | 18:08 |
| noonedeadpunk | the problem with the last part, is that this approach does cannibalize community, but does not grow it | 18:08 |
| noonedeadpunk | And I think we need to grow and bring in new faces, esp given then tons of old ones have left it | 18:08 |
| JayF | cardoe: and if not, I want to trust the project's documented processes and feedback enough to know that the person/approach was the problem, not the community | 18:09 |
| cardoe | Exactly ^ | 18:09 |
| JayF | I also think the difference between a community-minded developer and a non-community-minded developer might be if they were shoved into a community early on to help them learn that community-mindedness | 18:09 |
| dansmith | JayF: how is "the core team voted three times and still doesn't think that person is worthy" not that indication? I mean, you could ask for that to be public I guess, but if it's being communicated to the person... | 18:09 |
| noonedeadpunk | I kind of wonder how you are evaluating reviews though? | 18:09 |
| noonedeadpunk | what kind of stats would show up quality of reviews? | 18:10 |
| noonedeadpunk | as that is extremely subjective thing... especially at AI age | 18:10 |
| JayF | noonedeadpunk: this is the hard part and the part (nod to cardoe) that I think we could document better at a project level | 18:10 |
| JayF | Ok, my wife is waiting for me to go grab a sandwich; going to head to lunch o/ | 18:11 |
| cardoe | mnasiadka touched on the next topic I had which was around formalizing different levels of contributors... like JayF mentioned that ironic has the -reviewers separate from -core. I'm not saying that each project has to adopt the levels. But providing a definition in the project team guide. | 18:12 |
| noonedeadpunk | I am just a bit scpetical that it can be reasonablly formalized for the goal and to convinced C level managers to be enough to put in money/effort | 18:13 |
| cardoe | gouthamr: I do think "how to become a core member" doesn't belong on the PTL page either. | 18:13 |
| noonedeadpunk | but dunno | 18:13 |
| fungi | from what i saw, the nova team has several proposals under discussion for how to more effectively grow their core reviewer team | 18:13 |
| fungi | (the separate reviewers category/label was one of the options they were discussion) | 18:14 |
| fungi | discussing | 18:14 |
| dansmith | noonedeadpunk: agree | 18:14 |
| cardoe | The goal here is to increase the engagement and the community sense. | 18:17 |
| cardoe | If someone has a desire to be a committer on a project they know they need to get a mentor and get votes | 18:17 |
| cardoe | Like mnasiadka pointed out. Many open source projects are documenting levels of contributor status. | 18:18 |
| cardoe | They're documenting ways to on ramp onto that. | 18:18 |
| cardoe | I'm suggesting the TC require the projects under the umbrella start doing the same. | 18:18 |
| opendevreview | Tim Burke proposed openstack/election master: Tim Burke candidacy for Swift PTL (Indri) https://review.opendev.org/c/openstack/election/+/1001400 | 18:37 |
| opendevreview | Merged openstack/governance master: Update details for trove release/security liaison - new email address https://review.opendev.org/c/openstack/governance/+/1001024 | 20:15 |
| gmaan | interesting topic that i missed today. just to add my opinion: I think TC should/continue let projects team to decide what is exact criteria to become core and that of course cannot a checklist (WHICH CAN BE EASILY CLICKED IN AI ERA :P ). Asking projects to document some path/guidelines/recommendations are fine but please do not force any decision or make pressure to any team to make members core. | 21:51 |
| gmaan | OpenStack governance model itself is based on "let project team handle the tech and project related governing things" | 21:52 |
| fungi | yeah, i don't think the proposition was to standardize it, just to standardize the practice of transparently documenting it | 21:54 |
| gmaan | ++ | 21:55 |
| gmaan | now or later the key issue we have to accept is that we will be seeing more slowness in merging the things and reasons are multiple. | 21:56 |
| gmaan | and IMO, "making more core" is not the correct solution for that | 21:57 |
| gmaan | i mean having more core is good but just thinking that *adding more core fast* will not resolve the problem, instead will create more | 21:59 |
| fungi | for the purposes of sustainability, we do need to onboard new maintainers who can fill gaps left by departing maintainers, at the very least | 22:00 |
| clarkb | I think it can go both ways. within the infra team (I don't think it was opendev yet) we added new cores/roots with the idea being that we trusted them to ask questions and only proceed with things they felt confident in. This meant that the scope of what they started with was small and for everything else other admins had to spend more time bringing people up to speed. But | 22:01 |
| clarkb | after that initial investment period we had a couple of new cores/admins that were quite capable and things were great. Then things were sad again when they quickly moved onto other new things with their leveled up skills | 22:01 |
| fungi | i agree that the answer to rising change proposal counts is not merely adding more people to review/approve them, the latter doesn't scale linearly relative to the former | 22:01 |
| clarkb | so yes adding new people is an investment that takes time from other efforts. But if you can turn that into capable help you start to see dividends. Its just nice if the return period is longer than a few months too | 22:02 |
| fungi | it's like the old engineering joke that it takes 9 months to produce a child no matter how many engineering hours you invest | 22:02 |
| fungi | not everything scales the same | 22:03 |
| gouthamr | "this is why we can't have nice things" eh :) | 22:03 |
| opendevreview | Goutham Pacha Ravi proposed openstack/governance master: Add liaison-update hashtag with PTL/liaison CR+1 check https://review.opendev.org/c/openstack/governance/+/1001440 | 22:27 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!