Minetest Forums

Linuxdirk wrote: ↑

Mon Oct 19, 2020 14:18

That’s how a meritocracy works. You’re not selected as core artist and then do the work, you first do the work and then get selected as core artist because of what you did before.

If this is about me specifically, I think I proved enough, but ok. And no, to be clear I'm not asking for any core role, already been there.

Linuxdirk wrote: ↑

Mon Oct 19, 2020 14:18

Zughy wrote: ↑

Mon Oct 19, 2020 13:41

On 968 current issues, 959 are unassigned.

Basically because they’re all volunteers and no-one can just assign something to them.

But they can self-assign them, yet they don't. Back to the Africa example

Zughy wrote: ↑

Mon Oct 19, 2020 13:14

There is already the "assign" function for that, the problem is that is not respected. See here

Yep, and only core devs can assign themselves. There should also be a normal way for contributors

Zughy wrote: ↑

Mon Oct 19, 2020 13:14

Uhm, I don't think it's a good approach: I mean, if something is simply bad for the project, ok, let's close this, but if something is doable and no core dev has the interest to do it, I think it's fine to leave them there just in case someone else wants to take care of it. The important thing is stating the approval, a thing they could already do with the supported by core dev tag

Sure, we shouldn't close undone Issues with great Ideas!
I don't mean close if it nobody does it, I mean close it if the core devs wouldn't like it if anybody will do that.
And the supported by core dev tag is way to less used! There should be a standard way to look on issues

Linuxdirk wrote: ↑

Mon Oct 19, 2020 13:17

PR reviews could be made faster by auto-linting it stead of playing ping-pong with the contributor figuratively one code line after another with a 2-3 days to weeks delay between each review. Not sure if Microsoft offers that on their GitHub platform but this should be part of every DevOps loop (either after plan or in code).

Yep, I agree.
That's just the thing that there are no clear "rules" how to handle Issues or PRs
I also have almost or not reviewed PRs where all checks passed. Just have a look on my currently open ones.
But I think the even more important thing is to not half review PRs but working through them in a queue.

Zughy wrote: ↑

Mon Oct 19, 2020 14:52

If this is about me specifically, I think I proved enough, but ok.

No it’s not, don’t worry. Enough is, what current core devs think is enough, I guess.

Zughy wrote: ↑

Mon Oct 19, 2020 14:52

Linuxdirk wrote: ↑

Mon Oct 19, 2020 14:18

Basically because they’re all volunteers and no-one can just assign something to them.

But they can self-assign them, yet they don't. Back to the Africa example

I prefer the volunteer fire department example: People volunteered to join them and if there is an emergency they simply can’t say “nah, now I’m not doing it because I am a volunteer and I decide what I do and when I do it”. So when you volunteer as a developer: same thing (slightly). You either do dev work when it’s needed, or you stop doing it altogether. It’s simple as that. But playing the “I aM a vOLuntEer” card every time there is work to do is just the wrong way. No mater how stupid the analogies are.

When it comes to creating features, I already have a full roadmap in place for what I want to work on. I have no problem with that whatsoever. I think that the real problem is I don't know where to focus when it comes to reviewing PRs. It's basically a find something that looks interesting and review it system. As a result, I don't especially feel like reviewing anything. What I really want to know is what to review. Maybe a queue for PRs that I should review (not made by me for myself, but by someone else) or something along those lines.

Secondly, I really wish that GitHub had a separate Issues and Feature Request sections. That would simplify things greatly and make bug reports vs feature requests much easier to find. The "Feature Request" and "(Unconfirmed) Bug" labels don't really organize it well enough. If anyone know a way to practically separate these, I would love to know how.

Linuxdirk wrote: ↑

Mon Oct 19, 2020 13:17

formspecs (which will never look great, either)

Please don't say that, it's simply not true. Basically the whole reason I became a core developer is to make them better, and a lot of progress is being made on a replacement. Just because I don't advertise it on Discord or display it on the forums doesn't mean it's not happening, just that it's not yet in a presentable state. I don't want to get false hopes up or to show something off too early.

(OK, actually that statement might be kind of true -- formspecs will never be good, but the GUI replacement will :) )

