Spring RTS Engine

This is a rough idea of how I have always seen the content devs. Just to clarify, I specified functional as part of designer because we have tons of lazy douches with half baked ideas, few ever really flesh them out

I couldn't resist. (and i've always thought this of your typical spring game-dev)

Ehh, maybe 'basement dweller' would be a more factual characterization.

Anyway, I suspect that we are nearing the end of the productive discussion. I will have to find some time to code the feedback from this topic. There are one or two changes I want to make.

And then then there’s the question if there are 4 or 5 people that meet the requirements, will take this thing serious enough, and are willing to give each other 3 or more recommendations to be part of the initial seed.

So you are still pursuing it despite the feedback?

I think I agree with the characterization of a merit system as a solution in search of a problem. I'm also wary of karma-ish systems in general, since I watched such a system contribute heavily to a game community's implosion. [1]

This is (of course) a very different situation, since this is primarily a technical community and an open source project, but the vague dread of karma remains

Tim: you mentioned in your problem statement that the ZK server split was one of your primary motivations, and then posed some hypotheticals about a sudden influx of cash needing more structure to handle without corroding the community -- is there a potential XY discussion happening?

I don't doubt that a Spring game becoming a massive success would cause some growing pains, but perhaps it makes sense to identify the core issues before proposing approaches to shake things up (such as merit). In particular, identifying those issues that we feel would be impossible to solve at the moment that growth is becoming obvious.

My overall feeling about merit is reflected in enetheru's spot-on comment:

enetheru wrote: The only influence anyone has over anyone else is that which is given.

All the merit in the world doesn't mean an individual can demand changes that they are otherwise unable to effect through personal effort (technical or political or reputational).

Conversely, if the goal is merely to highlight "this is an important person", I think trying to quantify the political or reputational ability of a community member to drive changes is a really hard problem that we're unlikely to solve in a useful way, except in exceptional cases where everyone agrees that the person is doing great work (in which case they should just be publicly recognized as "awesome person who we all trust", like "project lead" status).

At any rate, my instinct is "YAGNI!" -- at the moment I feel a bit like we're a tiny company talking about making sure the product will scale to 100 million concurrent users when we barely have 1000. I tend towards thinking that games should manage their own needs in the event of sudden popularity, much as ZK is essentially doing.


[1] Obscure free 90s multiplayer game with a strong community of organized team play, developer added "karma" on a whim that you could gift to people for doing things you approved of in-game: the more karma you had, the more power you had to give it; led to a lot of bickering and more mature players leaving the community, which led to the death spiral.

So, now we dragged the ideal down into the mud and wrestled it, this is not a burrial - at all.

Stackoverflow showed, that a slight change to discussion culture and forum presentation can reel phenomenal results.

The problem is the clash between the bazaar culture of open source, and the rather top-down approach the merit-system (and the actual vote by moving fingertips aka as coding) have. Formalizing this clash into something working is difficult (Q.E.D. by thread) also because it means kissing goodbye to many ilusions.

So what is there too vote about? Wildgrowth- people will contribute. You dont get to decide what they will contribute, when or how- (except for the rare kind that is very nice and meritty) - all the community (and with it merit) could decide upon is wethere there contribution stays.
Should the gardener murder the pull-request of recent, or not.

Also interest conflicts- i should not have a say en detail on matters i have no clue about. So allowing votes on results and Delegated People okay - voting on fine-details - not okay.

Lets take MT again- it was fast. And (according to the devs involved) unmaintainable. The broad public would vote for keeping it- only knowing the results. While the experts would jetison it - for cryptic expertinistic reasons - like code readability.
They explained, but i didnt read.

Merit should only allow voting on passive outcomes - in our historic example: is it worth cutting time from other features, to rewrite MT.
And event then only allow devs to vote on that.
Really really sorry.
This is now the first spring imperium.

I had some 1 on 1 discussions the past weeks and I wrote some more code.. I'm going to reply to the earlier feedback and then discuss the new code in a separate reply.

