Core/MTG dev(s)

[jas]

Sometimes, it seems, there is one that will disapprove of even the discussion of an idea. It completely derails things before they even happen, as typically the issue or PR author is discouraged from the onset. Or offset, as the case may be.

I feel that that Core/MTG dev(s) should be more careful not to weigh in with (pre-)judgement too early.

[Linuxdirk]

Yes, it’s a pretty tall ivory tower some devs are living in. That doesn’t mean they do bad work, but sometimes they’re a little too disconnected from the player base to make decisions that are fully embraced by the majority of the player base.

… as typically the issue or PR author is discouraged from the onset.

I started fixing things for and by myself via mods where possible because I learned the majority of “user-made” PRs or issues are either talked to death or ignored.

[ThomasMonroe]

I agree that they should at least be a little less, erm how do I put this..harsh?..strict?..narrow-minded?(I do see this sometimes) with their judgements of PR, ideas, etc.

[Aerozoic]

This is a much bigger problem than you all are letting on. I see no reason to protect anyone's feelings. There are so many issues with the core dev team and attitude is probably the biggest. But guess what, they are the core dev team so they get to do what they please.

[rubenwardy]

I'm aware that historically (and still today, although I'd argue less so) the Minetest engine has the issues of code rot and a negative attitude towards new features.

Code Rot

I've been attempting to alleviate code rot by adding labels to ensure that everyone is aware of the state that a PR is in, and personally reviewing and adopting more PRs myself. The solution to code rot is two fold, in my opinion. Old and unmaintained PRs need to be adopted if useful, or closed. New and current PRs need to have affective communication on the state of the PR, and more reviews. Code rot causes contributors to abandon the project, and a large number of PRs causes potential contributors to be scared away - so it's a real problem.

The fact is that I, like many of the other devs, am limited by time. I am a full time university student and the time I spend on Minetest could be spent on studying, other projects that would be worth more to employers, or misc chores. I don't like approving PRs unless I can be mostly sure they don't cause issues, which means I have to spend a lot of time reviewing more complex features. In the last few months I have personally spent hours at a time going through PRs and reviewing, adopting, or rejecting them. I am not paid to contribute to Minetest - no dev afaik is - so I contribute purely for fun and because I want to see the project succeed.

Anyone can easily help us merge more PRs by reviewing and spotting errors. We'll trust your reviews more if we see you spotting lots of errors, rather than correcting code style or just approving. You can also help by comprehensively testing PRs for issues. In terms of development direction, make your opinion known by voting using emoji reactions on PRs and issues, and arguing your case.

Negative attitude

My aim for Minetest, as described in my roadmap is to create a piece of software you can use to make a variety of different voxel-based gaming experiences. By this I mean both classic Minecraft-likes, and more varied games. We've already seen some varied games - CTF, ItB - but not enough. I'd also like Minetest's default install to to come with a fully-playable (without mods!) crafting/survival/mining game. In summary - Minetest's default install should be a fully valid game, but the engine should also be flexible enough to allow a variety of gameplay.

I personally try to compromise between direct community needs/wants (fancy features), and indirect needs/wants (stability, code cleanness). CSM is a colossal fuck up as mentioned elsewhere, however I'm hopeful it'll turn into the client-side scripting that we were promised. This would allow more possibilities such as advanced drawing (HTML5-style canvases) and better entity prediction. See my roadmap for more thoughts on this.

The easiest and best way to achieve this game engine goal is by pushing gameplay functionality into Lua (builtin or mods) in order to increase the chances that the feature and related features are controllable and customisable by mods. This means the the engine exposes callbacks and APIs to give mods control. If a gameplay feature needs to be hard coded in the engine, then it's a sign that the engine may be doing something wrong, and fixing that could allow more possibilities and control by subgames. This is the reason why development is so conservative.

In terms of alleviating the negative reactions to new features, I've tried to encourage core developers to publicly document their goals for the project and their opinion on its development.

[Wuzzy]

In this post I give my random thoughts about Minetest development.

The easiest and best way to achieve this game engine goal is by pushing gameplay functionality into Lua (builtin or mods) in order to increase the chances that the feature and related features are controllable and customisable by mods. This means the the engine exposes callbacks and APIs to give mods control. If a gameplay feature needs to be hard coded in the engine, then it's a sign that the engine may be doing something wrong, and fixing that could allow more possibilities and control by subgames. This is the reason why development is so conservative.

