| opendevreview | Merged openstack/election master: Tim Burke candidacy for Swift PTL (Indri) https://review.opendev.org/c/openstack/election/+/1001400 | 07:12 |
|---|---|---|
| opendevreview | Merged openstack/election master: Add Bartosz Bezak candidacy for 2027.1 TC https://review.opendev.org/c/openstack/election/+/1001391 | 07:14 |
| opendevreview | Merged openstack/election master: Adding Felipe Reyes candidacy for OpenStack_Charms 2027.1 https://review.opendev.org/c/openstack/election/+/1001386 | 07:14 |
| opendevreview | Merged openstack/election master: Add Takashi Kajinami candidacy for Puppet OpenStack https://review.opendev.org/c/openstack/election/+/1001345 | 07:14 |
| opendevreview | Merged openstack/election master: Adding René Ribaud candidacy for Nova 2027.1 PTL https://review.opendev.org/c/openstack/election/+/1001347 | 07:23 |
| opendevreview | Merged openstack/election master: Adding Mauricio Harley candidacy for Barbican https://review.opendev.org/c/openstack/election/+/1001338 | 07:23 |
| opendevreview | Merged openstack/election master: Add Carlos da Silva candidacy for Manila PTL https://review.opendev.org/c/openstack/election/+/1001357 | 07:23 |
| opendevreview | Merged openstack/election master: Refactor contributor recording into a new function https://review.opendev.org/c/openstack/election/+/1000991 | 07:23 |
| opendevreview | Merged openstack/election master: Reformat lines in record_contributor function https://review.opendev.org/c/openstack/election/+/1000992 | 07:32 |
| cardoe | gmaan: So to be clear my proposal is to just require projects to publish a clear set of procedures to become core. I would also like to have a set of procedures to evaluate if someone is no longer active enough to remain a core. I don’t want the TC to set anything past that. So it’s still leaving projects in control. | 11:27 |
| cardoe | gmaan: so nova was first provided to me as an example but I’ll continue is the fact that nova keeps saying they don’t have the bandwidth to review or look at contributions. I’m asked to attend the PTGs and bring up ironic driver related topics. Heck I was asked to attend the weekly nova meetings to bring up nova/ironic integration items but they never got reviews. And I’m told that there is no core with knowledge of the | 11:30 |
| cardoe | ironic driver. So something is broken here. | 11:30 |
| cardoe | That being said. I’m also a little bit tired of nova being the focus point. A bunch of proposals are brought up here and it’s always immediately “well we don’t need this cause nova…” | 11:31 |
| cardoe | My proposal is for all of OpenStack projects. When you were TC chair gmaan we had multiple projects where the TC contemplated adding people to projects because there was no clear documented pathway for people to become core and the existing cores didn’t reply. That’s a problem. That project should had a visible way for the TC to see it was unhealthy and didn’t have any cores long before then. | 11:34 |
| frickler | IMO the core problem is trust. a potential new core should be trusted by the existing cores. I have no idea how "a clear set of procedures" to earn trust could look like. this probably was much easier when people used to meet in person twice a year, maybe there isn't actually a workaround for that, especially when all other interactions can no longer be trusted not to be fake nowadays | 12:07 |
| spotz[m] | I know back when I became core for OSA it was about trust, doing reviews, patches, answering questions, and even running meetings. Core candidates were brought up on the dev list and then if no objections added. For other repos like docs I think it was more of a TC appointment at that point. | 12:14 |
| frickler | that's a good list of tasks for someone who wants to join a team, I agree, but I still cannot see that one could give anyone the instruction "do these tasks and you'll get promoted to core in N months". and much less I think we can agree on such a list if we cannot even agree which communication channel an OpenStack project should use | 12:20 |
| spotz[m] | Yeah it's still about trust, will they show up, can they review without bias, etc | 12:21 |
| opendevreview | Hemanth N proposed openstack/election master: Adding Hemanth Nakkina candidacy for OpenStack Sunbeam https://review.opendev.org/c/openstack/election/+/1001484 | 12:21 |
| cardoe | frickler: again not wanting a checklist of "do this and you will be a core" | 13:11 |
| cardoe | Maybe a project has a process to formally have a mentor work with a candidate for a while before voting on them. Call out the mentoring process. | 13:12 |
| cardoe | If there are hard barriers to achieving that then be transparent. | 13:14 |
| frickler | cardoe: then "my proposal is to just require projects to publish a clear set of procedures to become core" has a different interpretation for me than for you | 13:14 |
| cardoe | A clear set of procedures would be "We required candidates to have a mentor of a current core member. That mentor can submit them forward when they feel they are ready for the other cores to vote on. If 50% of the cores vote in favor than that person is accepted." | 13:15 |
| frickler | ok, that might work. if you are able to find enough mentoring capacity | 13:17 |
| cardoe | I'm not saying that's the rule. | 13:19 |
| cardoe | It's up to every project to decide what they want. | 13:19 |
| cardoe | Just publish something. | 13:19 |
| TheJulia | Something is a start, but looking at a chat the highlighted issue is also trust. I concur that is a base issue, and the TC should be willing to take a stand to set expectations that it requires active participation to build trust. The obviously related aspect is good over perfection and extending a little trust to the submitter of a change. Each project's culture is different, but the key thing is to accept we're all human, we're all | 13:43 |
| TheJulia | going to make mistakes at some point and that is more an opportunity to learn and evolve than anything else. | 13:43 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/election master: Add nomitation for Vitrage https://review.opendev.org/c/openstack/election/+/1001514 | 14:25 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/election master: Add nomination for OSA https://review.opendev.org/c/openstack/election/+/1001515 | 14:28 |
| opendevreview | Wu Wenxiang proposed openstack/election master: Adding Wu Wenxiang candidacy for Skyline 2027.1 PTL https://review.opendev.org/c/openstack/election/+/1001530 | 15:11 |
| opendevreview | Merged openstack/election master: Adding Hemanth Nakkina candidacy for OpenStack Sunbeam https://review.opendev.org/c/openstack/election/+/1001484 | 16:36 |
| opendevreview | Merged openstack/election master: Add nomitation for Vitrage https://review.opendev.org/c/openstack/election/+/1001514 | 16:36 |
| opendevreview | Merged openstack/election master: Add nomination for OSA https://review.opendev.org/c/openstack/election/+/1001515 | 16:37 |
| opendevreview | Jeremy Stanley proposed openstack/election master: Add internal toggle to skip change incrementing https://review.opendev.org/c/openstack/election/+/1001555 | 17:53 |
| opendevreview | Jeremy Stanley proposed openstack/election master: Active core reviewers are also Active Contributors https://review.opendev.org/c/openstack/election/+/1001560 | 19:01 |
| opendevreview | Jeremy Stanley proposed openstack/election master: Add internal toggle to skip change incrementing https://review.opendev.org/c/openstack/election/+/1001555 | 19:42 |
| gmaan | cardoe: yeah, we can have some clear doc or guidelines but i do not think problem is "we do not know how to become core". I think everyone knows how to become, do more review and quality review. But parameter is again trust which is very hard to quantify. anyways I am not against of starting something if that can help but my only concern is not to force anything on projects which can impact their way of working | 19:49 |
| gmaan | on nova changes merging late of not merging due to less expertise on a particular area. I think having more core will not solve it instead we need some solution to have those SME in nova team. though we are discussing a few options to solve it so let's see how it goes. | 19:51 |
| cardoe | gmaan: so it's not just how to become but also does this project evaluate whether core membership remains valid for individuals? | 19:52 |
| cardoe | There's folks we've got as core's for projects that no longer have OpenStack involvement and have stated that they won't. | 19:52 |
| gmaan | but this is not just nova, I have a recent and very unreleased experience on RBAC goal. I asked projects to do xys things as it will break, nobody did, i proposed the fixes (as per my bandwidth/assigmenyts i am not supposed to), asked for review, reviews did not happen from many projects | 19:52 |
| cardoe | These kind of accounting items help the TC understand if a project is healthy or not. | 19:53 |
| cardoe | If a project has a policy of evaluating their core membership on some schedule then the TC can have a higher level of trust that the project's core's are active and the project is healthy. | 19:54 |
| gmaan | after pinging projects in IRC, meeting, ML, i had very hard time to get the reviews on changes which fix the RBAC for them. still many projects reviews are pending https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status:open%20OR%20status:merged) | 19:54 |
| gmaan | I am not sure we can say cinder is not healthy as they took months to review RBAC fixes proposed by me or even they are still pending | 19:54 |
| cardoe | If the project never evaluates the core membership then the TC will have less confidence that core membership implies a project with active core members. | 19:54 |
| gmaan | and not sure if as we add more core in cinder can solve this issue | 19:55 |
| cardoe | You're doing the same thing that others are doing and thinking what I'm trying to do is stuff more core's into projects. | 19:55 |
| gmaan | its a existing issue since many years, I remember mnaser bringing it a lot in past. i brought up a very less but faced maximum time | 19:56 |
| cardoe | I'm trying to help the TC have another tool in the belt to understand if the project is healthy or not. | 19:56 |
| gmaan | that is good. I am thinking if we can have some matrix to relfect the 'incoming requests/work (review/bug etc)' vs 'available core bandwidth' and then flag it to higher level organizations/foundation memebrs level. or at least it will reflect reality that things will take time to merge in this proejct because of know issue | 19:58 |
| cardoe | So I think those kind of metrics would be great. I'm just not sure how to capture them. | 20:05 |
| gmaan | ditto | 20:06 |
| gmaan | cardoe: one thing such doc can help is to highlights if any project has any unrealistic or wrong or personal expectation than what it should be from open source and project perspective | 20:06 |
| cardoe | gmaan: another one that I haven't gotten to yet is like mnasiadka mentioned that CNCF recommends to their projects a tiered membership approach... not necessarily recommended I guess but a reference model and that's what kubernetes uses. | 20:06 |
| cardoe | I know a handful of projects under OpenStack have adopted one or are looking at it. | 20:07 |
| cardoe | So I was going to suggest we find a common model between them and include it as a reference model as well. | 20:07 |
| gmaan | sure but honestly saying it might will not solve the problem we have or solve it completely but having a ref model is not a bad idea | 20:08 |
| cardoe | The last one that I haven't mentioned at all here yet is around SMEs. | 20:09 |
| cardoe | But a project might say oh well all of our cores / reviewers should have an equal knowledge of the code base potentially | 20:10 |
| cardoe | But another project might have different backend drivers for example and they might say oh well we do have SMEs and everyone should know the API but then there's a SME per backend. | 20:10 |
| cardoe | A lot do this informally on the wiki for example. But the names on there are grossly out of date. | 20:11 |
| cardoe | It's along the lines of the TC declaring security liaisons and release liaisons for projects recently. | 20:12 |
| cardoe | Maybe we should more formally capture those SMEs and do a better job to keep that list up to date. | 20:12 |
| gmaan | yeah, I am not sure if anyone ref those cross area/projects liaison as they are outdated | 20:12 |
| cardoe | Then we'll have a better idea when areas are uncovered. | 20:12 |
| cardoe | I was roughly thinking that each PTL cycle, just after the election we ask the project to ACK that the list is up to date or make a change? | 20:13 |
| gmaan | that is hard part. we have failed to get PTL engagements in such things, more than 50% PTLs do not even respond :) | 20:14 |
| cardoe | That might serve the project two ways... folks will know their changes in those areas will be slower going but then also that might spur the project to recruit someone or spur someone to step up? | 20:15 |
| gmaan | but anyways, i will not discourage you to try the things even we did not get much success in past. | 20:17 |
| cardoe | Now I hope what I've said above isn't controversial so now I'll say my controversial piece. | 20:18 |
| cardoe | A project that is growing in valid potential contributors but is unwilling to accept those contributors by not being willing to grow their reviewer base is a project that is not interested in building an OpenStack community project and is just a project that's here for git hosting and zuul CPU cycles. | 20:19 |
| TheJulia | just kind of skimming the chatter, and one thing you noted gmann is saying it might not help, but really it requires active participation and leadership guidance to both identify problems and work to fix them. Even as you've noted, a lack of PTL response is another symptom of similar (yet differ shaped problems) | 20:20 |
| cardoe | Yeah I didn't call that out but PTL's not responding to the TC is another category of problem. | 20:22 |
| TheJulia | cardoe: I don't think so, but some people can always interpret things differently, I think what your trying to get at is how does the TC have the tools to really chart direction | 20:22 |
| TheJulia | Its a similar problem, engagement. Engagement with governance is differently shaped than engagement with active community building | 20:23 |
| TheJulia | The last thing I'd hope to see is "oh, its too hard!" | 20:24 |
| TheJulia | I think a little earlier, there was a note of metrics. That has been something the TC has been struggling with for years, but maybe the time to identify metrics and the trends over time to create a holistic picture | 20:28 |
| opendevreview | Jeremy Stanley proposed openstack/election master: Active core reviewers are also Active Contributors https://review.opendev.org/c/openstack/election/+/1001560 | 20:39 |
| opendevreview | Jeremy Stanley proposed openstack/election master: Pass email explicitly to record_contributor https://review.opendev.org/c/openstack/election/+/1001565 | 20:39 |
| opendevreview | Ghanshyam Maan proposed openstack/election master: Add Ghanshyam candidacy for QA PTL https://review.opendev.org/c/openstack/election/+/1001574 | 21:11 |
| opendevreview | Jeremy Stanley proposed openstack/election master: Add internal toggle to skip change incrementing https://review.opendev.org/c/openstack/election/+/1001555 | 21:27 |
| opendevreview | Jeremy Stanley proposed openstack/election master: Pass details explicitly to record_contributor https://review.opendev.org/c/openstack/election/+/1001565 | 21:27 |
| opendevreview | Jeremy Stanley proposed openstack/election master: Active core reviewers are also Active Contributors https://review.opendev.org/c/openstack/election/+/1001560 | 21:27 |
| opendevreview | Clark Boylan proposed openstack/contributor-guide master: Add code review templates appendix https://review.opendev.org/c/openstack/contributor-guide/+/1001577 | 21:32 |
| opendevreview | Clark Boylan proposed openstack/contributor-guide master: Add code review templates appendix https://review.opendev.org/c/openstack/contributor-guide/+/1001577 | 21:40 |
| opendevreview | Clark Boylan proposed openstack/contributor-guide master: Add code review templates appendix https://review.opendev.org/c/openstack/contributor-guide/+/1001577 | 21:48 |
| gouthamr | ^ woah. good thoughts there clarkb.. | 21:50 |
| clarkb | ok cool I'm glad we don't hate it | 21:51 |
| gouthamr | shouldn't that be in "project-team-guide"? | 21:51 |
| clarkb | maybe? | 21:51 |
| clarkb | I think the idea I had was that it still had general contributor benefits even if targetted to a subset of contributor | 21:52 |
| gouthamr | don't want to make you do work.. can i assume this came about beause of the b-t-g surveys/findings? | 21:52 |
| clarkb | yes this is one of the ideas that came out of that work | 21:52 |
| gouthamr | yah no, we can cross link etc.. its just i don't know where to find what info after these 95 years of openstack :D | 21:52 |
| clarkb | specifically that communication is hard and we often struggle with it. | 21:53 |
| clarkb | it should be an easy transplant. I'm not doing anything special with sphinx or rst | 21:53 |
| gouthamr | +1 | 21:53 |
| clarkb | gouthamr: https://23747c8ea869a495f1ca-a232ce3bdc50fca913ceba9a1c600c62.ssl.cf2.rackcdn.com/openstack/1d0b41507d3d497394ec84755ab05e0d/docs/code-and-documentation/using-gerrit.html#reviewing-changes this section is why I thought it fit here | 21:54 |
| gouthamr | nice, i didn't know that existed.. ty for pointing out | 21:55 |
| gouthamr | like cardoe was noting, maybe some of that core-maintainer language is nested under the "PTL" documentation | 21:55 |
| opendevreview | Clark Boylan proposed openstack/contributor-guide master: Add code review templates appendix https://review.opendev.org/c/openstack/contributor-guide/+/1001577 | 21:55 |
| gouthamr | and was incorrect too, because who'd expect to find it there: https://docs.openstack.org/project-team-guide/ptl.html | 21:56 |
| clarkb | `doc/source/appendices/code-review-templates.rst:30: D000 Cannot analyze code. No Pygments lexer found for "none".` sometimes I think we go too far with all the linting | 21:59 |
| clarkb | I believe none is a valid rst code block type. It means don't highlight etc | 21:59 |
| clarkb | https://c0c3548b65f303ef6c0e-9dc5526a72bde5cc52e2c616e6a483fd.ssl.cf5.rackcdn.com/openstack/792b820179b54178b711f792a92f975d/docs/appendices/code-review-templates.html yes it works as expected here | 22:01 |
| fungi | yeah, i think the idea is that we have reviewer guidance suitable for the project team guide, and contributor guidance suitable for the contributor guide | 22:01 |
| fungi | divided up by audience | 22:02 |
| gouthamr | clarkb: https://github.com/PyCQA/doc8/issues/53 ".. code-block :: " should work apparently | 22:02 |
| gouthamr | fungi: yeah agreed.. | 22:03 |
| clarkb | gouthamr: that is what I did before using None and you get highligthing | 22:03 |
| fungi | but they probably should also cross-reference one another eventually for discoverability too | 22:04 |
| gouthamr | ".. highlight:: none"? | 22:04 |
| clarkb | gouthamr: I'm going to try :language: none as an option | 22:04 |
| clarkb | but if that doesn't work I'm just going to disable doc8 on this file. I don't think we should use unmaintained software | 22:05 |
| gouthamr | interesting problem, yeah not worth wasting time on :) | 22:06 |
| clarkb | oh actually `text` may be a valid value | 22:07 |
| cardoe | I'm late to the convo. | 22:08 |
| cardoe | I fought this recently too | 22:08 |
| opendevreview | Clark Boylan proposed openstack/contributor-guide master: Add code review templates appendix https://review.opendev.org/c/openstack/contributor-guide/+/1001577 | 22:08 |
| cardoe | It's text as you saidf | 22:08 |
| gouthamr | cardoe: i'm picking up subtopics for our weekly meeting next.. i think there's a perception problem that hurts contributors and maintainers when core teams are larger than they really are.. i wonder what all possibilities exist for our current state there | 22:08 |
| gouthamr | i for one was too nice to drop people that stepped away with no notice | 22:09 |
| clarkb | https://pygments.org/languages/ is a list of values pygments should accept | 22:09 |
| cardoe | gouthamr: well I think that was my third topic. Just some kind of check-in that asks the PTL every cycle to re-affirm. | 22:09 |
| gouthamr | i thought that was respectful, and maybe was hoping they'll come back.. but it took me forever to drop folks | 22:10 |
| cardoe | But it hurts the project as you said. | 22:10 |
| gouthamr | yeah | 22:10 |
| clarkb | are people going to the gerrit group and saying "you're lying there are actually 10 people here not 5" ? | 22:11 |
| clarkb | I guess I haven't experienced that and its pretty easy with a simple gerrit query to see what the actual acitviity levels are when things are near idle | 22:12 |
| cardoe | clarkb: it's more cause projects say they need SMEs to review some areas and then say Bob is the SME for that but Bob has been MIA for years. | 22:13 |
| clarkb | ah | 22:14 |
| gouthamr | as a new (or new-to-project) contributor, i don't even know Bob's the SME | 22:14 |
| gouthamr | and that the team is waiting on them | 22:14 |
| clarkb | gouthamr: ya one of the things my change above tries to get at is we need to be more explicit about telling people what the enxt step is | 22:14 |
| gouthamr | ++ | 22:14 |
| clarkb | if we're waiting on Bob then we should say that outloud in the change and make that clear | 22:14 |
| gouthamr | one day JayF said something about "security" around here that gave me another angle to this.. someone sitting on a core team, or a coresec team, or the VMT and not paying attention could hurt us beyond perceptions.. | 22:15 |
| JayF | clarkb: in practice, what happens is the patch sits with 0-1 reviews and the SMEs never show up. I try to comment on these when they happen in ironic-land, but I don't always get to them | 22:16 |
| clarkb | yup that particular reason for keeping things aligned with reality is the one I am more concerned about due to my day to day | 22:16 |
| JayF | clarkb: and sometimes I think it can come off as "yep, sucks to be you" instead of empathetic | 22:16 |
| clarkb | JayF: ya and maybe its ok to proceed without SME input if they aren't around anymore. And use that as the basic for building new SMEs | 22:17 |
| clarkb | I mean I get thrown at things I've never seen before on the daily :) you get good at figuring stuff out | 22:17 |
| gouthamr | ++ | 22:21 |
| gouthamr | (i made an adjustment to the TC topics for next week based on the chatter here so far, please feel free to continue the discussion here or on openstack-discuss) | 22:22 |
| clarkb | Speaking of: if anyone wants to learn about cummins automatic transfer switches for 150kw generators and why they don't have any parts for the one I already have I have an opportunity for you. But also its crazy to me that big generator parts are not kept on shelves and the hospital you visit may just fail to have electricity as a result | 22:23 |
| clarkb | I'm sure people who work in data centers can tell some real horror stories about this stuff | 22:23 |
| gouthamr | they have backups for those backups? | 22:25 |
| gouthamr | and after some layer of such backups, i presume they'll make rough choices.. | 22:26 |
| clarkb | yup | 22:26 |
| clarkb | I'm just annoyed that a 10 year old switch does not have spare parts available anymore | 22:27 |
| clarkb | for systems that are expected to last multiple decades | 22:27 |
| gouthamr | crazy indeed.. "right to repair"! | 22:34 |
| clarkb | its a consumable part too which is the real annoyance | 22:42 |
| clarkb | like being unable to buy an oil filter or light bulb | 22:42 |
| fungi | in theory that should create a market for third--party replacements | 23:20 |
| clarkb | yup we tried that. Found a company in china that claimed they had them then when we put an order in they disappeared. (They are large arc chutes) | 23:32 |
| opendevreview | Merged openstack/election master: Add Ghanshyam candidacy for QA PTL https://review.opendev.org/c/openstack/election/+/1001574 | 23:56 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!