Team Fortress Wiki:Discussion/Wiki Cap/Archive 1

The following discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

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.

System reboot

Now that the new system is in place, we need a better and more visible way to handle things. Things to clear up are:

• How to tell users that they are free to check their own logs; they have to request a password for it, but it doesn't change over time and they may request it at any time, even without being nominated
• How to let people nominate themselves
• Rewriting the guidelines page

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)
  • If this is a problem, could it be solved by extending those who nominate and participate in voting to the "trusted editors", more people would reduce (but not eliminate) any effects personal bias' have on the voting proceedings? - 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)
• I nominate and approve the nominate-and-approve model. It requires effort on part of mods, but on the other hand valuable contributors naturally tend to get noticed. Also why are we using bullets instead of indents like civilized people — 23:14, 11 July 2011 (PDT)
• I have to admit that I have some qualms about the nominate-and-approve model, if only because some of us are relatively lazy. If anything, I think that one/several of us should keep a permanent but private list of discussed candidates somewhere, even if only on someone's HDD, so that we don't risk forgetting anybody and can keep discussions ongoing even if a vote fails. I'm fine with staff nominating users and then approving it via vote, but it needs at least some form of fallback. -- LordKelvin 12:22, 16 July 2011 (PDT)

Decision: Nominate and approve accepted.

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)
• I think discussions like this on the wiki are slow and cumbersome. Look how long it's taking us to even decided how to give them out (which brings me to another point further on). I don't think you can talk about how without talking about when. If you want discussions to go on for days (or weeks) then wiki, otherwise IRC. —Moussekateer·talk 08:42, 11 July 2011 (PDT)
• Basically we need to discuss, I suggest we have a regular discussion on a completely private IRC channel but a discussion that does not always conclude into a drop, and if someone really impress us we can gather up immediately and debate. We can have a special Wiki page where every user can suggest ONE editor with a reason (Preferably not themselves, but I haven't imagined the details of that) saying why he think he deserves the cap. This could help us notice people (because personally I can only name deserving french or english editors, not in other languages, there are other mods for this), and this page would need to be cleared regularly (details debatable). I do prefer an IRC to a long wiki debate over weeks because it can be more private than the wiki page everyone can read. Tturbo _{( / )} 09:52, 11 July 2011 (PDT)

• In my opinion it doesn't really matter as long as there is a record of the discussion, keep in mind that IRC is much more convenient and I can provide logs if necessary. -- Lagg 21:52, 11 July 2011 (PDT)

• My vote goes for irc. It lowers the threshold of taking part in discussion, which is an advantage if other moderators are as busy as I think or as lazy as I am. — 23:14, 11 July 2011 (PDT)

• I will throw my vote in on IRC as well. One of the things I remember being discussed before was making a private forum elsewhere, but that just screams "cabal" and isn't exactly reliable; doing things on the Wiki is very slow as well. On IRC, we can hammer a discussion out in two or three days with enough determination, whereas the same thing would take weeks or months on the Wiki. -- LordKelvin 12:22, 16 July 2011 (PDT)

Decision: Discussions in an IRC channel.

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)
• In an ideal world everyone would contribute to the discussion when they had the chance, but realistically that's not going to happen. Like it or not we need to have some sort of regularity so people (including myself) don't become lazy and put off voting. —Moussekateer·talk 08:42, 11 July 2011 (PDT)
• I'm certain we need a regular discussion to keep ourselves up to date and debate together. The drops however must not be. For instance we can keep a weekly private debate on an hidden channel, and randomly drop the number of decide cap a certain day of the week that changes every time (in example a Sunday we settle on 2 cap, and decide to drop one on a Wednesday and one on Friday because the precious ones were dropped at other days, giving not hints to the days of discussions/drops). Tturbo _{( / )} 09:52, 11 July 2011 (PDT)

• I think that it should be done when someone makes a large amount of useful contributions. It's easy enough for anyone to say that an editor deserves a hat, and at that point we can have a discussion about it via whatever medium is decided on. -- Lagg 21:52, 11 July 2011 (PDT)
  • I support this notion, although if done on irc, the periodic inactivity of the staff channel may cause nominations to be overlooked (time zones damn dagnabbit). — 23:14, 11 July 2011 (PDT)