hokomoko wrote:As far as I know, no one here was elected and everyone was either appointed by others or by themselves. If someone is the only one left to do a certain job, they were still appointed in the past, maybe to do something else, but the main point is that there is and was no democratic process.

It's true, Spring is not a Democracy. And with this 'Merit'-ocracy extension I'm also not really suggesting to make it one. Depending on the situation Democratic principles can make sense. But the most popular thing is not necessary the right way to go, and it shouldn’t get in the way of people who do the "crazy" alternative things.

hokomoko wrote:

Tim Blokdijk wrote:Yes, this topic is not about how things are organized currently.

You're creating a class system in the spring community so I'd argue it actually is.

Ok, maybe you're right. It's definitely the next step up for discussion. I'm reluctant to move into the "what" and "how" of organizing things. I want to solve the "who" question with merit first, once I know who actually ends up with the merit status.. at that point it becomes easier to decide on how they should be empowered in relation to what. If we indeed decide to empower the "merit" group. I'm willing to just delete the extension if we end up with a group of 'merit' users that are just not the right people.
But I wrote some more code..

enetheru wrote:And thats to turn spring community interaction into a RPG style game that takes zero(and i mean zero) effort to play.

It's to much work for me to program and maintain. But purely abstract it's a interesting idea.

enetheru wrote:its the idea that there needs to be a split, or that i would be a gamer or a creator, when reality is more grey. people feeling disenfranchised by putting them in a box they dont necessarily feel they belong. making hard splits is never a good idea. people take offence when you categorise them.

Maybe, I think it depends on what requirements are in place (to get merit) and how transparent those are. Also it's not my intention to make it a hard split, more of a soft split. If merit does become a hard requirement for something it should be openly discussed.

Forboding Angel wrote:The largest issue I see on these forums is that only people who code are given any credit for anything, despite the fact that coding is actually only a little tiny part of making a game for spring, not to mention making maps, wiki tidiness, and all the stuff that AF mentioned, forum moderating, etc etc.

Yes, we as a community also have the tendency to expect c++ programmers do a lot of non programming tasks.

PicassoCT wrote:But you cant allow people to vote on everything, ..