This explains a lot.
And I mostly disagree with the reasoning. While I am not against customization, I don't like the tendency to make the engine dumb on purpose or to intentionally leave out core features. This just seems to be a lazy trick to shift the burden to the modder instead of creating something which is useful and fun for everyone.
I don't think there are some features for which an engine implementation is actually the best possible solution and forcing modders to do it on their own is not always a good idea.
One example is health and breath. These things are so basic and important it does make a lot of sense to have this engine-side. A mod implementation of breath would be too laggy.
Another example for which I think an engine implementation makes a lot of sense would be ambient sounds. We had a lot of attempts to do this in Lua, but they were (unsurprisingly) very inefficient and laggy. Also, engine support would make adding ambient sounds infinitely times simpler, so adoption can happen early.
Don't forget that modders are developers, too. They have a stake and their opinion matters. I think the big feature of Minetest is to be moddable, so it makes only sense to listen to the modders, don't you think?
Note that I have no issues with making an already existing core feature customizable.

There are featues in the API that are implemented in a way that are practically unusable unless you write a lot of boilerplate code.
So in theory you could use awesome feature X, but not without this boilerplate code.
The best example for this are player physics. In theory it's very easy to set the player speed and gravity. But as soon you have two mods which want to do this, you run into conflicts, because each time you set the player speed, Minetest forgets the previous state completely. Minetest is not helping mods at all.
So basically gravity is only actual useful with Lua boilerplate code which makes it useful.
This is bad, for several reasons: First, subgame development time increases, second, redundancy increases, and if there's a bug in the boilerplate code, it has to be fixed in every subgame.
Other examples of annoying-to-use features:
- Sky API. It's the same problem with player physics. Also, the plain sky is pretty useless on its own, as you still have to manually adjust the color for day and night
- Statbars. There's no simple way to just add a few statbars. You have to set every position manually or you use a boilerplate mod like HUD Bars

I hope you get the idea. The API already offers good features, but I think some of them are just painful to actually use.

Suggestion for the future: Whenever you want to implement something big, please hear the community opinion. Especially I feel the opinion of modders and server operators has been too often neglected. Also, some real world tests should be made before a Lua API call is added. So that weird-to-use APIs are avoided in future and implemented properly right from the start.

Priorization of issues is completely messed up.
What I mean with this is that MT has important bugs which are ignored and not fixed for years while unimportant issues get fixed much faster.

For example, that players are immortal while attached: https://github.com/minetest/minetest/issues/4484
Or that spawning an entity is like winning the lottery: https://github.com/minetest/minetest/issues/4759
Or that depth sorting is broken. https://github.com/minetest/minetest/issues/95
Or that Android users can't sprint (not “Use” key available).
Or that the player physics for Android users is different, giving them an unfair advantage.
Or the subgame banner is sometimes invisible on widescreen. https://github.com/minetest/minetest/issues/2262
Or that formspec coordinates are so weird, they're almost useless (issue 3872)
None of these issues are considered high priority for some reason.

I believe this is probably because there are so many issues, many developers actually have lost track of what's actually important. I don't blame them. I think this is mostly GitHub's fault.

GitHub issues suck.
Frankly, I think GitHub's bug tracker sucks. The sorting and filtering options are just a pain and I hate the crappy label system. GitHub automatically sorts issues by date which is mistake number 1: Important issues get pushed down the rabbit hole very soon and become invisible.
You can't just sort by priority or severity which is very important IMO. ESPECIALLY if you have >700 issues! The only priorization which exists are two labels: “high priority” / “low priority”. And the high priority label is only used for the ultra-important issues. Important (but not ultra important) issues disappear in a sea of issues without any priority labels.
Developers are concerned about the large number of issues and I fully understand this. But they seriously started in mass-closing issues because they apparently find it hard to navigate. Sorry, but this is dumb. What you actually want is proper filtering.
It's not a problem that MT has a lot of issues, the actual problem is that they are very hard to navigate and even harder to sort by priority. Closing just for workload reasons is a bad idea even for suggestions. The reason is that the ideas won't go away if you just close them. Suggestions should be rated (mostly) on their merit. Also, the bug tracker is not just for you, but also for potential outside contributors, don't forget this!
Suggestion: Consider moving to a bug tracker which does not suck. Use at least 4 priority levels and explain each level in words. Sort by priority by default instead of date.