• I would like to propose, as above, a permanent but private list of candidates be kept for continuous staff discussion. When someone catches our eye, we discuss it continuously and ask staff opinion as they come into the channel. If someone gathers enough approval, they get capped, otherwise they stay on the list with notations about how the vote went and what overall staff opinion of that user is, which can be brought up again at a later point. This way, there's regularity in that candidates can be discussed all the time, but non-regularity in that it's impossible to predict when someone might get a cap. -- LordKelvin 12:22, 16 July 2011 (PDT)

Decision: Discussions will be regular. Still deciding on consensus vs majority (See above).

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)
• I think regular users should be able to nominate other users, for those that we may overlook (which has happened plenty). The voting itself I'm not so sure about. Giving visibility to 'trusted users' I don't think is a good idea because it still has the stigma of the wiki having some sort of 'inner circle'. But at the same time making the discussion public could result in bad blood. This is a toughie for me. —Moussekateer·talk 08:42, 11 July 2011 (PDT)
• Apart from the Suggestion Page I mentionned earlier, I'm for a completely private process. We discuss privately and everything is decided between us. Not to empathize on the "friend of staff" thing but because we've seen what a completely public and transparent process caused.Tturbo _{( / )} 09:52, 11 July 2011 (PDT)

• See my opinion on How -- Lagg 21:52, 11 July 2011 (PDT)

• Even if the logs are not made public, I think a short rationale for selection should be, e.g. "For substantial translation work on the French wiki". — 23:14, 11 July 2011 (PDT)

• I think a record is a good thing, TBH. Making staff channel logs available to the public lets them keep tabs on what we're doing, so there's no complaints about "staff conspiracy" or whatnot. I still think cap discussions should be staff-only (no offense to non-staff longtime members), but I'm amenable to changing that as well depending on the circumstances and arguments. -- LordKelvin 12:22, 16 July 2011 (PDT)

Discussion still in-flux, will be concluded above via voting.

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)

Drops should happen whenever a nominated editor is approved (that is, after discussions that end with one or more nomitade editors approved).  –  Epic Eric (T | C) 14:50, 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)
• Give it to them when it's decided, no advantage in delaying it. —Moussekateer·talk 08:42, 11 July 2011 (PDT)
• Already talked about that earlier, my bad. We settle on a regular discussion, but the drops should not be regular, they can either be right now when we gather an unplanned reunion because someone really impressed more than 1 staff, or we decide every time on a day where the drop(s) will be made. Tturbo _{( / )} 09:52, 11 July 2011 (PDT)

• My opinion is simply to give someone a cap once they get enough approval, no regularity in it. If we discuss users as per my recommendation above (continuous with permanent record), then giving people caps as they earn them will produce zero regularity. -- LordKelvin 12:22, 16 July 2011 (PDT)

Decision: Drop as soon as a recipient is decided.

Unanimity or majority decides recipient?

Should recipients decided by unanimity or majority vote by the discussion attendees?

 Majority I'm going with majority here... I don't think any single attendee should be able to stop somebody receiving a cap if the rest of the attendees think that person deserves it. - 16:11, 17 July 2011 (PDT)

 Majority For exactly RJ's reason. —Moussekateer·talk 16:23, 17 July 2011 (PDT)

 Majority If the opposition has some very good reasons, the majority will change their opinion. — Wind 16:33, 17 July 2011 (PDT)

 Majority Best idea -- Firestorm 16:57, 17 July 2011 (PDT)

Consensus doesn't mean one guy stops everything >_> ... it means everyone is in agreement, that there is a general agreement amongst everyone. But obviously that is harder to measure so to make things easier,  Majority I guess seb26 17:01, 17 July 2011 (PDT)

 Majority for reasons stated above. — 23:58, 17 July 2011 (PDT)

In practice, it's not possible to actually legitimately get everyone to vote unanimously. -- Pilk _(talk) 00:35, 18 July 2011 (PDT)

Decision: Majority.

Invite trusted editors to the discussion?

