Time Nick Message 01:36 MTDiscord idk, I have NVME m.2 drives at work and the switch to RAM was a nice speedup for our compilations 11:47 [MatrxMT] PRs are still on the rise, that's not good, although I do realise people have more free time during the summer. If we could focus on approving more rather than opening new PRs it'd be great 11:48 sfan5 >I do realise people have more free time during the summer 11:48 sfan5 you mean less? 12:08 [MatrxMT] sfan5: no, more. Like people who maybe would like to contribute but they're busy with work/studying, they can actually do it in summer (and around the end of the year) 12:09 [MatrxMT] People as in external contributors 12:12 [MatrxMT] Pulse data is of no help but my perception is that we've seen more PRs than usual in these weeks 12:49 MTDiscord I had a small unit test PR that was already reviewed and merged. I had a break between internship and classes and had time to contribute, like Zughy said. 12:51 [MatrxMT] Knowing these things is helpful for the future in my opinion, as it allows us to know what to expect more or less according to the time of the year. For instance, I don't remember a significant increase right after FOSDEM 12:52 MTDiscord don't forget summer is the vacation season there's nothing surprising in people wanting to lay on sunny beaches instead of sitting behind a computer screen 12:52 MTDiscord and when that season comes to an end, everybody's like "shit I got to lock in" 12:53 [MatrxMT] So if "I" know that e.g. August and December are in general pretty hectic, I won't start new ideas during those periods as it might bring to overwhelming me and/or the the rest of the staff 12:56 MTDiscord BTW what is this channel bridged to on Matrix? #minetest-dev:libera.chat doesn't seem to update at all, nor does it have any messages in it 13:13 MTDiscord anyways. is this another non-personal-but-pretty-specifically-personal jab? should I apologize for making a PR at the "wrong" month? 13:14 MTDiscord I'm not saying your points are invalid, it's just that, again, you could've addressed me directly 13:20 MTDiscord ...in case it relates to me, of course 13:21 celeron55 i'd say... all of it is par for the course: zughy stressing out on the number of PRs, everyone being busy at every time of the year, and contributors being confused 13:22 celeron55 (i don't mean it's very good, but it happens) 13:37 [MatrxMT] rudzik8: what, no, I'm genuinely preoccupied for the status of the project. Can people stop thinking I'm an arsehole please? :/ 13:37 MTDiscord celeron55: Minetest has 115 open PRs and we in VoxeLibre have 113 open PRs 13:38 MTDiscord Tbh I'm not stressing over that in VL, and in my opinion engine may have well more PRs than a game made under it 13:39 [MatrxMT] Yep but we were able to reach ~70PRs, which I think it's healthier 13:40 MTDiscord I was trying to keep PRs under 25, then under 50, then under 75, then I gave up and it is what it is 13:40 MTDiscord Wr have a lot of drafts for example, and it's OK 13:40 MTDiscord Btw rudzik8 wanted to close some of them and I refused. 13:41 MTDiscord We have* 13:43 MTDiscord Zughy: re "thinking you are arsehole": we genuinely think your reaction to my doc PR was way overreaction (suggesting to remove the behavior entirely) 13:43 MTDiscord So you should understand that our devs may be way too suspicious of whatever you say 13:46 MTDiscord In this case rudzik unnecessarily took a general observation - one that was even made before any of the drama in that issue unfolded - personally. See e.g. the mainmenu redesign issue, where Zughy deferred pinning it to avoid overwhelming the team. 13:46 [MatrxMT] I think that my 3rd comment was too, I was nervous and I shouldn't have commented in that mental state, so I'm sorry for the tone. But I don't think that portraying me like that in general is fair 13:47 MTDiscord Now returning to the negative saturation thing, because that's what I came here for: it's not inversion, but it certainly is an interesting effect. I have posted some information on a non-bridged channel, and I'll post it again here: * it preserves Luma (perceived brightness) * it preserves saturation (expressed as chroma/Luma), so 1 and -1 is the same saturation * it alters hue either by exactly 180 degrees or by some seemingly random 13:47 MTDiscord value 13:48 MTDiscord Looks generally like some form of "brightness preserving inversion", since normal inversion turns light colors into dark ones and vice versa 13:48 MTDiscord Quite interesting tbh 13:49 MTDiscord I still think it should be kept and documented, and I'd like to talk about how to word it here. 13:50 MTDiscord If this is to be documented, the only viable way is probably to just slam the formula there. 13:51 MTDiscord So just slam the formula and then describe the effects a bit? 13:52 MTDiscord Yes, that seems acceptable. 13:53 [MatrxMT] herowl: on AES whenever we reach 50 issues we stop from introducing whatever new feature (except for "Waiting for upstream"). Not too much fun sometimes but everything is in order and whenever some big bug/crash pops up, we have all the time to focus on that without the pressure of the rest of the huge pile 13:54 MTDiscord We have over 900 issues on VL repo 13:54 [MatrxMT] Ouchie 13:54 MTDiscord I understand this and won't try to escalate this, only explain myself I think Herowl had put this better than I could ever do. my previous interaction with Zughy on GitHub don't make this one any better if Zughy feels like they're portrayed wrongly, I'm sorry, but that's how some of your messages can come across. I don't actually think Zughy's an "arsehole" 13:54 MTDiscord Many of which probably could be closed by now... but yeah 13:57 [MatrxMT] rudzik8: thank you for the clarification, I hope there's no bad blood between us, and actually thanks for your latest PR :) 13:58 MTDiscord Zughy: thanks for all the work you put into Minetest ❤️ 13:59 celeron55 enterpreneurs use the term "positive problem". as annoying as it is, too many PRs is one of those 14:00 celeron55 yes you can have policies with hard limits, but that would be a big change to how MT development is run 14:06 MTDiscord if we're entrepreneurs now we should start putting AI and crypto into Minetest 😄 14:07 MTDiscord On a more serious note, I don't think hard limits are a good idea, because priorities need to be pretty dynamic. 14:08 sfan5 priority: deliver the next release and have it be overall better than the previous one 14:13 luatic Anyways sfan5, Desour: What's your status on the static gltf PR (#14557)? 14:13 ShadowBot https://github.com/minetest/minetest/issues/14557 -- Add static glTF support by JosiahWI 14:13 luatic I interpret Desour's last comment as wanting to do a review? If so I'll wait for that to finish before I merge. 14:14 Desour I just wanted to take a quick look (to see what changes in the minetest codebase), and found some small things. I didn't want to do a full review. so go ahead with the plans you had before I came :) 14:22 luatic Desour: Great, thanks for letting me know. Guess I won't have to reschedule the merge party in *checks notes* 3 days. 14:22 MTDiscord Haha, I was just checking the date, too. 14:24 MTDiscord Place the glTF loader on the ground then lie on your stomach with your arms at your sides. A merge party associate will arrive shortly to collect you for your merge party. 14:34 sfan5 luatic: no status change. if I don't get to it, don't wait for me 14:35 sfan5 only concern is conflicts with #15076 14:35 ShadowBot https://github.com/minetest/minetest/issues/15076 -- [no squash] Ability to handle vertex and index VBOs separately by sfan5 14:35 sfan5 it might be easier for you to rebase yours than me mine 14:46 luatic hmm, i'd expect there to not be significant conflicts either way. the impact should be comparable to the changes needed in the other loaders. 14:48 sfan5 if you squash yours that one conflict vs potential 5+ conflicts, I was thinking 14:51 luatic sfan5: i was planning to squash it anyways, the history isn't terribly useful at this point 14:52 MTDiscord I think people reacted badly to the "negative saturation" issue because they felt like they were trying to make an improvement to the engine (improve documentation) and got "burned" by it when it looked like they were going to lose access to a feature because of it. 14:52 MTDiscord I've gotta admit that that I've noticed that kind of chilling effect myself. There have been times when I've been unsure whether it's a good idea to file an issue because there was always a risk that the resolution of the issue would make the engine worse for my use-case. 14:54 MTDiscord There was clearly a disconnect there because gamedevs found a weird funky psychadelic effect and didn't really care about whether the underlying math behind it was "correct", but the engine devs seemed to care about having only correct, well-specified, and planned functionality. 14:55 MTDiscord A lot of the time we're trying to make games fun and interesting, not correct or rational. That leads to conflicts like this. 14:56 luatic to make my stance clear, i am not in favor of taking this feature away. 14:57 luatic i see either the option of keeping it (which leaves a bit of a sour taste in my mouth but i can live with it) or deprecating it in favor of a "proper way" to achieve a similar effect in a more well-behaved manner. 14:58 MTDiscord Unfortunately that's not entirely in your control, and as gamedevs we've seen discussion around an issue evolve like -> we shouldn't support this hack, we should do it properly -> split "remove the hack" and "do it properly" into separate issues -> "remove the hack" is easy and gets done, "do it properly" turns out to be complicated and stagnates. It's a natural risk in issue management and it happens in our own backlogs too. 15:01 luatic warr1024: i mean it in an atomic way. as in, i'd not accept a PR that just does one without the other. 15:01 MTDiscord You could probably mitigate the chilling effect on issue reporting this causes by providing some kind of guarantee that "remove the hack" will always be a dependency of "add the proper fix" first, so at least we can be sure we will never lose ground. Having to add version compat hacks to transition from a deprecated method to a supported one is a mere annoyance, but a gap in functionality is a different story entirely. 15:01 sfan5 has this actually happened in the past? 15:02 MTDiscord Like I said, it's not only the minetest engine where people learn this :-) 15:04 MTDiscord If you're asking for a specific case of it, I don't recall one, but it's been quite a few years and I forget a lot of stuff. I'm pretty sure that I'm not just projecting this from other projects, and I've seen it in MTE before. I'm not sure if it every eventually worked out this way (very often neither adding the proper fix NOR removing the hack ends up happening) but the "threat" of it is enough to make people regret they reported 15:04 MTDiscord something. 15:04 MTDiscord People who reported negative saturation are already surely regretting having gotten involved, and that issue is nowhere near resolved. 15:08 MTDiscord The irony is that MTE has actually historically taken a very strong pro-backwards-compat stance to the point where it makes forward progress hard because of old features that are a pain to deprecate gracefully. The problem arises because people aren't sure that "backward compat" includes old bugs, even if they turn out to be useful. 15:08 MTDiscord Undocumented features are a calculated risk we often have to take. Making a game that uses ONLY completely documented APIs ... actually sounds like kind of a fun challenge someday, or maybe some kind of penalty game 😆 15:10 sfan5 documented APIs is not that hard depending on what you're doing 15:10 sfan5 but you often rely on internal behaviour despite that 16:16 [MatrxMT] RE PRs: the goal here is not to have policies with hard limits, just to avoid the situation to become unmanageable 16:19 [MatrxMT] Right now on the table we have: 5.9.1, 5.10, name change, 100+ PRs and (for some of us) the hope to go to FOSDEM 2025. That's already too much in my opinion 16:23 [MatrxMT] And if more things keep coming without others being addressed, the result is that something will be forgotten because it'll come a time where people will be busy with life and it won't be able to tackle all these things - or they'll do it poorly 16:26 [MatrxMT] To be clear: with 5.10 I meant the experiment of releasing more often. Which, being new, it'll need time for us adapt and draw conclusions 16:26 [MatrxMT] *to adapt 16:27 MTDiscord did anyone every agree in 5.10 what the experiment was going to be? other than the hope of releasing faster? i know there was some ideas put out 16:30 [MatrxMT] Not in the details as far as I remember, just release every 3 months 16:31 MTDiscord I like the idea of a regular release schedule that's independent of whether thare are significant changes or not 16:32 [MatrxMT] Right now it's the "wishlist" time, where you see different kind of issues and PRs added in there. I guess that one month prior we'll keep removing things not doable in time from there, yet this might result in contributors being annoyed. We'll see 22:21 [MatrxMT] Zughy. I will apologise for going heavy on you. I will also apologise for making assumptions about your motives. I will also thank you for the work you put in on the high priority bugs, it's much needed 22:21 [MatrxMT] I have to be honest though, I get frustrated with your approach at times, and I do hope things can improve 22:23 [MatrxMT] what works in AES may not work in a larger project. i don't think you can put arbitrary numbers on prs and issues and enforce them. anything over that number it is like giving a middle finger to them 22:23 [MatrxMT] the desire for tidyness and organisation comes at a cost of openness 22:23 [MatrxMT] godot have 2.8k issues https://github.com/godotengine/godot/pulls 22:23 [MatrxMT] sorry, prs, and 5k issues 22:24 [MatrxMT] obviously they're well funded, but they're also well organised and progressing well. they're also scaling up effectively 22:25 [MatrxMT] if there are too many issues, and some are irrelevent right now. mark them as low priority, and ensure people know how to use filters on github. even share some useful ones 22:25 [MatrxMT] same with prs. if you go to prs and ignore all marked low priority, it's pretty clean 22:26 [MatrxMT] a successful project isn't something with an empty issue tracker. it's full, as people raise the bugs. it also has a LOT of prs, because people are trying to help fix it 22:27 [MatrxMT] tags such as "awaiting contributor" for example, means you can filter by most recently updated and see if anything needs moving off there, and you can get all prs, minus low priority or awaiting contributors. good filters keep things clean and easy for devs. good clear milestones also 22:28 [MatrxMT] but if people care about mt, and raise stuff, and it's ignored. folk get frustrated. people do not get frustrated about stuff they do not care about. people do not always want to get there way. they just want to be listened to 22:29 [MatrxMT] they just want some consideration that what they're raising isn't going to be thrown a no by default. it's exhausting having to justify something every time. it's easier to ask why first, than to say no and have to u-turn later 22:29 [MatrxMT] if you default to no, the interactions you will have on the issue tracker will be a lot harder as the strategy is a frustrated other person by default 22:32 [MatrxMT] the thing i realised, is you never get a clear issue tracker. you'll never be bug free. the moment you make things could, people raise somewhat unimportant stuff that is annoying. you close 10 high priority issues, and 20 low priorities appear. that's fine. you just focus on the criticals -> highs -> elevateds -> mediums 22:32 [MatrxMT] and by the time you're on the mediums, your issue tracker is still pretty full, but you software is much better 22:33 MTDiscord Pretty sure most of us dont hold the opinion that "less prs is better" 22:33 [MatrxMT] triaging issues is about prioritising, not removing 22:34 [MatrxMT] in a hospital, they don't remove not dying immediately but still sick people, they just want to know who to deal with first 22:34 [MatrxMT] green, maybe, but zughy is the active face of mt issues as a triager, and it's the policy of mt at the moment it seems 22:35 [MatrxMT] but if priorities can get put on, and or areas of where it is (shaders, ui etc.), contributors can find what they need 22:45 [MatrxMT] i will say warr made some excellent points earlier 23:19 MTDiscord not that i don't agree with this but they do remove "not hospital kind of sick" people pretty quickly :p 23:20 MTDiscord I wouldn't say "fewer PRs is better" but "fewer PRs that are ahead of mine in line" definitely are. Work tends to get added to a queue in various places, as priorities are evaluated. However, when it's being pulled off the top of the queue at all, it's being pulled off at a certain maximum rate. 23:21 MTDiscord The problem is that, the more items there are above any specific item in priority, the more likely it is that any new item in the future gets added above it. That means that unless the rate that items being added above is less than the rate they're being dequeued, then your item is moving BACKWARDS on the conveyor belt. 23:21 MTDiscord I think the actual point is the number of issues or PRs open, closed or processed says little about how much work got done or how well a project is doing 23:21 MTDiscord We can hang onto items like that forever if we wish, but we need to be realistic about whether they're actually going to get worked on, and we can't be reevaluating their priority at every meeting. 23:21 red-001 merging more PRs is how you get fewer PR realistically. 23:21 red-001 PRs* 23:22 red-001 merge or close 23:22 MTDiscord Making decisions about PRs is how you get to fewer PRs. That decision could be merging, yes. But MTE for better or for worse has certain standards it wants to meet, and not every PR is going to meet those. 23:23 MTDiscord Closing PRs without an explanation, or recourse, is a pretty lousy experience for the opener. The core team may need to just provide some kind of "so, your PR got rejected, here's what's next" guide or something that lets people down gently and gives them advice on how they might make another attempt at it next time. 23:24 MTDiscord Resubmitting a rejected PR should be fine, but probably have some kind of rate limit, like you can only attempt it once per release, where we start doing releases every 3 months regularly. 23:24 MTDiscord in my experience it can be good to help PRs to meet standards as a way to get things done more quickly 23:24 MTDiscord Right, and the core devs could really use more help with that. 23:25 MTDiscord Not being a core dev means you can't make an authoritative decision about a PR, like voting to merge it, but it doesn't mean you can't give somebody advice, if you understand the standards well. 23:26 [MatrxMT] do you need to reevaluate the priorities of everything at every meeting? if you have 10 high issues. 5 mediums, and 20 lows, you can ignore anything but the highs. of couse give facility for someone to appeal priority 23:26 red-001 I'm not convinced endless debate on non-feature PRs is doing much to help with keeping code standards. If the change isn't *worse* than the existing implementation. 23:26 red-001 features are difference of course 23:27 MTDiscord If, say, we've got 50 PRs, and it's quite clear that there's no way 30 of them are going to get reviewed before the 5.10 deadline, then I think we should just close those 30, with each one getting a message saying "sorry, not planned for 5.10, if you still want this, please reopen when 5.11 dev starts" and possibly some advice about making it clearer WHY the thing should be considered higher priority next time around. 23:27 MTDiscord why 23:27 MTDiscord AM: no, you don't have to reevaluate things that are already low priority, but if they're "stuck" in low priority then that's sort of like the trash can already. 23:27 MTDiscord who does it hurt that a pr is open? 23:28 MTDiscord Closing the prs seems pointless 23:28 MTDiscord cora: two reasons. 23:28 [MatrxMT] why close them? why not just not have them in themilestone? 23:28 [MatrxMT] then you just click on the milestone and that's all you have to care about 23:28 MTDiscord For one, it's more honest to tell people up front that their work is not going to get merged this cycle instead of just slapping a "well maybe" label on it when you already know it really doesn't have a chance. 23:28 MTDiscord AncientMariner: by your 2nd "them" you mean those PRs you want in the respective release (high priority ones), correct? 23:28 [MatrxMT] closing if an author doesn't do anything in a few months is fair with adoption needed 23:29 MTDiscord well you can tell them without closing the pr 23:29 MTDiscord the other reason is that it naturally filters out stuff that the authors themselves don't really care about, making it more likely that PRs whose authors DO resubmit next cycle get merged. 23:29 MTDiscord e.g. with the milestone thing as ancient proposed 23:29 MTDiscord If literally closing the PR seriously causes a bunch of butthurt then we can just slap a "not closed :-)" label on it, it makes no difference to me. 23:29 [MatrxMT] if someone raises a pr to fix something, just because it isn't in the delivery plan, doesn't mean it's not valid. if it's poor, say why and close, or give feedback on how to improve 23:30 red-001 or could just merge more 23:30 MTDiscord Yeah, closing prs is the wrong function to use for "not this release" 23:30 [MatrxMT] i would say if something hasn't been reviewed in 2 months, someone should try and get some eyes on it 23:31 [MatrxMT] because after 2 months, that person stopped caring about it 23:31 red-001 I mean there's no reason contributors shouldn't be asked to review other PRs and those reviews shouldn't count towards approval 23:31 MTDiscord If you want to keep the compost pile in the same place as the stuff being worked on, that's fine too, I'm pretty sure GH supports that. It won't change the reality though that some things are just not moving forward. 23:31 MTDiscord Maybe the disconnect here is we disagree who as at fault for not moving forward 23:31 MTDiscord "Get some eyes on it" is not going to happen if even a PR's OWN author has abandoned it. 23:32 [MatrxMT] i do not understand a person who could be ignored for months about something they were enthusiastic about, then given feedback and jump in with the same energy 23:32 MTDiscord If NO PRs are moving forward then that's the core team's fault. If SOME PRs are moving forward, then it's not. 23:32 red-001 people do in fact have things to be doing 23:32 MTDiscord It depends entirely on the pr 23:32 [MatrxMT] as i say, if they abandoned it for 2 months, close with needs adoption 23:33 [MatrxMT] but often it isn't with the author 23:33 [MatrxMT] i've seen 5 line prs closed for inactivity in 1 month 23:33 MTDiscord You can't say it is an entire groups fault for all slowness based on overall metrics 23:33 [MatrxMT] i mean come on, probably easier just to review it and give a comment 23:33 MTDiscord idk if it's that simple then again it isn't really about who's fault it is 23:33 MTDiscord i will say i have seen many PRs that seemed very promising which ended up going nowhere sometimes because of seemingly trivial stuff 23:34 MTDiscord MTE's PR queue is not a bin you can just throw code in and say "here you deal with it," it requires active advocacy and maintenance. A PR author must first meet that hurdle, unless they're lucky enough to fix something high priority enough that it can't wait. 23:34 [MatrxMT] faults are not helpful. blame does not solve problems. it does not create improvement 23:34 MTDiscord If an author abandons a pr, close it. If devs aren't reviewing a pr and it gets stale, its the devs fault not the author. It shouldn't be closed on that account. 23:34 MTDiscord The core team has no responsibility to any specific PR, their responsibility is only to the collective. 23:35 MTDiscord What exactly is an author supposed to do to get something merged? 23:35 MTDiscord Is there a documented process? 23:35 [MatrxMT] agreed, green 23:35 MTDiscord If a PR is low priority and PRs with higher priority are getting merged, then it's not the fault of the devs doing the reviewing and merging. It's either because the author didn't communicate the priority well enough or convince people it was important, or because the people deciding on priority screwed up. 23:36 MTDiscord Even if a pr is low priority it shouldn't be closed simply because no one has gotten to it yet 23:36 MTDiscord The fact that it's assumed that the same people will be deciding priority and also doing code reviews is ... frankly, kind of weird, for a project this scale. 23:36 MTDiscord something being someones fault kind of implies intent. I do not think any of this is because anyone involved has bad intentions 23:37 MTDiscord Closing a pr requires intent 23:37 red-001 the issue has always been a bad review process that focuses too much on a few core devs having the time to look at the PR. Rust has a process where people are randomly assigned to review PRs. Getting all active contributors to take part in that would get things reviewed quicker 23:37 MTDiscord The intent to close a pr when an author is maintaining it but no devs are reviewing is a bad intent 23:37 [MatrxMT] tidying is not bad intent. they intent is to clean, the effect could feel like a slap in the face 23:38 MTDiscord zughy usually handles closing prs, but iirc if it has action/change needed label and the author hasnt done anything in a month it gets closed 23:38 MTDiscord Whether fault implies intent or not, it certainly implies responsibility to correct it. The total amount of responsibility each role/person has should be limited. 23:38 red-001 it seems fair to not review someones PR unless they for instance review 5 other PRs from other authors 23:38 [MatrxMT] the art of it is to understand what doesn't work, and what changes could be made to improve things 23:38 MTDiscord I would appreciate more contributors partaking in reviews. That's also the path that leads to them becoming core devs in some cases :-) 23:38 [MatrxMT] insanity is doing the same thing and expecting different results 23:38 MTDiscord We can't have the core team be responsible for reviewing and nurturing and guiding every PR when there is not limit to how many can be thrown at them. They need to be allowed to triage some. 23:38 MTDiscord nah i think the intent is probably to maintain some sense of order i would not say the intent is "you suck your pr is bad, go aways" hehe 23:38 MTDiscord Haha, lars, you're not exactly upselling it there :-D 23:39 MTDiscord When merges are labeled as requiring dev approvals, most contributors don't feel they have any say or use in reviewing 23:39 MTDiscord "Help out with some reviews, and you can have a bunch of responsibility and be underappreciated too!" 23:39 MTDiscord "We are closing your actively maintained pr because we can't keep track of all these prs" 23:39 MTDiscord yeah that is probably a quite important point 23:39 red-001 it should be everyone's responsibility to review PRs, green is right that people aren't encouraged to do it when it's not considered in merge decisions 23:39 [MatrxMT] maybe there needs to be more focus on groups below core devs, folk trusted to help out and get a pr from horrific into reviewable 23:39 MTDiscord In order for the community to get involved in reviewing we MAY need to have something like a "needs code review" label specifically, and let people know that that means that it WOULD help. 23:40 MTDiscord red: "everybody's responsibility" isn't very helpful though, as that often just means nobody's responsibility. 23:40 MTDiscord Having only core devs and no other role doesn't seem right for a project this size. 23:40 red-001 well that's why I suggest it's enforced by requiring people review other PRs if they want theirs to be reviewed 23:40 MTDiscord We should probably have more roles 23:41 MTDiscord Like, there's no steering by gamedevs. How is a project supposed to be successful if it only ever haphazardly gets feedback from its actual users? 23:41 [MatrxMT] core devs can set direction, standards stuff to look out for 23:41 [MatrxMT] and it's almost like a mentoring program for newer high potential folk 23:41 [MatrxMT] who can review 23:41 MTDiscord I've suggested that there be an official gamedev steering committee at one point but everyone said "oh, that might be a good idea, I guess" and then did jack all about it. 23:41 red-001 now sure with mandatory reviews, some of those reviews won't be very useful, but making it a requirement to put the minimal effort in requires someone at least tries least they look like they are avoiding their responsibility 23:42 [MatrxMT] very good idea warr. an engine is only as good as it's uses 23:42 MTDiscord gamedevs are major stakeholders, it only makes sense. A lot of what we do is working around engine bugs and quirks. We also know what kinds of issues we can live with. 23:42 MTDiscord no time i'm busy fixing hud_elem_type :p 23:43 [MatrxMT] prolific modders too 23:43 MTDiscord can the gamedev steering committee please speak up 23:43 MTDiscord Players have a stake too, though theirs is partly indirect. Things like accessibility, translations, and a lot of main menu stuff (like content browser and server list) affect players directly. A lot of game features like Lua APIs are more things that affect gamedevs. 23:44 MTDiscord Obvious gamedev steering candidates would include publishers of major games on CDB that are still actively maintained. 23:44 MTDiscord seriously though i think if there was such a group of gamedevs willing to step up, i imagine there'd be less of a hurdle of bestowing them with such a role (though to an extent, they've always had it by virtue of minetest folks recognizing their names...), vs. if we first have to chase after them 😅 23:45 MTDiscord That disqualifies me ;D 23:45 [MatrxMT] i think there are folk that would step up, if they were welcome to step off 23:45 [MatrxMT] you don't step up to get your head knocked off 23:45 MTDiscord I'm willing to lend my voice, talk about my priorities, etc. I'd need to know about what you actually want from somebody in my role before I can commit to anything specific. 23:45 [MatrxMT] you don't give feedback if you expect a "ahhh, shut up" 23:46 [MatrxMT] or a polite "no" 23:46 [MatrxMT] "no", and "definitely not" to anything anyone says 23:46 MTDiscord I have time concerns; I take hiatuses from game dev every so often for IRL reasons, so I could participate in meetings but maybe not be in charge of making sure they happen every week or something. 23:46 MTDiscord There are also quite a few gamedevs that don't publish games because they can't finish them due to missing engine features.. their input sounds rather valuable 23:47 MTDiscord the "unhappy gamedevs steering committee" unironically sounds like a great idea 23:47 MTDiscord AM: The MT project has always been sensitive to the risk people have of becoming abuse targets for their involvement in the project, and has pretty careful policies about e.g. maintaining people's pseudonymity and such... 23:47 [MatrxMT] maybe if there is a forum for game devs and modders to discuss what they care about 23:47 [MatrxMT] and it can influence priority labels, that'd be cool 23:47 MTDiscord Green: if you can identify them, we should throw their names in the hat and invite them. 23:47 [MatrxMT] it would almost be a form of triage too 23:48 [MatrxMT] a way to perculate ideas and come up with a convincing pitch that can cover multiple uses 23:48 [MatrxMT] but without mt approval, it'd be a stealthy union of the disgruntled 23:49 MTDiscord I mean even something pretty simple, like, each release cycle, each member of the steering committee gets to cast votes on PRs to get prioritized somehow, that would get things started. 23:49 [MatrxMT] turned pitchfork brigade 23:49 MTDiscord AM: though, never underestimate the MT community's ability to overestimate its own ability to actually organize. Most of us are just sitting at home polishing their own pitchforks. Mine is actually holding up a table leg. 23:50 MTDiscord idk, you can prioritize all you like ultimately someone has to do the work 23:50 [MatrxMT] yeah, but how do you know what to work on if it isn't prioritised 23:50 MTDiscord Well, if people on the gamedev steering group want to do some actual work too, they're welcome to. 23:50 MTDiscord Thats the neat part: We dont 23:50 [MatrxMT] if you have 900 issues, that's weighing up 900 things, if you have 50 highs, that's weighing up 50 23:50 [MatrxMT] no one can weigh up 900 issues and decide what to work on 23:51 [MatrxMT] maybe it could do with a channel to discuss things 23:51 MTDiscord Ultimately we can't force people to work on things they really don't want to work on, this IS a hobby project run on volunteer time. All we can do is make it easier for people to pick the things that will give more value. 23:51 MTDiscord Not even the devs have any real priorities. There isnt a real vision for the engine or anything. Just a handful of "this could be better for now"s 23:52 MTDiscord We don't need to actually SOLVE the whole problem yet, just IMPROVING the situation is worthwhile. 23:52 [MatrxMT] "communitee steering group, and folk can suggest ways to go about it, or things they care about, if someone can update that list, organisation can be done ad hoc 23:52 MTDiscord well i mean are there people sitting around a lot thinking "i wonder what i could do, i am so lacking someone giving me priorities here"? 23:52 MTDiscord Often it's more like "this all looks so daunting, I think I'll go do something else instead" but the effect is much the same. 23:52 red-001 speaking more on the code side of things, would be nice if someone could get a second review for #15077 or decide it's trivial. It's pretty annoying seeing Visual Studio complain about "security issues" and would require using Windows-only functions to fix. 23:52 ShadowBot https://github.com/minetest/minetest/issues/15077 -- Disable CRT security warnings in MSVC. by red-001 23:53 [MatrxMT] some devs often pick up newest issues, even if they are irrelevent 23:53 [MatrxMT] if there was a nice filter for top bugs, or top issues, it's easier to digest 23:53 red-001 most annoying compiler feature, cmake should have really set the flag by default 23:54 MTDiscord well i guess you'll have to find someone who has windows first :p 23:55 MTDiscord 15077 is trival enough it could be merged under 1 approval policy 23:55 red-001 you can just look at the build output from actions https://github.com/minetest/minetest/actions/runs/10623319320/job/29449510847?pr=15077 @corarona 23:56 MTDiscord if you want to rank things, label + thumbs up does a decent job, isnt perfect though https://github.com/minetest/minetest/issues?q=is%3Aopen+is%3Aissue+label%3ABug+sort%3Areactions-%2B1-desc for example 23:56 MTDiscord As an experiment, we could just invite a bunch of people (like maybe a dozen) pulled from active gamedevs, and allow each one to vote on ONE issue or PR. Then the triage team tallies up the votes and picks some reasonable number of those issues from the top to get some kind of high priority label. Core devs can have their own high priority items based on what is causing them the most trouble. Then we generally agree to at least try 23:56 MTDiscord to work on high priority stuff first, where work is being done. 23:57 [MatrxMT] perhaps more than 1 vote, 3, as most just vote for their own, 3 would probably encourage concensus 23:58 [MatrxMT] 2 of your votes have to be for an issue raised by another project ;) 23:58 MTDiscord Sure, exact number of votes isn't a major factor, though it'd be nice to be able to put multiple votes on a single item. 23:58 MTDiscord can i object to this on grounds that i dont want to do more minetest stuff? /s 23:58 MTDiscord make preferential voting 23:59 [MatrxMT] preferential can be more time consuming to tally than just adding up though 23:59 red-001 select a jury of world citizens and have them decide /j 23:59 MTDiscord The reason why the steering group idea is important and I'm skeptical about just counting 👍 from the community is that there's a difference between "if you complete this item, I have a major feature based on it planned "and "if you complete this item, I bet somebody could do something neat with it someday." Things that have speculative value are cool and all, but things that are actually holding back real development today should 23:59 MTDiscord be first. 23:59 [MatrxMT] yup. we've decided. take your proprietary windows, proprietary ms software, and stay out! :) 23:59 MTDiscord 👍