New project managment proposal

[Big_Caballito]

Hello all,
In light of viewtopic.php?f=3&t=25417, and seeing the need for a better organization system, I took it upon myself to try to create one. This is in no way final, I simply wanted to see what everyone thought.

IDK who the Project manager would be, but they should be the "strong leader" that Minetest needs.
Thoughts?

[rubenwardy]

It doesn't make sense to separate core development and PR review, as the core dev team's main responsibility is to review pull requests. Any contributor can do programming/development, being able to approve and merge pull requests is what sets a dev apart from a contributor. (Core devs do also happen to be major contributors, simply because they're selected that way.)

There's already a separate website team, it consists of Calinou and me. I was on the website team before I became a core dev.

Project management needs to be defined better - it's not clear exactly how that role is supposed to work

[Big_Caballito]

Okay, scratch separation of PR team and core devs, Project Manager would be someone who would help keep everyone organized, they would have the authority of Core devs without having the responsibility of doing any coding. If they saw a major problem (like 1,000 issues), they would help to prioritize things, and just generally be a good leader.
And yes, I am aware that this is a hobby for (most) everyone involved, I am not saying they would be A Boss, that wouldn't be fun, they would simply help everyone keep priorities straight.

[parasite]

Project Manager would be someone who would help keep everyone organized, they would have the authority of Core devs without having the responsibility of doing any coding. If they saw a major problem (like 1,000 issues), they would help to prioritize things, and just generally be a good leader.

Do you see the role of Project Manager (PM) more like coach or manager? If the latter, such person must be higher in the hierarchy and be able to suspend or exclude someone who is causing problems from the team (temporaly or in a given task). (and not just politely suggest, tag posts or resolve disputes through proper discussion or questions on IRC)

From your schem above, PM is supposed to lead 3 teams: website, art and PR review. This would mean that PM is not above core devs in the hierarchy, the core devs are not automatically in the PR rev team and might be a situation when some core devs are not in the PR rev team. For example PM suspended or excluded someone from the PR rev team. E.g. someone who takes a long time to perform their duties or creates other problems. Such a core dev suspended in PR rev process could simply focus on coding or other tasks for some time. And PM - while is on the same hierarchy level - has no power to exclude anyone from beeing core dev, I mean PM could just assign other task. Is it that what you try to propose?

It doesn't make sense to separate core development and PR review, as the core dev team's main responsibility is to review pull requests.

Apparently so, but someonoe could say that the recent statements on the forum prove that the core team failed in this key role. Maybe something would have to be changed? But what?

[eyekay]

1. AFAIK Minetest Game is under feature freeze and soon it will be removed as the default game as well. I don't see what an art team will do that can't be done by the 'request a texture' thread
2. Core devs and PM shouldn't be at the same level, PM should should be above core devs too

And what's marketing?

[Zughy]

Aside the already discussed PR/core dev thing, let's cut the chase: If we're considering a PM guy/gal, which is basically asking for a new leader, who exactly should it be?
What my topic stated is how core devs weren't able to manage the community or simply the code, so what makes you think one of them would be actually able to manage the whole project all on his/her own? If anyone of them had been actually able to do that, we'd have noticed it already. Also, being a PM also means having a 360° vision: again, nobody kind of played Minecraft, meaning they don't know what happens outside of MT, which yes, it is crucial, which then I find pretty self-explanatory.

Or are you considering someone from the outside? In that case, I don't think they'll approve.


------------- EDIT after a couple hours

Giving a better thought about it, a solution to the problem might be having separate working groups, where each group is managed by one person. For example, core devs are managed by the dev TinkyWinky: TinkyWinky draws the general lines of development, considering both the other core devs and the community. That also means core devs are beneath TinkyWinky. Then there is the website crew, managed by Dipsy. Then the design crew, managed by Lala, and the advertising crew, managed by Po. They then communicate altogether, but at the same time everyone focuses on their areas.

This means several things:

• a core dev authority is now limited to their sector: e.g. if Lala opts for a sound system a core dev doesn't want, the final decision is up to Lala
• better management and less stiffness: this would avoid situations like the current one, where celeron55 pops out once in a while and if someone's not happy with it, there's basically nothing they can do, because it all depends on him. In other words, if you're not satisfied with Lala, there's a higher possibility to have her (?) replaced, and no central authority able to pull every string would exist
• less stress for core devs, which now are more like core everything

[Linuxdirk]

Giving a better thought about it, a solution to the problem might be having separate working groups, where each group is managed by one person.

Why the hell is everyone thinking about management first? Devs first! This will simply not work at all in a small team like the Minetest core dev team. Core devs also not hired because of management but because of contribution. None of them is a manager but all of them are developers.

The only thing I could think of are smaller projects, i.e. clearing up the nearly 1000 issues dating back up do 9 years. Form a project team of 4-5 core devs stopping all other development activities for 1 or 2 weeks and only handling the issues, going from oldest to newest. Same with the nearly 140 PRs. Go through them, aggressively close outdated ones. When both are in the low 2-digit range then disband the team and continue normal development.

a core dev authority is now limited to their sector

Who defines who’s in what sector? The creepy baby face in the sun? What happens if there are all devs in one sector because that is what they desire most? No-one will work in the other sectors.

less stress for core devs[/b], which now are more like core everything

You mean except having another layer of complexity added in communication?

You simply can’t handle real-life development teams with business administration theories you learn at universities. All teams I worked in having this nonsense forced on them (usually by freshman managers coming right from university) hated it and bureaucracy basically exceeded productivity.

[Kezi]

It was a mistake from the beginning to talk about management, that won't work and has never worked

Dividing work in groups is not about management, and groups don't need to be managed by one person, groups are useful when there's sufficient specialization, for example, engine devs vs UI designers and artists

KDE's VDG is exactly this, designers and artists have their own working group that's somewhat independent, graphical and UX changes go to the VDG's review, then the technical one, technical changes go directly to the core maintainers

This issue is more important in something like a game / game engine where everything is done to look good, obviously it's an act of balance, but it somewhat became clear in recent times that graphical or gameplay related things should not be but in the hands of c++ programmers

[Zughy]

Why the hell is everyone thinking about management first? Devs first!

Yes, and we know how well it worked so far. Quoting rubenwardy: "I'm not happy about the progress and the management".

Who defines who’s in what sector?

Their role? I didn't say to split up programming in 5 different parts, I said to split the aspects of MT in separate areas. Why exactly a core dev who knows nothing about graphics and who probably is not interested a bit should decide about it? And yes, I'm using graphics as an example because the current one is horrible and people do want a new design. I don't think it's hard to distinguish an artistic task from an advertising or coding one. In-betweens do exist but I think everyone here is also smart enough to manage them.

less stress for core devs[/b], which now are more like core everything

You mean except having another layer of complexity added in communication?

What, why? It's simply not their responsibility anymore, how should this be more complex? They can still take part to whatever they want, but if it's not coding they'll be considered as normal users.

and groups don't need to be managed by one person

It could be interesting to know how Godot and Veloren are doing with leaders and management though. I'm not saying this to provoke, it's a genuine thought. Like, is this related to their success or it's not relevant at all?

[Linuxdirk]

I said to split the aspects of MT in separate areas.

Then you end up with one or two areas having all the devs and the majority of areas have no devs.

I don't think it's hard to distinguish an artistic task from an advertising or coding one. In-betweens do exist but I think everyone here is also smart enough to manage them.

The dev team has no artist in it, otherwise we already had an art-style and not only “developer graphics”.

[Zughy]

I said to split the aspects of MT in separate areas.

Then you end up with one or two areas having all the devs and the majority of areas have no devs.

Wait wait wait, I think there is a misunderstanding. Advertising, design, website, they don't involve core devs at all. The point is having a separate team for each one of these tasks.

The dev team has no artist in it, otherwise we already had an art-style and not only “developer graphics”.

And that's exactly what I've been suggesting. Core devs would benefit to delegate things outside of their field to other people, because they'd know that thing is not up to them anymore. It means they wouldn't have to bother, as that thought on the back of their heads saying "you should do that too" would disappear. And yes, those thoughts weight. For instance, rubenwardy not only is a core dev, but he's also the guy behind social accounts and (along with Calinou) behind the website. He said he already has no time to manage development as much as he'd like, how exactly is he supposed to manage all these three things together? Do we want to play Russian roulette with burnouts and/or quitting?

At this point you could say "but people can already help, no matter what", but here's the catch: currently these people are considered just as mere contributors, people beneath core devs. And I don't think that's fair, because 1) these things matter as much as code 2) it still requires core devs approval, meaning they still have to spend time evaluating whatever suggestion, and 3) that would mean core devs have an insane range of expertise in fields detached from coding, which as we can currently see is simply not true.

What I'm saying is, these people should be elected by the current staff, but when they are indeed elected, they'll by no means inferior to any core dev when it comes down to their expertise field. Meaning, if JohnDoe is a core artist and core artists decided to go for this new main menu, core devs can't say "no we don't like it, redo that", exactly like core artists can't say "no, we don't like this algorithm, redo that". This is called trusting people.

So will this resolve PRs and issues bottlenecks? I don't think so, but it'll lighten up the burden. It'll give new people the ability to express theirselves, it'll make Minetest more vibrant ("is code stuck? ...heh. But hey, the advertising team posted the monthly blog, and it looks like their redesigning the menu. Looks pretty cool!") and it'll open up to more possible contributors/future core "something".

[Linuxdirk]

Wait wait wait, I think there is a misunderstanding. Advertising, design, website, they don't involve core devs at all. The point is having a separate team for each one of these tasks.

So you create teams where there are no members for?

Core devs would benefit to delegate things outside of their field to other people, because they'd know that thing is not up to them anymore.

But who are they delegating to? Will you hire an artist or an advertising expert?

if JohnDoe is a core artist and core artists decided to go for this new main menu, core devs can't say "no we don't like it, redo that", exactly like core artists can't say "no, we don't like this algorithm, redo that". This is called trusting people.

That’s called turf battle. No-one would benefit from such a style of management in real world. Been there several times in different companies. Productivity spiraled down while rivalry/dismissiveness raised, basically ending up with “it’s in their scope, I don’t care nor do I provide any necessary information to them” every damn time.

So will this resolve PRs and issues bottlenecks?

It will make the situation even worse because over time teams stop communicating with eachother.

("is code stuck? ...heh. But hey, the advertising team posted the monthly blog, and it looks like their redesigning the menu. Looks pretty cool!")

(“Shit, code is stuck, but that advertising weirdos promised something that simply is not there and it all falls back on us, screw them!”)

[Zughy]

But who are they delegating to? Will you hire an artist or an advertising expert?

I'm literally a professional artist and I'm pretty sure there are other people willing to help. I've stumbled upon Minetest, I'm not the first and I won't probably be the last.

It will make the situation even worse because over time teams stop communicating with eachother.

Oh, so you mean exactly like the current situation between community and the majority of core devs, because of the latter?

(“Shit, code is stuck, but that advertising weirdos promised something that simply is not there and it all falls back on us, screw them!”)

I'm sorry but this is nihilistic AND disrespecting to whom would like to help somehow. Especially because you need to do a mock-up before putting a menu into code, so that's exactly the thing you want to talk about in some sort of newsletter. More people will evaluate that and if enough people are enthusiastic about it, even if core devs don't have time to develop it, I'm pretty sure some contributor will. Spreading the news is important as much as coding, I don't think you'd be happy if someone called you weirdo.

[Linuxdirk]

It will make the situation even worse because over time teams stop communicating with eachother.

Oh, so you mean exactly like the current situation between community and the majority of core devs, because of the latter?

Yes, and now imagine single teams not communicating with each other. This is exactly what happens if you slap business administration nonsense on real-life situations.

Minetest is a meritocracy. You cannot simply change this by defending an organigram.

Especially because you need to do a mock-up before putting a menu into code,

Yes. And this mock-up should not be put in an advertising blog. It’s something devs and a graphics artist or UI designer work on. If THEY decide to release it, then it can be put online for advertising purposes. Not the other way round.

More people will evaluate that and if enough people are enthusiastic about it, even if core devs don't have time to develop it, I'm pretty sure some contributor will.

So you say, advertising people should not only lie about the current state of the project but also enforce devs to code a specific thing or hope that external people will randomly join out of a sudden and go through month long discussions and stupid code reviews and linting (that should better be done automatically) just because they saw the fantasies of advertising people in an an advertising blog? Sorry, but this is delusional and will horribly crash everything.

Spreading the news is important as much as coding,

Only do the advertising if you can be entirely sure that the thing you advertise is ready for release when advertising it.

I don't think you'd be happy if someone called you weirdo.

If I advertise features that are not in the product I AM a weirdo and deserve being called one.

[Big_Caballito]

parasite: I see the PM as more of a coach, who looks at the team as a whole, then makes suggestions to the sub-teams.
LinuxDirk: I would like to know what you think should happen instead of my idea. I think that we can both agree that something needs to change and I would like to hear your ideas.
Hopefully we (The Minetest Community) can civilly bring about the change that needs to happen.

[eyekay]

@rubenwardy: I'm not saying that the website needs much improvement, but won't it be better if your work is reduced? I sometimes worry upon the fact that you are incharge of almost everything related to MT: not that you have too much power, but that you have to many responsibilities.

So, here is my probably stupid suggestion made while not being funny awake yet, sorry:
1. Criteria for core devs changed to 'professional-level skills in, well, anything which Minetest needs help in'
2. More core devs
3. They can focus on what they like to do on Minetest, instead of something they don't have particular interest in, preventing/ reducing stress
4. ???
5. Profit

[Zughy]

Yes, and now imagine single teams not communicating with each other. This is exactly what happens if you slap business administration nonsense on real-life situations.

But then I wonder: how exactly Veloren is able to do that?

And this mock-up should not be put in an advertising blog. It’s something devs and a graphics artist or UI designer work on. If THEY decide to release it, then it can be put online for advertising purposes. Not the other way round.

What exactly happened to "everything is public"? Where's the difference between someone doing it unofficially and someone doing it officially? Also, see below

So you say, advertising people should not only lie about the current state of the project but also enforce devs to code a specific thing or hope that external people will randomly join out of a sudden.

First of all, why is that lying? You're not making people fantasise about anything, you're showing them what it exists already. If there is a core artists team and they do come up with a mock-up, that's real, it's not a lie. A blog shouldn't be about illuding people, it's about converting the unnoticed work of whoever contributed to the project into a language people can easily understand without skimming every time through technical discussions on GitHub, forum, IRC and/or Discord. Minetest need players too, and a lot of players don't care about technicalities.
Secondly, yes, that's exactly the problem: it looks like core devs need to be extremely spoonfed with a request before even considering it. Someone is not angry enough? Yeah, let's just don't bother and let's put it in our "denial" box. Because you know, it's volunteer work (but can you imagine someone bringing food to idk Africa, who forgot the food and then says "well, you can't expect that much, I'm a volunteer; at least I'm here!" ?). A blog is probably the best shot to put enough pressure to whatever team that doesn't want to change a system which is causing troubles, while at the same time bringing new people in here. Look at how many content creators Minecraft have. And on the contrary, look at what's happening here. What these days taught us is how stomping feet together is apparently the only way to be noticed, which is incredibly sad. So either we keep living in this frustrating environment, or we try doing something about it, when it's obvious core devs don't. I mean, there is still the fork option so we can forget about this nonsense, but how many people would like to proceed that way? I don't think it's that doable

[Linuxdirk]

how exactly Veloren is able to do that?

I have no clue and I don’t care. Ask them if you’re interested. I guess because their team is larger due to having a much more polished game and thus a larger user base and that attracts more devs?

You're not making people fantasise about anything, you're showing them what it exists already.

You worded that different. If you show the current state of the development version it’s fine,I guess.

Minetest need players too, and a lot of players don't care about technicalities.

So, why should those players care about a dev blog?

it looks like core devs need to be extremely spoonfed with a request before even considering it. […] A blog is probably the best shot to put enough pressure to whatever team that doesn't want to change a system which is causing troubles,

No. A blog somehow “forcing” devs to do something ends up the devs hating whoever runs the blog and not doing anything just because.

So either we keep living in this frustrating environment, or we try doing something about it, when it's obvious core devs don't.

So you mean instead of working with the devs you want to enforce stupid business administration nonsense on them?

[Lejo]

Guys...

I don't think this topic should be about who is in charge and who not.
I think it should fix the main Problem of a too slow review process.
The management should just make clear who is responsible for reviewing what.
The new content is a other thing as we currently can't handle the amount of contributions.
Nobody should be forced to create something new. We only need a clear review system (with or without teams)!

We just need to do something, maybe stuff tagging like nextcloud does:
Tagging if a Issues Idea is accepted(to develop) IMPORTANT to prevent useless PRs
Maybe also add developing tag to prevent two people working on the same problem
Otherwise close issue!!!
Tagging if a PR works and code style is correct -> to review

This is only a very inaccurate idea but there needs to be a system

[Zughy]

I have no clue and I don’t care. Ask them if you’re interested.

Tadaa

If you show the current state of the development version it’s fine,I guess.

Yeyyy, we agree one something ahahah I'm glad about it

So, why should those players care about a dev blog?

Judge it yourself: imho that's interesting no matter if you're a dev or not.

Tagging if a Issues Idea is accepted(to develop)

That's already been done, it's "Supported by core dev", but as you can see Paramat is the only one placing that tag. And not because he's the only one entitled to, but because others don't.

So here we are, back to square one: core devs mindset, the thing we can't fix.

[Lejo]

Tagging if a Issues Idea is accepted(to develop)

That's already been done, it's "Supported by core dev", but as you can see Paramat is the only one placing that tag. And not because he's the only one entitled to, but because others don't.

Yep, but the important part is that you accept the idea and so also a working PR for it.
We don't want the discussion on the PR side it should be on the issue side, to prevent useless PRs

And maybe even more important: Close Issues with unwanted ideas to make clear nobody works on this.

We need clear decision if an feature is accepted than it's also clear if a PR is accepted.

[Zughy]

Yep, but the important part is that you accept the idea and so also a working PR for it.

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

And maybe even more important: Close Issues with unwanted ideas to make clear nobody works on this.

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

[Linuxdirk]

The new content is a other thing as we currently can't handle the amount of contributions.

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).