All this is great but what can be done? What can we change? Devs: do you see this? Do you have any ideas? I think that a dev blog and dividing up 'core devs' into smaller chunks (like PR reviewers and UX designers and such) is a good idea. It would also be great to see some sort of roadmap so it's easier to see what the devs are doing without the hassle of reading commit logs. Edit: I started writing this befroe seeing v-rob's post

v-rob wrote: ↑

Mon Oct 19, 2020 16:59

When it comes to creating features, I already have a full roadmap in place for what I want to work on. I have no problem with that whatsoever. I think that the real problem is I don't know where to focus when it comes to reviewing PRs. It's basically a find something that looks interesting and review it system. As a result, I don't especially feel like reviewing anything. What I really want to know is what to review. Maybe a queue for PRs that I should review (not made by me for myself, but by someone else) or something along those lines.

I totally agree,
that's why I think a clear order is needed by using tags or whatever. The current state is just a mess of never reviewed, partly reviewed and PRs which will never get merged. That's just not effective. The core devs should be more strict with decisions on PRs but also with reviewing if an idea of a PR is good.
But honestly I'm sometimes not sure if the core devs really want to change something...

Lejo wrote: ↑

Mon Oct 19, 2020 18:51

But honestly I'm sometimes not sure if the core devs really want to change something...

Ruben wants, v-rob wants, others don't. They're the only ones taking part to these topics, and I saw you linking this one in the IRC, and how they didn't consider you at all. Welcome aboard

v-rob wrote: ↑

Mon Oct 19, 2020 16:59

It's basically a find something that looks interesting and review it system.

So the older a PR gets the less interesting it is?

v-rob wrote: ↑

Mon Oct 19, 2020 16:59

Maybe a queue for PRs that I should review (not made by me for myself, but by someone else) or something along those lines.

Here’s a task: Order the PR lists by age (descending) and start on top. Review the first 10 PRs :)

v-rob wrote: ↑

Mon Oct 19, 2020 16:59

Linuxdirk wrote: ↑

Mon Oct 19, 2020 13:17

formspecs (which will never look great, either)

Please don't say that, it's simply not true.

It is, unfortunately. A lot of awesome work was done, and formspecs are now a lot more consistent than before and are easier to style (no weird 3 decimals anymore! I just love it!). Still some imperfections and weird things (i.e. labels are measured from their center and not from ther top left corner like everything else, or – also labels: a newline being optically two newlines instead of one newline. But those are minor things) but overall much better.

Except styleability and overall look and feel. It just looks like wireframing on LSD and is far away from being polished - at all! Even when used the weird element styling or 9-sliced backgrounds. Where are the percentages? Where are the viewport-based units? Where are SVG elements? Where is the flexibility (i.e. dynamic elements instead of re-sending the whole thing on every change).

Not having those are fundamental design flaws. It might have been okay nearly a decade ago in an early beta version, but not in 2020 for a game in a 5.x version.

v-rob wrote: ↑

Mon Oct 19, 2020 16:59

formspecs will never be good, but the GUI replacement will :) )

Anything replacing formspecs will automatically be better :)

Linuxdirk wrote: ↑

Mon Oct 19, 2020 20:39

So the older a PR gets the less interesting it is?

No, just less likely to be found.

Linuxdirk wrote: ↑

Mon Oct 19, 2020 20:39

Here’s a task: Order the PR lists by age (descending) and start on top. Review the first 10 PRs :)

The unfortunate thing is that most of those first 10 are in areas of the engine that I know nothing about. A queue would make things a lot simpler. Another problem is when to review. Since I'm working a lot on a formspec replacement, I don't want to review any formspec PRs (which are some of the few I can review) because it will all be replaced anyway and increase the compatibility layer that will need to be made, and searching through the large list of PRs to find ones I am able to review is exhausting. If there was a queue based partly on my opinion, partly on another person's, it would just be to work through those one at a time, no problem.

Anyway, formspecs definitely are bad currently, I'll be the first to admit; I was just saying that "(which will never look great, either)" (emphasis mine) is not true. I'm trying to say that, in the future, they most certainly will.

Linuxdirk wrote: ↑

Mon Oct 19, 2020 20:39

v-rob wrote: ↑

Mon Oct 19, 2020 16:59

formspecs will never be good, but the GUI replacement will :) )

Anything replacing formspecs will automatically be better :)

Have a look at viewtopic.php?p=382529#p382529 and the new linked draft PR I've been working on. That is what I hope is the future.