Should trusted editors be able to partake in the discussion?

 Yes I think the more people partaking in the discussion would reduce the effects of any personal bias'/"friends of the admins". - 16:11, 17 July 2011 (PDT)

 Dunno How would we choose these 'trusted editors'? Are they just the green texted people? The fact that we call them 'trusted editors' might still imply a bias. —Moussekateer·talk 16:23, 17 July 2011 (PDT)

 No "Trusted editors" is really meant to be just a cosmetic change for editors we know do good stuff. That, and the fact that they are hand-picked by staff means that making them only partake in the discussion would actually reinforce the "friends of the admins"-ness. What I would like is only staff can vote, but anyone can nominate people. — Wind 16:33, 17 July 2011 (PDT)

 No Agree with Windpower... again... -- Firestorm 16:57, 17 July 2011 (PDT)

 Eh. Agree with RJ that more people should be joining in but I think determining a group of 'trusted editors' is pretty much having admins' friends anyway but under a different name. seb26 17:09, 17 July 2011 (PDT)

 No. Agree with Wind. — 23:58, 17 July 2011 (PDT)

 No The best judge of people deserving of the cap are people who are actually specifically tasked with moderating their edits. -- Pilk _(talk) 00:35, 18 July 2011 (PDT)

Decision: Staff only.

IRC logs be visible?

Should the IRC logs of the discussion be public?

 Yes The ability for the community to review what we're saying, I think, will add a bit of pressure to make well informed decisions. - 16:11, 17 July 2011 (PDT)

 Yes Transparency is important. Voting behind closed doors with no non-staff scrutiny leaves the process open to accusation of bias and distrust in the system. —Moussekateer·talk 16:23, 17 July 2011 (PDT)

 Dunno How about not making them public, but allowing people to ask if they have been nominated, and if yes, to know why they have not received it yet? Not sure exactly how much to give out (full log concerning a certain person?) but it would avoid some drama caused by the publicness of them while letting users know what's up with them. In any case, I advise the creation of a separate channel like #tfwikicap where such things could be discussed, in order to possibly have different settings without disrupting #tfwikistaff (like invite-only-ness) and to better coordinate the regular-ness of the meeting — Wind 16:33, 17 July 2011 (PDT)

 No I agree with Windpower.. it would be better if we quickly explain why they didn't get the cap, rather than show who exactly is opposing them. -- Firestorm 16:57, 17 July 2011 (PDT)

 Yes. Logs should be viewable by everyone but only mods / admins should be allowed to join when there is discussion going on. A new channel is an ok idea but I don't think it's really needed, we'll still face the same problems of whether to log / who to let in regardless. seb26 17:09, 17 July 2011 (PDT)

 Compromise? Transparency is an important concern, but if a nominee is not approved, it may be unnecessarily harsh to display the preceding discussion in public logs. I suggest only publicly releasing logs concerning approved recipients, and possibly privately disclosing others on request. — 23:58, 17 July 2011 (PDT)

 No It's not necessary. We should introduce transparency when explaining why individuals were awarded the cap at the time of awarding it. -- Pilk _(talk) 00:35, 18 July 2011 (PDT)

 Maybe I understand how some people may feel about anyone being able to see who they are opposing because of possible harassment or just the fact that they'll know people will be reviewing the logs may put them under pressure to not truly speak their mind. Neither of these things concern me personally but it is something to keep in mind when considering what lines, if any to release. Particularly my note about undue pressure. -- Lagg 14:24, 23 July 2011 (PDT)

Conclusion, or lack thereof

It seems we have reached a disagreement, gentlemen. I advise everyone, myself included, to reconsider. Some comments worth reading have been posted by the community as well. We should meet on IRC to discuss this — Wind 22:15, 19 July 2011 (PDT)

Well, guess that won't happen; I'll just go ahead and implement the idea described on the talk page, unless anyone has an objection. — Wind 01:03, 30 July 2011 (PDT)

 Approve Thumbs up from me. -RJ 01:06, 30 July 2011 (PDT)

 Approve Move zis gear up! -- OluapPlayer _(t) 18:43, 30 July 2011 (PDT)

 Done Implemented; system should be tested this week (tomorrow, that is). — Wind 15:30, 6 August 2011 (PDT)

Decision: Aforementioned system implemented.

The preceding discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.