smoth wrote:Pretty much ever karma system I have been in I end up with something like 40/-35 etc. People who are more charismatic and less actually doing things tend to have higher scores because they never challenge any one.
Well, it's not a "open" karma system, it should be a judgement from peers. Would be interesting to see if that changes your "rating" here. And I hope this wouldn’t be used as a "friend" status or popularity vote. That's the intention, not that I have a solid way to keep that out of it.
gajop wrote:I still think the solution you're offering is overly simplistic if you want to replace what we currently have - and that's general knowledge of the Spring ecosystem.
It's should be a quantifiable supplement next to that "general knowledge". i.e. have three people who know their shit bothered to indicate that they think that this person also knows his shit?
gajop wrote:I really don't think devs will really care you have "Merit recommendations" if you don't have meaningful and high quality contributions to the specific topic. You could try changing your system to be more similar to what's done in linkedin, where people would recommend you for special tasks (e.g. "Knows C++", which would be "Engine developer" here).
The problem is at the end of the day veterans won't consider these Merit points but instead make their own judgement.
And this would allow them to express that judgement. Yes, in the current implementation that is expressed in a binary fashion and that's a limitation that needs more thought. I don't know if (LinkedIn) categories would be practical.. who is going to maintain those categories? When to remove old categories for tech? Who is going to judge my CUDA skills? Or my knowledge of the Bitcoin protocol? When is such a category relevant for Spring? Add categories for "social skills"? Or "management"? Then again.. maybe if we reduce it to three categories: 'code', 'content' and 'other'?
Would categories be better then just free form? i.e "I'm Tim Blokdijk and as of 2015-06-05 I think this person made considerable contributions to Kernel Panic's AI, by tweaking the behaviour based on heat-map threat analysis."
That would prevent the problem of having to squeeze people in categories. But free form isn’t quantifiable. I don't know?
This system is only useful for noobs, who still don't know who's who in the community, and for that, it's too complex/hidden. 0ad does a better job for example: http://wildfiregames.com/forum/index.ph ... ntry307531
, where you can clearly see roles of each person in the forum discussion - pretty important if the person responding to you is a programmer, an artist, or a random community member! However, unlike 0ad, we have multiple games here, so it's likely just not feasible for us -> but in that case, we need a more complex system, rather than an even more simplified one.
Yes, 0ad has a more traditional "game developer" setup, I don't know if that means that they are doing a better job. It's a more top down system (afaict), I don't think that it would fit Spring.
gajop wrote:I also don't agree that you need to have a formal "merit" system to do bounties. Maybe if Spring suddenly grew to ludicrous sizes we would, but even if the developer community were to increase 10x it would still be manageable to keep track of who's doing what. At the very least, mods and admins are here to make sure no outright robbery-like bounties happen.
Yes, outright robbery-like bounties can be be countered. The problems start when it's not outright robbery but "over-promising" and "under-delivering", that happens to the best of us. Or if an admin has to approve an other dev's bounty's that will compete with his own underfunded bounty and they also just happen to dislike each other. Even a delay in approval would put the admin in a very difficult position.
In the end, shit will hit fans and with money involved people will give enough shit for a big mess. Those problems can seriously damage the community.
Having a "merit" system is not a requirement for doing bounties, but I like to play with the concept in the design of a bounty system. If I don't try this "merit" approach now and start with a bounty system based on an admin making the hard choices I'm going to reinforce a system where power is centralized.
enetheru wrote:I'm having difficulty folowing your train of thought.
I think your summary is spot on.
enetheru wrote:I notice that you yourself dont know how it would be used, and perhaps are unwilling to commit to official stance on how it should be used. which i think feels like a solution seeking for a problem, rather than the other way around.
Yes, right now I'm not committing to any interpretation or use of this merit thing. Maybe that's a solution seeking a problem.. I think that if "merit" would have to solve an acute problem the pressure from the problem would make us discard it and fall back on a top down approach. Let it mature on the sideline, play around with it, see if it has any 'merit'.
In the meantime I'm reading up on json-ld, deciding what framework to use, bdd for testing?
enetheru wrote:I feel like there are multiple problems you are trying to solve with one 'simple' solution, and feel like its just needs tuning to make it work..
I'm seeing too much in the way of active personal engagement with the system, and people are always lazier than you give them credit for.
and then there's this: "But as I plan on using this "merit" status thing to split the userbase into two groups (contributors and playerbase)", umm... massive red flag.
I hope merit can help solve different problems as people are lazy and we will lack engagement for to complex systems.
And why is it a red flag? I want to take that concern serious. What's your fear here?
enetheru wrote:The general trend of your posts indicates that this will happen, and I would like to see it happen in the way that you envision internally, but I'm not convinced it will happen that way, and I fear it will be ignored and your time wasted.
I wrote the code.. it works, but I'm not even putting it on https://test.springrts.com/
I first want to make sure I address any concerns expressed. I don't think I would have wasted my time if it's ignored, trying a few things and learning why it doesn't work would be an interesting outcome. If someone would remove it prematurely for "reason" without a public discussion. Yes, then I would have wasted my time.
enetheru wrote:I have ideas for improvement, but after this post I don't think its the right time to respond with those.
Feel free to share your ideas, you can also message me in a pm if needed. And thanks.
smoth wrote:Honestly if the system was enabled, I'd probably set most of the FGJL people as merit I and several people I used to have spat with such as knorke, argh, caydr because they did shit.
I think honestly just having the title of content dev is enough
Fgjl are fine people. But if we were to use merit for voting then there's a risk of giving merit to people that vote a particular way disregarding the "contributor" part, that would kill the merit status. It should indeed be about those that do shit, even if you have disagreements.
hokomoko wrote:I thought about this quite a lot yesterday, but decided to only post today, because yesterday I wasn't even eligible for wanting to get merit, since I registered on June 1st 2014.
Oops, seems like I've already written my first point.
Oh great, perfect timing. What would you suggest? Is 6 months better? Or 3 months, 9 months? I just picked a year, it seemed a reasonable time for someone to demonstrate his or her capabilities and commitment. What do you think of the 25 posts (one post every two weeks)?
I know both are artificial measurements. Maybe just ask the user if they are capable and committed? As in a "Do you consider yourself capable and committed?" checkbox?
hokomoko wrote:The current organization of Spring is based on oligarchy, where some folks I've never chosen decide how things are going with or without consulting me or any other person. Sometimes even without consulting each other.
If a large portion of users will have merit, there's going to be chaos, and merit will degrade into being nothing.
If a small portion of users will have merit, we'll just trade one form of oligarchy with another.
I don't think oligarchy is the right way to characterise Spring as it stands. I also think that those that happen to control some aspect of Spring do not necessary wanted the responsibility but just had to do it as nobody else did it.
hokomoko wrote:The problem I see with merit is that it's arguably giving the illusion of democracy, or equal opportunities. This is a very good thing in society, but not in a project. It doesn't matter how nice I am and how much people want feature X in the engine if adding my code is a bad idea (due to performance, bugs or any other reason). Democracy may allow it in and we can't really have that. Oligarchy is the only system where people stay around long enough to clean the mess after mistakes.
Debian's DD's chose a 'project leader' and this person then can chose members for a 'technical committee'. The TC makes the final decision with technical disputes. I personally think Debian's 'technical committee' is one of the better functioning body's in that project.
hokomoko wrote:It's not that I think the current situation is wonderful and nothing needs to be changed, for instance the process of getting something contributed into the engine is terribly tedious at the moment since there's only one core dev left active, and he probably has better stuff to do than reviewing pull requests all day long. That's a subject for a different discussion though.
Yes, this topic is not about how things are organized currently. If you need commit access to github you will have to take that up with those who administer that.
tzaeru wrote:More seriously though, would there be a potential for big harm done if a system like this was tried?
If it's not actually used for anything it wouldn’t do any harm, if the merit status is used for something then we also have to make sure it's functioning as intended. It's probably possible to abuse/break the current implementation.