From the feedback (thanks, guys!) I conclude that this would be a good idea, at least to try. So let me outline here what this can ultimately look like. We would implement it in stages, starting from the top levels, but eventually work our way levels down:
General Rules:
- Any and all asking for promotions or karma is off-limits. Repeated offending will be banned.
- Settlers and Citizens will stick with giving/receiving karma. We display the karma in the voting process to simply give additional information on the proposed people. Specially if people are very controversial (+10 & -10), this should be a sign that someone maybe isn’t Master material.
- All levels (except Settler and Citizen) can vote to promote by one rank if the proposed person has a lower rank.
- All votes are secret. Nobody can see how many votes someone got, and you can see only who is proposed if you can actually vote on them.
- Higher level votes count double. If a Architect votes on a citizen, it’s +1 vote. A Designer can give +2 votes, the next level +4, then +8 and so on.
- If someone has been upgraded, they have to wait at least 2 months before they can be proposed again. Someone has to be Citizen before being recommended.
- A negative vote will be subtracted from the points.
- Votes cast expire after 2 months to make sure people do not linger in the proposal system for 6 months.
- To recommend someone, you need to be 2 levels above the proposed person (or Elder).
When will someone be upgraded?
I made the following spreadsheet:
So there are 11 active Elders, 11 Masters and so on (Column A/B). If we assume that Architects have a voting power of 1, and we double at every step, Elders will have 8 (column C). Assuming all users of a level vote for someone, their per-level voting power per level is 88 for Elders, 32 for Architects (Column D) etc. Since everyone in the table can vote for an Citizen to be upgraded, the accumulated voting power for that level is 88+44+14+32=178 (Column E), for an Architects to become Designer it’s the same but less the Architect votes (88+44+14=146) and so on (column E). Then we assume that all Elders votes together should always be enough to promote someone, so the max vote required is 88, (100% of Elders) and then less than that when we go lower (Column F). So we could vote a Citizen to Architect with 26 Architects (Field G5) or with 4 Elders or 7 Masters or 13 Designers. Or any combination of those. This method puts the main power in the most regular users and makes sure that we need more users with each level we go down, but Elders can always rule the game. It will be hard to get 26 Architects to vote for something. To have 4 Elders in one vote will be easy enough however. They are online a lot and talk to each other anyhow. It also makes it quite hard for someone to come in with friends and affects the voting process since there would be quite some people required.
Rejected method:
There are two possible base methods: The one above where we assume that the combined power of all Elders should be enough for anything, or one where we want a certain % of all possible voters to be counted. Both methods have their advantages and disadvantages. I tried around a bit and chose the first one. If, alternatively we used the same vote power (1,2,4 & 8) and left the % progression the same, but made the % depending on the overall available voting power, we would get this:
I found this unreasonable since even all Elders would not be able to promote someone to Master. Of course one can compensate with higher voting powers for Elders, but then we just get back to simulate the first model.
We might change this in the future if we find out that there are not enough people being able to accumulate enough votes, but for now I want to keep this.
