Team Fortress Wiki:Discussion/Wiki Cap
Bringing back this to life, we need to decide how to proceed on Wiki Cap distribution in the future.
A reminder of some now-established points:
- Using a list and a scoring system is broken, leads to unproductively competitive behavior from users, and to over-reliance on it from staff
- While distribution on a weekly basis seemed like a good idea to regulate the number of total Wiki Caps in existence, it had the side-effect of the community having the false expectation for it to happen without fail every week, and proved to be too slow at times, causing frustration
- The English and Russian parts of the Wiki being complete, there has been an issue of people creating work for themselves in order to get more edits
- The combination of these things turned the Wiki Cap into a standalone reason to edit, rather than a reward for doing so
- The Wiki Cap guidelines need to be rewritten
Here are some solutions that have come up in order to address those issues:
- Using a list and a scoring system is broken, leads to unproductively competitive behavior from users, and to over-reliance on it from staff
- Done: Delete the Wiki Cap candidates list, and stop using the Wiki Cap scoring script entirely
- While distribution on a weekly basis seemed like a good idea to regulate the number of total Wiki Caps in existence, it had the side-effect of the community having the false expectation for it to happen without fail every week, and proved to be too slow at times, causing frustration
- Done: Dispel the notion that drops will happen every week; we did that by not giving anything on June 26th
- The frequency to give it may be irregular now. However, getting everyone together in order to decide on distribution requires a generally-agreed-upon moment when people are there, which may vary over time in order to keep it irregular
- Volume/rarity concerns should be disregarded; even if all editors with over 500 edits or so got a Wiki Cap, it would still be considered a rare item
- The English and Russian parts of the Wiki being complete, there has been an issue of people creating work for themselves in order to get more edits
- Done The deletion of the list should help this, as edit count matters less now, and is less visible
- The combination of these things turned the Wiki Cap into a standalone reason to edit, rather than a reward for doing so
- This needs to be more emphasized into the Wiki Cap guidelines
- Rewarding users based on other things than editing (e.g. outstanding community contribution, à la Shugo (item icons), Michael (highlander team), or Benjamoose (promo material, graphics, general awesomeness))
- This should make the "bias towards IRC members" more widely accepted, since IRC is a great way to get involved in more community-related matters other than pure editing. However, it should never be completely mandatory to use it
- The Wiki Cap guidelines need to be rewritten
- This can only be done when all of the above is settled
The method most people were leaning towards as of the last discussion was to do it on a nominate-and-approve basis:
- Staff members (or maybe regular contributions?) can nominate people and explain the reasons behind the nomination
- The rest of the staff reviews the nomination and approves, or declines, explaining their decision in case of a "no".
Multiple questions arise:
- When and where does this discussion happen?
- Can regular contributors see it?
- If yes, can they also nominate others?
- Does an approval require unanimity? Does it require a threshold of "yes"'s? Does a nomination expire if nobody says anything?
Last point: Robin said, in the email in which he talked about wiki cap distribution, that we may run any changes past by him. This is such a change, so his opinion should be taken into account before making any decision final. — Wind 11:43, 3 July 2011 (PDT)
Edit as of July 6th: Reformatted to make it easier to answer. Each question has its own section.
Distribution model
The best option here seems to be the nominate-and-approve basis. If there is any endorsements or objections to this, please post them here.
- Big problem with the nominate-and-approve model is that, put frankly, people are lazy; people won't really look out for people to nominate, nor to participate in the nomiation-voting. I feel that if we go this way, the cap would become even more exclusive than it currently is; and promote the kind of "have to be friends of the admins" narcissistic view some people seem to have of us. Is this a problem - do we want to make it more exclusive? - 16:40, 6 July 2011 (PDT)
- The nominate-and-approve requires the mods to focus on specific users, forcing them to overestimate some users and underestimate others, or to just ignore the voting and don't make part of it (as RJ said). I'm not sure about allowing trusted editors to participate, though this would help in the previous points. – Epic Eric (T | C) 10:11, 7 July 2011 (PDT)
Distribution process
How
How should the discussion happen? Should it be done in instant-style IRC, or on a talk page or a forum or something?
- IRC can get messy if we're having lots of people to "review". Doing it on the Wiki has the advantages of organisation and the pressure of the community being able to review what's written, however it has the disadvantage of being publicly editable (we want to keep the voting exclusive) - we could change the permissions so it's staff only, but then my expanding the discussions to "trusted editors" idea would be unfeasible on the Wiki without implementing a new user group and permissions directly in the MediaWiki configuration files. - 16:40, 6 July 2011 (PDT)
- I fully agree with RJackson. We have to find an organised, yet partially private, way to promote these votings. Setting up a new group for trusted users and allowing them to see a determined page is a good solution. – Epic Eric (T | C) 10:11, 7 July 2011 (PDT)
When
Should the discussion happen on a regular basis or not? If it is, is a consensus expected to be reached every time? If it is not, when should it be considered that a consensus has been reached?
- I'd say have regular discussions, keeping to a pattern could reduce the "laziness" concern I noted above as people would feel some pressure to look out for potential recipients. - 16:40, 6 July 2011 (PDT)
- Discussions must be regular so mods can get prepared and know when they'll be required for this task. Apart from what RJ said above, there's not much I can add. – Epic Eric (T | C) 10:11, 7 July 2011 (PDT)
- A regular thing would work best since it would mean that everyone would try to come on at the right time and whatnot. It also means that we actually give them out instead of waiting around for someone to realise that we haven't given them out – and then everyone who wasn't online at the time is just like "wat". seb26 22:19, 8 July 2011 (PDT)
Visibility
Should all or parts of the process be visible to all users, or none of it? If this is done in IRC, should logs be visible?
- Quoting myself above: "...the pressure of the community being able to review what's written" - that pressure would ensure we make well informed judgements. - 16:40, 6 July 2011 (PDT)
- It depends on the community's pressure. Some of them may agree, some others may not and cause havoc on other sites such as SPUF and ruin our image (as much mods fear). I think it should be visible for a few previously selected members only (mostly staff and trusted users). – Epic Eric (T | C) 10:11, 7 July 2011 (PDT)
Drops
Even if the "reunions" are made to be regular, the drops don't have to be. They can be randomized, though it may seem a bit silly. What do?
- Keep it regular - on the day of the discussions perhaps, but stress that there's no guarantee any caps will be given out that day. - 16:40, 6 July 2011 (PDT)
- Drops shouldn't be regular. Along with stressing the possibility that no Caps might be handed out, we should also inform users we can give 1, 2, or 10 Caps if necessary. Randomly selected drops are even more silly than regular drops, as they are not actually what we really want: to reward users. The quantity of Caps only depends on the number of users nominated and approved. – Epic Eric (T | C) 10:11, 7 July 2011 (PDT)
- (By "randomized", I was talking about the moment of the drop, not the user on which the drop happens) — Wind 12:06, 7 July 2011 (PDT)
- Just drop zem when it has been discussed / voted. Is easier. seb26 22:19, 8 July 2011 (PDT)
- I don't have anything to add but because WindPower won't stop bugging me about it, I'm posting to say I agree with pretty much all solutions presented. I don't think I can say anything else. -- OluapPlayer (t) 17:12, 9 July 2011 (PDT)
- Why can't we just use a "We'll come to you if we feel you deserve it method.", I don't see why it's so bad. Infi^ 11:18, 10 July 2011 (PDT)