Another big community problem I see is that a lot of PRs are left to die. This is more a social problem. If you spend a lot of time in doing 3 PR and all 3 of them are ignored for weeks, this can be extremely bad for morale. It's no surprise that authors eventually disappear.
Core developers are always complaining about lack of “dev time” but if someone actually wants to contribute it's usually very hard to get it accepted.
Rubenwardy already is spot-on with the technical problem with ignoring PRs for too long: The longer you wait with merging, the harder it will be to merge them. This is both more work for the merger and for the author at the end.
Another related and frustrating thing is “rebase needed”. This label appears WAY too often and scares more contributors away.
Suggestion: Maybe PRs should be given a priority rating just like normal issues. Maybe also a rating for complexity. A high priority means it fixes an important bug or just should be merged in fast.
Complexity is used for the rough amount of code it touches and the likelihood it attracts conflicts over time. Big PRs are generally complex ones.
So a high complexity or priority rating means that it should have higher dev attention than other PRs. Ideally, those PRs should be dealt with *first* so merging becomes less painful.
On the other hand, with low complexity PRs it's unlikely to attract a lot of difficult conflicts over time so they can wait.

Another thing which can stop in GitHub right now are absurdly long discussions about every minor unimportant detail. It's really annoying if serious dev discussions get derailed about whether the sentence should have a comma or not. Yes, even if there is a typo, that's mostly not the point of the issue. I think we all are a bit guilty of this. xD
Suggestion: Just stop the spam. xD

Bugs get lost in the forums!
I think a lot of devs are unaware of this, but currently, a lot of bugs get lost in the forums, because right now, we have a subforum called “Bugs and Problems” while it is clearly NOT intended for bug reports! Unsurprisingly, players continue to report bugs here instead of GitHub. This is not good.
viewforum.php?f=6
IMO this forum should be renamed to just “Problems” or “Support”.

About Minetest Game: I have given up on this subgame and mostly ignore it now. It is heading nowhere for years and still has no clear agreed-upon goal. This isn't even the problem. The problem is that it is still the default subgame while it clearly does not deserve this position. The problem is that we don't ship a good and complete (!) game by default. I'm actually not against MTG, it still has a legit use case. If you like to add a lot of mods, that is. But this is not the kind of subgame you should give to complete newbies.

Final notes
I complain a lot of many things, but I'm not your enemy. xD
Actually, I think that overall, Minetest is heading to the right direction and overall, good progress has been made.
Issues will be continued to get fixed over time. Awesome features will continue to be added. It just takes more time. The past Minetest releases have never been a disappointment to me.
CSM was a fail, but thankfully it's optional (so I can ignore it) and devs accept it as a fail.
So I think the community should be more involved in major decisions in the future.
Although people complain about lack of contributors, I think there are actually a lot of contributors already. The biggest hurdle in Minetest currently might not be manpower, but organization. We're just not really well organized yet and it's not always clear what everyone wants. Maybe it really just boils down to communication, who knows?
If we just manage to organize ourselves and the resources we already have better, I predict Minetest development would advance to a whole new level.

[TumeniNodes]

As far as issue/bug tracking
I have suggested using LaunchPad a couple times in similar threads
https://en.wikipedia.org/wiki/Launchpad_(website)

a quick edit here though:
I was reading the recent move of InkScape from LaunchPad, to GitLab so... now I am uncertain.
https://inkscape.org/en/news/2017/06/10 ... es-gitlab/

[burli]

I think, one big problem is, that the code base from the engine is too monolithic. It is hard to change fundamental things. Even if the game itself works, the code is broken to its base and too hard to maintain

I just fly over the bug filter and found a lot of bugs related to collision detection. I think it would be necessary to rewrite the whole thing instead of trying to fix each single bug within the current code. But who want's to touch that? Who has the time and the knowledge?

A lot of issues can be grouped, for example lightning, collision detection, HUD, liquids and so on. Instead of patching each single issue it might make more sense to rewrite a larger chunk of code or even everything from scratch

What's a real problem are PR's waiting for weeks or even month until they are merged, if at all. You have to spend more time to rebase than for writing the PR itself. Even though I understand that the developers don't have a lot of time to review and test each PR, this scares of a lot of good people.