Tadaa

So they don’t relly have any type of management and everyone can contribute to anything. Like it’s currently is in Minetest. They also handle special interests or expertise in a meritocratic way like it’s currently done in Minetest.

Judge it yourself: imho that's interesting no matter if you're a dev or not.

Since Minetest is an engine and not a game (this is what Minetest Game was for before it was degraded to “one of many games” instead of being the default game – which is a good first step in the right direction in my opinion) there is nothing visual to show except the main menu (which will never look great with the technology we have right now) and the formspecs (which will never look great, either) or real lighting (which has basic support in Irrlicht since ~10 years but was never developed any further since then and is not used at all in Minetest).

It could be something like this: https://godotengine.org/devblog … The only problem I see is that this blog has likely more articles in the last 3 months than Minetest had non-minor releases in the last 3 years.

So what to report about in a Minetest dev blog? After going back in the commit history for around 6 pages I don’t find anything worthy of a blog article.

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.

This is the reason for the absurdly high amount of issues and PRs.

[Zughy]

They also handle special interests or expertise in a meritocratic way like it’s currently done in Minetest.

I don't see any core artist even if a menu is apparently needed

This is the reason for the absurdly high amount of issues and PRs.

The reason is nobody takes the responsibility to say yes/no till you bring the issue right in the dev IRC, except sometimes Paramat (this guy); nobody says anything and nobody assigns anything. On 968 current issues, 959 are unassigned. Of those assigned 9, this one is assigned AND with "no core dev support long term", the SmallJoker one I linked before is abandoned, This has been assigned on January 1 2019, this has been assigned on November 21 2018, and finally this has been stuck as an upstream issue since March 10 2019. Doing the math, only 4 issues are currently followed by a core dev. Less than the current active core devs. Do this for a bunch of years, add the nitpicking/stalling reviews, and then you obtain what we have now

[Linuxdirk]

I don't see any core artist even if a menu is apparently needed

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.

On 968 current issues, 959 are unassigned.

In one of the utterly exhausting discussions it was mentioned by a core dev (don’t know who exactly it was) that the assigning functionality is not used. Basically because they’re all volunteers and no-one can just assign something to them.

AND with "no core dev support long term"

If it is not supported by a core dev (or if it causes work to implement) it’s dead until the requester was selected as a core dev and implements it by themself. It’s easier to patch and maintain a local repository or a public fork with your desired changes or try to implement them via mods than getting larger changes or code parts into official Minetest code as a non-core dev.