Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-06-17
16:46:55 gibi but it won't create satisfaction from the contributors as they feature will not land this way either
16:47:00 sean-k-mooney that partly pickign yoru favorit rather then which isready
16:48:04 fungi i also think satisfying ungrateful or entitled contributors isn't a goal, they're generally going to become a time sink, what would help is figuring out how to improve the experience for people who are likely to stick around and help
16:48:31 gibi how do I foresee who will stick around and help?
16:48:36 fungi and yeah, being able to tell the two apart isn't easy
16:48:40 gibi yeah
16:48:53 gmaan IMO, merging the spec is 'we welcome the ideas/feature requests' and if slow/no review in code then yes we face challenge in review bandwidth so help here
16:49:10 gibi should we require one cycle of active bugfixing from someone before we review their spec?
16:49:13 sean-k-mooney i guess folks that engagen in the review positivly and relfect on feedback
16:49:23 fungi but, for example, people who pester me for reviews on things that have only been open a day or two? i tend to ignore them and their changes, or at most explain to them that their expectations are unrealistic
16:49:24 sean-k-mooney is a good indication to some degree
16:49:59 fungi (unless it's clear that the change is urgent for the project and not just for the person proposing it)
16:50:09 Uggla maybe dumb question, the feedback are for nova or global for openstack project ?
16:50:45 fungi what i outlined above was the result of looking at the handful of resurvey responses we received for nova, and nova-specific gerrit metrics
16:50:58 fungi the posts on the mailing list are openstack-wide analysis
16:51:08 ildikov +1
16:51:10 dansmith this sounds like the same feedback we've had for ten years to me
16:51:20 gmaan yeah, maybe more than 10 :)
16:51:28 sean-k-mooney fungi: i read the mailing list post and i think there is a simliar corratlation tbeween nova's feedback and the wider feedback
16:51:43 Uggla fungi, thanks. What about other projects ? Same feelings about reviews ?
16:53:22 dansmith I always chalk this up to people wanting to drive-by a fix with no tests, a spec with no promise of CI, or the hard work to refactor the things necessary to make it work for more than just their niche case
16:53:27 fungi to some extent, yes, nova had lower overall numbers than other projects we looked at, though for the metrics i think a lot of that is due to outliers and "long tail" values skewing the averages, median values suggest there is still al lot of work getting done and there are more changes getting merged than propoosed each cycle, so the perceptions don't necessarily represent
16:53:29 fungi reality in all cases
16:53:52 dansmith and a decade of that sort of thing makes us fairly conservative in what we accept (code, not specs)
16:54:07 sean-k-mooney we did have a cople of large feataures like manila shares that took 4-5 releases
16:54:21 dansmith and we often get feedback that specs hold up implementation (even though they don't) so I think that's why some specs get approved even though we're not going to review the implementation
16:54:24 sean-k-mooney nova ofthen has deps on other projects that can take a whiel to resolve
16:54:27 fungi however, from what we can tell it seems like a small number of poor experiences can disproportionately influence contributors' perceptions of the whole
16:54:32 ildikov Would seeing the metrics per release cycle help with evaluating what to do with the survey results?
16:54:37 dansmith or people think that an approved spec means we won't object to the actual implementation
16:54:47 dansmith sean-k-mooney: also that
16:54:48 ildikov Like the time needed for first reviewed to happen, patches to get merged
16:56:01 sean-k-mooney ildikov: maybe but im not sure how actionaable that data will be
16:56:19 fungi yeah, we're at least initially trying to avoid dumping the project-specific analyses to the ml since we don't want it to turn into side-by-side comparisons and this-team-is-better-than-that-team sorts of discussions, but we can find a way to share more concrete numbers
16:56:21 dansmith yeah, pretty meaningless to me
16:57:08 gibi yeah, I would be more interested in case studies on specific contribution attempts
16:57:24 ildikov sean-k-mooney: I understand. I was thinking to compare how long things take with what people’s impressions are. And see if there’s any that’s better or worse than what people had in mind. And then see which one we’re can help y’all figure out how to improve.
16:57:43 sean-k-mooney knowing what the outliers were might help at least we could know if they should be excludied or were really a problem
16:57:51 ildikov This isn’t something to solve in one meeting. But wet would like to help figure out how to make improvements.
16:58:13 ildikov And whether or not those actions are helping, or were should try smth e we else
16:58:13 sean-k-mooney i.e. if it took 200days to merge but was teh 30th patch in a seriese that might mean the data shoudl be excluded
16:58:28 fungi i think it's also reasonable to ignore it all as "this is nothing we don't already know" but at least some feedback on what you'd like looked at (e.g. the idea of trying to gauge the contributor survey respondent's level of involvement in helping the project in other ways) is definitely appreciated
16:58:55 ildikov I’ll look into the case study approach
16:59:06 sean-k-mooney fungi: ildikov well i think the general trend are useful and if a project is vastly diffent then another hten it woudl be interesting to know why
16:59:15 dansmith fungi: I'd also say "nothing we don't already know and have tried various things to address in the past, with minimal success"
16:59:26 sean-k-mooney but i think part fo that comes down to the project in quetion too.
16:59:30 ildikov Might not be for a meeting to discuss that, since we can’t make that anonymous, etc
16:59:40 dansmith fungi: we've done all kinds of things like core sponsors, runways, etc..
16:59:52 fungi we've certainly done some case-by-case studies leading up to this (it started from specific member company representatives giving us lists of changes where they struggled and maybe gave up)
16:59:52 ildikov sean-k-mooney: +1
17:00:15 dansmith specs themselves were sort of a solution to this problem in the first place, and they improved some things but introduced a hurdle that sometimes get complained about
17:00:24 fungi part of the challenge is to avoid public shaming while finding ways to steer toward constructive feedback
17:00:53 ildikov +1
17:00:59 Uggla We are on top of the hour. So can we wrap up ?
17:01:04 fungi anyway, i didn't want to run over the end of the meeting
17:01:07 fungi thanks!
17:01:11 gibi ildikov fungi Thanks for the effort
17:01:16 fungi i'm always around for more discussion after
17:01:17 dansmith fungi: yep, appreciate that, because since this has been a complaint for over ten years, some of us are likely to feel like rage quitting :)
17:01:41 Uggla ildikov, fungi, thanks
17:01:44 ildikov We would love to avoid that! :)
17:01:59 ildikov Thanks y’all!
17:02:57 Uggla I wonder if we can postponed the open discussion to next week. There is a topic about Evacuate Action & InstanceInvalidState, but I don't know who entered it.
17:03:44 fungi while it may be an unpopular approach, the way a lot of open source projects (particularly volunteer-run communities) approach that challenge is by just saying that complaining only serves to burn out the handful of people keeping things going, and to either help shoulder their burden or go away
17:04:24 Uggla fungi++ completely true.
17:04:48 fwiesel Uggla: That would be me. Then maybe two weeks?
17:05:00 fwiesel In two weeks, I meant.
17:05:36 Uggla fwiesel, yes I keep the items and we will discuss it not next week but the week after.
17:05:48 fwiesel Uggla: Thanks.
17:05:52 gibi fungi: yeah then we need to figure out how they can effectivel help shouldering the burden
17:06:50 Uggla fwiesel, thanks you to understand. I don't want to keep people here anymore as we are already overtime.
17:07:02 Uggla Thanks all
17:07:15 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-06-17-16.02.log.html
17:07:15 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-06-17-16.02.txt
17:07:15 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-06-17-16.02.html
17:07:15 opendevmeet Meeting ended Tue Jun 17 17:07:15 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:07:15 Uggla #endmeeting
17:07:18 gibi Uggla: thanks
17:27:08 sean-k-mooney ^ that actully a ligiitmate suggestion
17:27:29 sean-k-mooney no mather how often we tell them ot never use it after a issue with a move operatiorn they still do
17:28:30 sean-k-mooney if we made them opt into it or had a "allow_foot_guns" role it would avodi lot of reset-state related pain
17:29:26 sean-k-mooney sort of like cephs --yes-i-really-mean-it flag to make them do just a littel bit more to do the unsafe thing
17:29:38 gibi sean-k-mooney: I'm supportive
17:32:34 sean-k-mooney i feel like if we do it will be a https://xkcd.com/1172/ and i tink im ok with that
17:40:45 gmaan sean-k-mooney: seeing it is admin currently, it should be very noticeable that what they are doing but I will not be against of blocking it via policy.
17:40:53 gibi sean-k-mooney: pretty much yes :)
17:41:06 gmaan but I think we should remove it or restrict it in some separate seciton in api-ref
17:41:53 sean-k-mooney gmaan: well changing the policy is the more consrevity change i actully want to deltee that api
17:42:33 gmaan sean-k-mooney: I am up to delete it. I am not sure what all cases it was helpful but it can/has been distructive in many cases
17:43:02 sean-k-mooney gmaan: i twas orgianlly added to help when your stuck in an intermediate state
17:43:53 sean-k-mooney most of the time the fix is hard-reboot or delete dependign on the state
17:44:01 gmaan yeah
17:44:04 sean-k-mooney i.e. if your stuck in buildign then delete
17:44:47 sean-k-mooney if we changed defautl policy we coudl get feedback form operators before commitign one way or another
17:46:41 sean-k-mooney i added --auto-approve and made it request an interactive approve in osc recently https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#cmdoption-openstack-server-set-auto-approve
17:47:25 gmaan sure, that will help at least to know if people want it or we can delete it. at least keep it restrictive for some cycles and if any one ask for it at least then it is not good to delete
17:47:30 sean-k-mooney so not it at least asks you are you sure before it will do reset state
17:47:44 sean-k-mooney s/not/now/
17:47:49 gmaan sean-k-mooney: yeah I saw that . ++ that was good from ux side
17:49:32 gmaan sean-k-mooney: if dis-allow in policy, do we need to remove/change anything from client? or nova error about unauthorized is enough for admin to know what they need to do

Earlier   Later