Another thing is, that the devs have to many concerns about performance and backward compatibility, but a lot of suggestions don't add much CPU time and sometimes you need to cut off old braids to be able to make progress.

I don't think, the Github issue tracker is a real problem if you know how to use it. But I don't know how to sort by priority. Who decides what's the priority of the issue? Sort by reactions?

Contributing to MTG is like riding a dead horse. It doesn't makes sense anymore. But a problem is, that the development of MT and MTG goes hand in hand. Only what is needed for MTG is added to the engine. I would completely stop the development of MTG and start with more something useful.

[Linuxdirk]

But a problem is, that the development of MT and MTG goes hand in hand.

Yes, that is the biggest problem MT development has. MTG and MT should be separated completely. MTG isn’t a good subgame at all and it does not even serve as reference implementation because it leaves out too many features. Even worse: It provides things other subgames use.

MT in general should be waaaaaay more modular.

[ThomasMonroe]

MT in general should be waaaaaay more modular.

+1 I agree wholeheartedly

[void]

GitHub issues suck.
Frankly, I think GitHub's bug tracker sucks. The sorting and filtering options are just a pain and I hate the crappy label system. GitHub automatically sorts issues by date which is mistake number 1: Important issues get pushed down the rabbit hole very soon and become invisible.
You can't just sort by priority or severity which is very important IMO. ESPECIALLY if you have >700 issues! The only priorization which exists are two labels: “high priority” / “low priority”. And the high priority label is only used for the ultra-important issues. Important (but not ultra important) issues disappear in a sea of issues without any priority labels.

This is not a GitHub fault.
The real problem is that milestones are not declared. Is really easy, put important updates as milestones for X release and X release will not be published until all the milestone are completed.

The real problem is that the dev core members are are always elusive regarding PR and issues, they discuss about them but they really don't say if they want or not add this feature and when.
Please, add milestone and respect them and lots of problems will be solved

[Shara]

Only what is needed for MTG is added to the engine.

#6792 (ability for subgames to restrict available mapgens) is proof against this. It was specifically added to support subgames other than MTG. I explained the case for it to several developers, made the PR, worked with them on requested changes, and then it was approved quite quickly.

I've found a lot comes down to how you approach PRs and how well you explain them. Many of the devs don't have much freetime, and despite it being repeated quite frequently, not many people actually seem to appreciate that they are volunteers with many other responsibilities outside Minetest. If you want a PR accepted with minimal fuss, it's a two way process and contributors should also make it as easy for the devs as possible.

This doesn't mean there are not any problems - I see a large number of issues that could be fixed - but let's not apply criticism where it isn't as justified.

A more constructive thing to do regarding PRs would be to look at why certain PRs get left for a long time, and to see if any guidance can be put in place, or other changes made, to try and reduce the delays. Simply stating there is a problem doesn't fix it, and solutions need to be realistic ones.

The same is true for the issue of MTG being the only official subgame. We know it's an issue, but it needs a solution that can actually work. A good alternative subgame needs support from a well structured team and clearly needs to meet certain quality standards, and I don't see many (if any) examples of this which could be considered.

[paramat]

Sometimes, it seems, there is one that will disapprove of even the discussion of an idea. It completely derails things before they even happen, as typically the issue or PR author is discouraged from the onset. Or offset, as the case may be.

I feel that that Core/MTG dev(s) should be more careful not to weigh in with (pre-)judgement too early.

No devs disapprove of discussion, they personally may not want to discuss something, or disagree with the PR or idea, but that is different. Threads can be posted in freely even if closed, they are very rarely locked.
Any examples?

[paramat]

The real problem is that milestones are not declared. Is really easy, put important updates as milestones for X release and X release will not be published until all the milestone are completed.

The real problem is that the dev core members are are always elusive regarding PR and issues, they discuss about them but they really don't say if they want or not add this feature and when.
Please, add milestone and respect them and lots of problems will be solved

We have and use milestones on Github as you describe, they tend to be used heavily when coming up to a release. We also have the blocker label.
We are not elusive, we state our opinions fairly forthrightly and approve or disapprove PRs.

[paramat]

Only what is needed for MTG is added to the engine.

No. Engine development actually seems quite distant from MTG, and ahead of it. Features are added well before MTG figures out if or how to use them, and some features we choose to not use in MTG.

[ThomasMonroe]

Guys, if an idea gets "shot down" its usually because it has already been talked about many times before.