I would be curious to see the demographic of people who complain about the core devs and engine progress and if they've actually seriously developed or contributed to an open source project... I do not mean to gatekeep anyone having concerns about the project or trying to contribute, but I do think people are missing an important perspective if they have not been in that place but continue to throw flak...
Full disclaimer before I begin this post, I've seen very little of Minetest as of the past 3 years, but have recently taken an interest in it from a hobbyist point of view. But I thought I'd give my perspective on my limited understanding of how things are in the Minetest community and my more recent knowledge as a software engineer.
I see relatively little issue with the way that current Minetest pull requests operate. I think that if you are a one-time contributor or active contributor, you will have to work harder to get your code into the engine. You should have to prove to the developers that you are willing to contribute code that is robust enough to withstand changes or are dedicated enough to make sure that it works across time. If I was given a slightly miswritten code solution and implemented it, there would be repercussions in the future. Whether that be in terms of crashes, future incompatibilities, performance hits, it still will add up in the long run. And while one or two may be fine, Minetest is a project that does have to worry about scale. So erring on the side of caution should not be seen as a bad thing.
As another note, I think that the "good developers" that will put effort into good code continually should be promoted (as desired) to core developers, and from what small anecdotal evidence I've seen, this does happen. And those who put more effort in going from "bad code" to "good code" should have their attempts to open a pull request respected.
This is not to say that core-devs are infallible and write good code and make good decisions all of the time. I would put money on the contrary--that they will write bad code at some points and ignore things that are actually good. I'm sure that not all, or even majority of them are software engineers with industry background in C++ and 3D graphics. But they are the ones that are going to put a majority of the work into fixing problems in the future. And they will make mistakes some times based on how their day is going, what is happening in the rest of their lives, as this is a side project. This is what you get in open source communities.
To address the original post and, I think developer roadmaps would be helpful. Not a laid out waterfall project guideline, but more of an agile development "goalposts" for individual developers. So hopefully Rubenwardy's works are fruitful. I can see that he cares about where all this is going and wants things to get better, so props to him.
Also, Jordach's original comment about code testing really hits home after going through projects that require manual review on huge rewrites. Its a giant headache, and automated unit/acceptance testing is a Godsend in some situations. But I also know it is very hard to retroactively implement those tests, and being the dev that has to write those retroactively implemented tests is something I don't wish on anyone save masochists...
More 'replies':
Spoiler
I have a suggestion.
Let's make a Minetest fork and let's merge all PRs there. Regardless of if it makes sense, regardless of how much buggy it is, regardless of any side effects it will have. And let's see how far we can go.
For the love of everything working, hell no. I get that this is an experiment that sounds intriguing if you've never done it or seen it before, but as someone who has seen projects take this turn, even on a small scale, it never ends well.
------------
This is why we can't have nice things
Incompatible, poor, or heavily personal code is why we can't have nice things. None of us are hiveminds, and getting a project as large as Minetest to a place where people can continue to contribute reasonably without breaking or rewriting each other's code is a massive undertaking.
------------
Forks only work when the project has been long dead and abandoned by the original or main developers. Minetest has not, and will continually outlive radical "forks".
Freeminer was the closest to such an event (like ever, but only managed about a year's life) but eventually the changes from Freeminer got absorbed into the main Minetest branch.
Yep.
Minetest still has a heartbeat, and an immune system that keeps it alive to boot. Even if it may not do as much as it can, at least it doesn't get sick and die.
------------
More hyperbolic ranting?
Lol, Minetest community is passionate and seems to have an affinity for it. I will leave how good of a thing that is to everyone else.