For now (as far as I'm concerned) if any voting is done it's Greek style voting, e.a. you can vote whatever you like but those that do make the decision.
Only when there's a clearly defined process (written down in a document) were voting is part of reaching consensus on that particular topic then the vote might have meaning. If the exact question asked in the vote is not predefined in that process it's just a random poll.

Nemo wrote:I think I agree with the characterization of a merit system as a solution in search of a problem.

I wrote code to give merit a real use, I'm going to discuss this in my next reply here.

Nemo wrote:Tim: you mentioned in your problem statement that the ZK server split was one of your primary motivations, and then posed some hypotheticals about a sudden influx of cash needing more structure to handle without corroding the community -- is there a potential XY discussion happening?

Yes. There are multiple topics that are semi related. I started with merit as the other topics always have a "who" aspect. I would like merit to be a basic building block that can help scope that "who" aspect. So for example a "technical committee" could have dealt with the ZK situation. Who would have been part of that committee? They might have been appointed by several "project leads". Who appoints the leads? The people with merit vote once a year on a new project lead. Who have merit? Those that match the requirements.
This is how Debian does it, I'm not suggesting we would need or want this type of structure with layered votes and appointments but we can create the structure that works for us.

Nemo wrote:I don't doubt that a Spring game becoming a massive success would cause some growing pains, but perhaps it makes sense to identify the core issues before proposing approaches to shake things up (such as merit). In particular, identifying those issues that we feel would be impossible to solve at the moment that growth is becoming obvious.

Yes. The problem with "identifying the core issues before proposing solutions" is that a lot of people would consider that an academic exercise. I decided to think things trough and to write the code before starting this discussion to make it as concrete as possible. I do want to have the deeper discussion about "who" we are, "what" we do and "how" we do it. And I also chose this somewhat calm period to introduce this merit thing. When we're dealing with pressing growth issues there is no room to introduce larger changes or have a meta type discussion.

Nemo wrote:All the merit in the world doesn't mean an individual can demand changes that they are otherwise unable to effect through personal effort (technical or political or reputational).

Yes. I fully agree.

Nemo wrote:Conversely, if the goal is merely to highlight "this is an important person", I think trying to quantify the political or reputational ability of a community member to drive changes is a really hard problem that we're unlikely to solve in a useful way, except in exceptional cases where everyone agrees that the person is doing great work (in which case they should just be publicly recognized as "awesome person who we all trust", like "project lead" status).

It's always going to be an approximation. I do want to try and "solve" it to a point where it's useful. I honestly don't know if it will work.
The "everyone agrees", "great work", "just be publicly recognized", "person who we all trust" and "project lead" approach is imo really murky and undefined. It's not a strong position. What happens is that admin/root access defaults into some sort of lead role, which is "ok".. until things aren't ok. And then it's good to have some sort of agreed upon process to resolve the crisis.

Nemo wrote:I tend towards thinking that games should manage their own needs in the event of sudden popularity, much as ZK is essentially doing.

Technically I would like to see a hybrid solution where games and other projects can hook into the overall Spring ecosystem where it makes sense to do so. Spring as a provider of services so effort can easily be shared across games and other projects.
Culturally Spring should also develop something to define itself. How much is this a Meritocracy? Democracy? Voluntaryism? Benevolent Dictatorship? Open Source? Non-profit? Commercial? Code of Conduct?

About the new code I wrote.
I added a second PhpBB extension, 'Merit for Auto Groups'. This extension makes a third extension 'Auto Groups' aware of the merit status as defined by the initial 'Merit' extension.
The 'Auto Groups' extension is an official extension developed and supported by the PhpBB extension team. It allows us to create standard PhpBB groups that are automatically populated with users that match a requirement. 'Merit for Auto Groups' makes it possible to select merit as a criteria within the 'Auto Groups' interface.

As the main criticism of 'Merit' as it stands seems to be that it has no use I decided to up the stakes and create a use.
Back in the day when the 'Dedicated Developer Discussion' sub-forum was new we had the problem "who gets the right to post here".
This never got solved. At some point a new PhpBB group was created for posting access to DDD and the old group lost its meaning. The DDD sub-forum hasn't been used for two years and as I'm still the admin for that old group (I presume it's the reason my username is still blue) I want to suggest to rename it to "Merit" and remove everyone from it. Then give people that gain merit posting access to DDD. And remove myself as group admin in the process.
I think that it's a relatively risk free use of merit, but would give it an actual meaning.

Please understand that this is a proposal, open for public discussion.

And what will be posted there?

Presumably things that you only what qualified people to discuss. To that end, I actually think it could be useful. Sometimes you want the thoughts of people who are experienced like you, without the peanut gallery. I can see the usefulness of that.

I have to admit that I hate the idea of a situation where generic development discussion takes place, where one has to be accredited in order to take part, with the purpose of "filtering out the noise" of unqualified discussion - this is how the merit idea comes across to me. Maybe there would be a small gain in the quality of the discussion, but I rate the chance of putting productive people off through elitism/bureaucracy as big.

The range of skills around here is very diverse, and the time people have to contribute changes randomly. There have also been cases where previously good people turned sour, and where someone with skills appeared out of nowhere. I don't think its sensible to try and encapsulate all that into a single on/off switch.

I also don't understand what problem merit is trying to solve. Afaics we have already have a good level of productive discussion, and (maybe others would say differently but) I don't think its difficult to work out who are productive/helpful people, especially since most are.

What happens is that admin/root access defaults into some sort of lead role, which is "ok".. until things aren't ok. And then it's good to have some sort of agreed upon process to resolve the crisis.

One the other hand, this I completely agree with. But I don't know how to do it in a way that suits Spring.

I like the merit idea: even if it's not perfect it's a step to the right direction, and that is to make the leaders that are chosen a bit more representative than what they are now.

I think it will be quite hard to predict how the merit will turn out, and I think that that makes some people cautious. But why not give it a shot and see what happens? Honestly, we do not have much to lose.

One more suggestion for increasing transparency would be to make a forum tag for the leaders that says how they have been appointed, like "appointed moderator by xxx" / " voted moderator by xxx"...

Silentwings wrote:I have to admit that I hate the idea of a situation where generic development discussion takes place, where one has to be accredited in order to take part, with the purpose of "filtering out the noise" of unqualified discussion - this is how the merit idea comes across to me. Maybe there would be a small gain in the quality of the discussion, but I rate the chance of putting productive people off through elitism/bureaucracy as big.

The range of skills around here is very diverse, and the time people have to contribute changes randomly. There have also been cases where previously good people turned sour, and where someone with skills appeared out of nowhere. I don't think its sensible to try and encapsulate all that into a single on/off switch.

I also don't understand what problem merit is trying to solve. Afaics we have already have a good level of productive discussion, and (maybe others would say differently but) I don't think its difficult to work out who are productive/helpful people, especially since most are.

What happens is that admin/root access defaults into some sort of lead role, which is "ok".. until things aren't ok. And then it's good to have some sort of agreed upon process to resolve the crisis.

One the other hand, this I completely agree with. But I don't know how to do it in a way that suits Spring.

we could use more examples of issues spring community had problems dealing with in the past and how having a merit system in place would have improved them.

I suppose all one has to do in that case is look in the semi-recent past.

Argh's community "mandates"
Salmon Pink is the new red
GPL by fire
BA fanbois vs Spring Project (BA fanbois had a HUGE problem with spring as an engine going more generic enginewise)
The removal of BA as "Default mod"
Removal of "Default Mod" altogether
Removal of "Great Divide" as default map
Removal of "Default Map"
Taslicent forcing user machines to download a horribly broken springlobby build
Argh vs Community
GPL -> But what does it all mean, Basil?

And oh so many more.

But the question was, how might some people having "merit" and others not having it, have helped?

And none of those are semi-recent.

Hokomoko ought to be the nail in the coffin of the whole concept

There have also been cases ... where someone with skills appeared out of nowhere.

The other part of that quote does relate to semi-recent and indeed recent events, also:

There have also been cases where previously good people turned sour.

Silentwings wrote:

What happens is that admin/root access defaults into some sort of lead role, which is "ok".. until things aren't ok. And then it's good to have some sort of agreed upon process to resolve the crisis.

One the other hand, this I completely agree with. But I don't know how to do it in a way that suits Spring.

I'm here to evaluate every alternative proposal and I'm willing to put my code where my mouth is.

FLOZi wrote:Hokomoko ought to be the nail in the coffin of the whole concept

I'm interpreting this as: The requirement of having an account older then a year before you can get merit is problematic.

We could drop it as a requirement. The essence is that X amount of people recommend someone else, the other requirements are more like sanity checks.

Silentwings wrote:But the question was, how might some people having "merit" and others not having it, have helped?

I don't know about the cases Forboding Angel refers to, I was not involved in most of those situations.
But I was very directly involved in the ZK split. It was me that did things that "resolved" that crisis. And I did not like it. I don't think that it should be up to my digression on how to resolve things like that.
It was the direct trigger for me to create this 'Merit' thing as it would have given me an inclusive group of people I could put the dilemma to.
Now it was just me and the people that had a conflict with each other. People did not want to talk with each other and my behind the scene shuttle diplomacy did not help to mediate the situation. It was just messy.

Tim Blokdijk wrote:

FLOZi wrote:Hokomoko ought to be the nail in the coffin of the whole concept

I'm interpreting this as: The requirement of having an account older then a year before you can get merit is problematic.

A year ago I was irrelevant for mostly anything, today I'm apparently an engine dev, but basically two weeks from now I may insist that the engine has to be renamed into autumn, fork it and go rogue. (clarification: no such plans exist at the moment)

Who's worth hearing and who should make decisions is very fluid, and the Merit system as you present it is either:

• Irrelevant - "Merit" won't mean anything substantial

or

• Misguided - The people with "Merit" won't necessarily be the right people (whatever right means).

At the moment, how many people in the spring ecosystem do you really trust?

Please explain how Merit would have eradicated the fundamental disagreements over the approach to lobby server software design which was the root cause of zk split.