STEAM GROUP
Team Fortress Wiki OTF Wiki
Join Group
STEAM GROUP
Team Fortress Wiki OTF Wiki
6,748
MEMBERS
255
IN-GAME
1,443
ONLINE
Founded
June 30, 2010
Location
United States 
Overview Announcements Discussions Events Members Comments
This topic has been locked
ωσΚ Aug 28, 2022 @ 11:34am
Staff emergency meeting
Notice: This discussion primarily concern staff matters, but the public is free to comment on it, as more voices provide more value. I'll be here to answer questions and take notes on suggestions or criticism. Also, fair warning; those that cannot keep it civilized or go off-topic will be banned from the discussion.



A brief rundown on what happened recently
I'm sure by now most of you is aware of the recent commotion that happened these past days, which has arised a bunch of serious issues that we need to do something about.

There also won't be no TL;DR, because I really want you guys to pay close attention to this matter and comment your thoughts on it. I apologize in advance if it's not concise or easily digestible, but I've spent a fair amount of time on the formatting to ensure readability.

If you really don't want to read the whole thing, then please refer to the section that has the most relevance to you, and comment on it accordingly.

Let's address a few things:
  • Wiki Cap hiatus
  • Nomination process
  • Staff cohesion/inactivity

Wiki Cap hiatus
Recently, the Wiki Cap nominations were put under hiatus by Lagg, because he believes that we're no longer capable of managing the voting process, either due to concerns of bias, friend nominations, lack of substantial reviews for translators, or fear of the cap getting devalued. See Nominations talk for details.

These are perfectly valid concerns and should've been tackled long ago. I can see where he's coming from, and I won't deny that the issues at hand are affecting the overall nomination process – because it very much is. However, unilateral action was not the way to go about it, regardless of who did it. A change this big should've been discussed and decided by bureaucracy, and I stand by that statement. With the staff lazing around, I can sort of see why this eventually happened, but that does not mean it's justifiable or that we should condone it.

Judging translators
This one is a sticky wicket for sure; judging translator candidates has become more difficult for us, especially with STS sunsetting. Valve has since moved their community translation efforts to the third-party platform, Crowdin, which functions identically to STS, except that anyone can participate, with minimal efforts. A lot of the old STS mods have been transferred over there, so it doesn't mean there's no moderation. In fact, it's the contrary.

How should we solve this?
Instead of solely relying on STS mods to conduct reviews of translators, we've decided to seek out help from cap holders that were granted a cap based on their translation efforts, who we believe to be qualified translators, thus still ensuring fair judgement. To combat bias/nepotism, a minimum of two reviews should be conducted, by different reviewers.

This will lengthen the review process, but not by much. Official Crowdin mods should always be the first go-to, and if none are available at the time, fall back to cap holders, or mix the bunch. A compiled list of qualified reviewers are still underway, but should make it easier for us to get a hold of reviewers in a timely manner.

If all else fails, ask the community for help, but remember; just because someone is a native-speaker, does not necessarily mean they can give substantial feedback and fairly judge someone's translation quality, forcing us to take it at face value.

Non-translators
Lagg believes the English part of the wiki to be fully complete, and that there's only polishing left to do, which isn't enough for cap standards. Yes and no. Even with the game being in maintenance mode, content updates still happen every year or so, and we don't know if/when a major update could drop. Those content updates are still enough for people to contribute imagery, weapon demonstrations, string additions to templates, as well as new translations.

Continue or discontinue the Wiki Cap?
Now the question for the hiatus remains: Are we willing to finally cause a change and end this stagnation, or pack it all up and discontinue the Wiki Cap? While it may be a big incentive for people to start editing and encourage quality contributions, it also shouldn't be their sole reason to join the wiki, because the cap isn't a participation right, and I too believe that honest and hard-working editors can still be attracted afterwards, just like with any other wiki.

Inevitably, the cap will get discontinued one day, and I've come to terms with that fact and so should you – but has that day really come? It could be argued that the cap has long since served its purpose, but I'll remain on the fence with that one.

Personally, I would be lying if I said I enjoy voting on candidates. I'd usually take a lot of time out of my day to thoroughly analyze candidates to ensure fair judgement, which is why I tend to write long essays sometimes and why I'm generally slow to vote in a timely manner. Whether I enjoy it or not, I still wish to continue doing it, for the sake of those that truly are deserving of a cap.

Nomination process
If we are to choose continuing cap distribution, we ought to make some changes to the current nomination system. Some wants to continue it the current way, while others want to reduce vote requirement count or autopilot it. For not to mention concerns of bias or friends nominating friends and how we should approach it.

Friend nomination/backing
I won't lie, I somewhat frown upon blatant friend nominations, as they usually are openly biased or lack substance, but they aren't exactly prohibited. Organic nominations happen rarely nowadays, because people either don't know how to start a nomination or don't take up the initiative.

Based on my own observation, community engagement will increase the odds of someone being nominated, but then it will likely be by someone that the nominee is familiar with, thus causing it to become a "friend" nomination. Without any community engagement on the wiki, editors are bound to burn out quickly, especially if they only have the cap in mind and continue to edit alone.

The point is, a vast number of past nominees have likely been nominated by friends or users they are close with, who felt they deserved it. Though, in the end, the voting staff are the ones doing the evaluation, so if they deem a nominee eligible, then what difference does it really make? Unless the voting staff member had some sort of bond to the nominee, I'd say it's quite irrelevant.

Unfair to past recipients
It could be argued that any such change to the current system/process would be unfair to past recipients or devalue the cap, but if we really want to continue distributing the cap, we would need to adapt to the current state.

How should we solve this?
Below is a list of proposed models by both staff and users, as well as my thoughts on them:

WindPower's proposal:
→[irc.biringa.com]
I would really like to see how this works in practice and how it will be handled. Otherwise, we probably should lean towards a more automatic process, but not fully automated, so that less action is required by staff to conclude a nomination.

Tark's proposal:
→[irc.biringa.com]
Reducing vote requirement count could lead to having poor judgement being overlooked and have the nominee bestowed a cap too quickly for the rest of the staff to determine. Some nominees in the past had almost received a cap due to lack of substantial review, and when it was finally revealed that their contributions weren't good enough, staff had to retract their votes in the last minute.

If we actually could automate nominations by tracking and filtering users based on a set criteria, as you suggest, then it should eliminate the concerns of friend nominations and biased backings. Whether backings should still be kept, we can decide by then. This would also solve the issue with the lack of organic nominations, but would require the staff to be active enough to review the suggested candidates and reach a consensus.

Gabrielwoj's proposal:
→[pastebin.com]
This could somewhat work, but also leaves out transparency. Granted, voting is already held behind closed doors for the sake of the nominee's privacy, although nominees can request access to their logs at any time.

The biggest issue with this, however, would be that the staff has to be fairly active, yet alone active enough to watch contributors, evaluate them based their contributions, and finally, take up the initiative to gather the rest of the staff and reach a general consensus on whether or not to grant a cap to that user. I can imagine this is what the initial process was like, but it just wouldn't work in this day and age.

Dereko's proposal:
→[pastebin.com]
Not a bad take, but giving a selected few editors a limited voice will run dry real quick, I'm afraid. I suppose an established voting committee could bear fruit, but they will need to be carefully picked, of course.

Devaluing the cap
Would a new system end up devaluing the cap? It's kinda hard to say, and largely depend on what system we decide to use. And no – it won't be in the sense that we will start giving caps out willy-nilly, as that should never happen. We should still strive to retain its value as a privilege and reward for valuable contributions, no matter what system gets put in place.

Will it become easier or harder? Ultimately, the goal is to keep the process running with minimal staff interaction to avoid months-on-end stagnation and wait time. If past recipients find the new system unfair, they'd have to understand that this is done to keep the distribution process going at a steady pace (even if going for years) and adapt to the current time/state.

Personally, I don't think it's ruining its value, and I'm not too worried about it. But I'll fully admit that I want to retain the cap's image as a privilege and reward and not as a
participation right.

Staff cohesion/inactivity
A long-term issue to say the least, but it's only natural for people to move on or become less active due to life or simply lack of interest – it's inevitable – and as I've already said, bringing in fresh staff is a temporary solution, as they too one day will become inactive, thus returning us to square one. Though, by definition, any solution is temporal, but we should at least try to do something about it if we're still interested in being a part of this project.

What can we do to become more active?
Honestly, it depends on if/how you want to stay active. Granted, this is all volunteer participation and we don't require you to edit the wiki everyday. You're pretty much free to come and go as you please, but I think it goes without saying that this is the root cause of the inactivity issue – and I happen to "abide" by it, too.

If you don't wish to participate or bring something to the table, then I'd assume you're either too lazy and just wish to keep your fancy title as a staff member, or are simply too busy with life. The latter is perfectly understandable and can't be avoided, but poppin' your head in every now and then – especially during these situations – shouldn't take that much time out of your busy schedule. If you really are unavailable, then please just make it known.

I'd also like to see more of you on the IRC. I can understand that you may forget to start up your client or whatever the reason may be. And to those of you that lack a bouncer, I'll offer free bouncer service to those interested. You may idle if you want, but it should make it easier for you to follow-up on past conversations rather than having to look up the wiki's public logs each time.

Recruiting more staff
We're a small enough team as-is, and with the majority of our team being as inactive as they are, it's difficult for us to keep up with staff duties, such as managing the nominations, as addressed earlier, or being available to deal with spam/vandalism/troublemakers. This will lead to less and less action being taken due to no discussion or concensus being made on existing matters, and eventually will lead to unilateral action, as seen by the enacted Wiki Cap hiatus.

As such, we should be looking into getting fresh staff onboard to create a better dynamic, which will hopefully cause a better flow. Eventually though, we will run out of potential staff candidates, and when that time happens, it might be a reasonable idea to call it quits and initialize archiveMode()

Below is a list of potential staff candidates and why they might fit the bill, as well as who is vouching for who.
You may vouch for any of these candidates or explain why you don't want them as staff, or even propose some yourself, down in the comments. Only staff members count, but we're open to suggestions.

Ashe ✔️
Ashe, not to be confused with Ashes, has been a member of the wiki for 2 years and receivied a cap for his general participation in the Weapon Demonstration Project, and has since been co-managing the official YouTube channel. He seems to have a good understanding of how the wiki works and is also taking on Spanish translation work, which would also make him a good pick as loc mod.

Current backers
  • Ashes
  • Lagg
  • Tark
  • Wookipan

Dereko ✔️
Dereko has been on the wiki for 4 years and mainly do translation work for zh-hans (simplified Chinese). He is a cap holder and seem like a competent translator, whose also responsible for managing the wiki Bilibili account (Chinese video platform) and has provided feedback on translators. Would be an overall good pick as loc mod.

Current backers
  • GrampaSwood
  • Lagg
  • Tark
  • Wookipan

Yossef ✔️
Yossef registered his account back in 2013, but first became active in 2018. He does not have a cap, but as stated in the Moderator guidelines, we have had capless (heh) moderators in the past. Nikno would be a good example of that. Alright, I'm going off on a tangent here, sorry.

Yossef is active on the wiki, regularly participate in discussions, hasn't caused any mishap or shown signs of being troublesome, and he is slowly crawling his way up the ladder in gaining a better understanding on how the wiki works. I've personally explained a few technical questions to him or helped him out with other technical matters. Even if he's lacking in experience, I wouldn't mind having him as a staff trainee.

Current backers
  • Lagg
  • Mikado282
  • Tark
  • Wookipan

In terms of backing/vouching, there should be at least four backers. If we really have trouble deciding, it may be reduced to three at a minimum, or the candidate will be discarded. Also, this won't be the future staff election process, I'm just trying to kill two (or multiple) birds with one stone, unless you want it to be.
* Checkmark indicates met criteria, but candidate may still receive more backers.



If you've read through this entire wall of text, I sincerely thank you – have a cookie 🍪 *reserved for those that read the entire thing >:(*
Last edited by ωσΚ; Sep 2, 2022 @ 2:20pm
< >
Showing 1-15 of 50 comments
Aiden Walker Sep 2, 2022 @ 9:42am 
So, if I understood correctly, and in summary, the wiki is low on staff? and the review process for cap receivers will be longer?
I first want to be sure that I understand what's going on before commenting on the matter.
Last edited by Aiden Walker; Sep 2, 2022 @ 9:42am
#1
ωσΚ Sep 2, 2022 @ 12:58pm 
Yes, those are the issues at large. The current translation review process/nomination queue time take too long to conclude due to lack of staff activity as well as the overall process, and we're open to suggestions on how we may reduce that. Any feedback is much appreciated!
#2
Yossef ⭐ Sep 17, 2022 @ 4:16pm 
Hi,
As we know, the Cap situation hasn’t been easy in the past few years. And I totally understand the concerns people are having while distributing the Cap.

I made a pastebin a while ago addressing some points.

https://pastebin.com/DxCvUg3r

Regarding the current Cap distribution system, I suggest in making some reforms. Its no surprise that the old system is no longer as sustainable as it was since its implementation a decade ago. We can start perhaps, by implementing one of the ideas I mentioned in my bin.
Cap holders that are image/video makers, can partake in voting for nominees that are being nominated for their image/video contribution. This way the voting pool is bigger and can make nomination process faster.

We can use this idea or perhaps other ideas as a pilot and see how this reformed system develops.

I’d like to hear what y’all think.

** EDIT 21/09/22 **

I was thinking about some other way to improve the current voting process, instead of reaching to 5 votes (either by granting or rejecting the wiki cap), we can do "Best of 5" and remove the "abstain" column all together, similar to what Grampa Swood mentioned. This way it will always end up with the user receiving or not the Cap. Moreover, this way we would only need 5 active staff members to vote, instead of requesting the presence of everybody, in a way, we alleviate that burden.

If by any chance there is an an even number of active staff members, by default a "No" would be added, this way it will always need the majority of staff members to agree.

How do we decide who is "active"?
If a staff member have not been participative (either IRC or Wiki itself), for X amount of time (5-6 months?), then the staff member in question would receive internally an "On hiatus" or "Inactive" status and won't be eligible to vote. Moreover, if a staff member becomes active *AFTER* the user have been nominated, the staff member in question would *NOT* be eligible to vote as well.

I can create an excel file (or Google Docs), with the registry of the activity of the staff members, this file will only be shared with the other staff members. The purpose for the file is to easily see which Staff members are currently active and eligible to vote, more or less if needed, within the same file I can create a database that tracks the amount of times a staff member voted (either, for or against granting the cap, or in general).

This are some thoughts that pops to my head during my day, I'm happy to hear your thoughts.


Last edited by Yossef ⭐; Sep 21, 2022 @ 2:19am
#3
Dereko | wiki.tf Sep 18, 2022 @ 5:17am 
Dereko's ideas has been presented in Wok's post, huge thanks for the thought exchanging.

With several users of our Wiki recently promoted to moderators, I'd say I am positive that we can conduct the staff reviews in a fairly satisfied efficiency provided the solutions mentioned in Wok's post.

I want to stress one of my points mentioned in the postbin: we could make a stricter barrier before a nomination become a topic for staff discussions.

(e.g. a nominee must receive nominations from a certain number of active editors before we start conducting the reviews, while those nominations which are considered not sufficient enough would be removed.)

By doing this, we can transfer some burden from reviewing process to nominating process, as well as to improve nomination quality.
#4
Mайкл282 (Michael282) Sep 18, 2022 @ 3:10pm 
Some of my observations (yes, light on the suggestions):

1. With the present system, most >passing< votes of the last 13 votes took only two months. IMO, 2 months is not a problem, nor is it unexpected that at least one of the volunteer voters would need 2 months to get their stuff together for a fair vote.

2. Yes, some votes do take much longer, so, the curiosity is, why? In some cases, there may be a problem or close call with the candidate. I am hoping for improvements to the long votes, but I want people to consider that most of the time, there is not a problem (if we can replace STS).

3. If a voting staff is choosing not to vote on a specific candidate, IMO, they should let the voting staff know. I think the wiki vote log is appropriate for such notification (cf. Nikno).

4. My 2017-18 vote took nine months, /supposedly/ when Mods were much more active.

5. As far as screening candidates goes, I have seen that done within the last two years (Removal of nominations before one or two votes.)

6. A reduction in Valve releases is natural; this is not a “caring” thing.

7. Therefore, a reduction in Wiki activity is natural.

8. Therefore, a reduction in Wikicap qualifying activity is natural, assuming no reduction in expected qualifications.

9. Therefore, a reduction in Wikicap nominations, votes, and awards is natural.

10. Despite statements otherwise, the number of voting staff is not greatly changed in the last 8-9 years. That said, an increase back to 9-10 voting staff would not be bad, but maybe not warranted given the Valve release rates.

11. Consequential to 6 through 10, a reduction in staff workload is natural and expected. My votes are not delayed because I have too many votes to do.

My original, longer disposition may be read here : https://pastebin.com/D9RePMaG
#5
Grampa Swood Sep 19, 2022 @ 9:19am 
My take on it is that this issue exclusively applies to the translator side of things, so we should either remove or update the hiatus notice ASAP. It's not fair for translators to block people who contribute a lot of non-image edits that would otherwise be eligible.

As for the reviews, I think it's universally agreed that we should go with old Cap holders/former STS mods/Crowdin mods. I don't see an issue with this and I'll agree to that.

As for the voting process, I agree with Gabriel's proposal of making it a more private affair than it currently is. I also think a time limit (i.e. 6 months, just to name anything) and then seeing if a minimum of 5 people voted. Whichever option has the most wins (with abstain/tie defaulting to a no, unless there's someone to break said tie). Setting the expectation that the Cap vote may take long is not necessarily a bad thing, but setting a hard time limit means that it can never be /too/ long without any verdict whatsoever.

As for the issue that's being brought up of "devaluing the cap for past recipients", that's completely false. Caps used to be given out for ridiculous reasons. See the approved nomination table with backings such as "Has been part of the wiki for quite some time now. [...] he has over 1400 edits and I see him every-time I'm on the Wiki IRC.", or "been helping me since I signed up on the wiki about 4 months ago. Has over 1000 edits since joining a year ago", or "consistently made a thousand edits of half a year. Often leaves wikichievements and positive comments".
If getting 3 staff votes is "devaluing" it, I don't think it had any value whatsoever to begin with. If anything, the current cap is more valuable because of how much harder it is to actually get it.


Not sure if I missed anything, but I really do wanna stress that devaluing the cap is non-existent. If I did miss anything, let me know.
#6
Ashe is Kiriko main Sep 19, 2022 @ 3:03pm 
1. I don't think there is a problem with the nomination system, because, after all, mods 1) determine the validity of a nomination and 2) decide if the nominated user deserves the cap and 3) it is not hard to distinguish an organic nomination to a friend nomin.
2. Friend nomination: This is weird because it is valid but it doesn't make sense if you consider the "participating in the IRC", and since trying to not be sociable or talking with other users sometimes can be counterproductive.
3. I don't have a problem with the devaluing of the cap. I agree with the point that Swood states, and we should look forward, vote with good judgement and not think too much in the mistakes made in the past.
#7
ωσΚ Sep 21, 2022 @ 1:48pm 
Originally posted by Yossef⭐:
Hi,
As we know, the Cap situation hasn’t been easy in the past few years. And I totally understand the concerns people are having while distributing the Cap.

I made a pastebin a while ago addressing some points.

https://pastebin.com/DxCvUg3r

Regarding the current Cap distribution system, I suggest in making some reforms. Its no surprise that the old system is no longer as sustainable as it was since its implementation a decade ago. We can start perhaps, by implementing one of the ideas I mentioned in my bin.
Cap holders that are image/video makers, can partake in voting for nominees that are being nominated for their image/video contribution. This way the voting pool is bigger and can make nomination process faster.

We can use this idea or perhaps other ideas as a pilot and see how this reformed system develops.

I’d like to hear what y’all think.

  1. Having image/demo makers get a word in feels quite similar to the process of reviewing loc candidates, only that it's intended for non-translators. I do like the idea; however given that we aren't impeded in the same way as with evaluating translations, images/demos are generally no issue to judge the quality of. I just don't see a reason to contact someone to evaluate something that we are already capable of doing in the first place, which could also end up dragging things out.

    Even if the goal is to establish a bigger voting committee, I don't think it's fair to equalize image/demo makers' verdict to a vote, because why should their voice be higher compared to loc reviewers? Moreover, they still wouldn't be able to do the voting themselves due to page protection.

    In theory, if we gave both loc reviewers and image/demo makers' a vote privilege, it would leave little staff interaction during nominations, which admittedly, is what we're aiming for, meaning that staff would only have to reach out to those privileged users. But in my opinion, it just doesn't feel right; like, the Wiki Cap is granted by the Wiki Staff, and having to rely on third-parties to do this feels like some kind of big corpo move to me and just kills the spirit.


  2. While STS is no more, the majority of veteran translators/mods have been transferred over to Crowdin. Now, I still find it a bit puzzling to navigate Crowdin and get in touch with other users, but it's the only alternative to STS we have. I believe our chances are much higher at getting someone to review loc candidates than getting in touch with some random people at Wikipedia, but it's not exactly a bad idea.

    I too feel that loc teams that lack activity are left out – excluded, even – from the chance of getting nominated. Your take could work well enough as an exception for loc teams with low activity/sole translators; by having the potential candidate contact staff and explain the situation that their loc team is lacking in active members, staff could then determine whether or not they are deemed eligible for a nomination and add them to the queue accordingly. This would of course be stated under the Wiki Cap project page.

    We are still in the middle of compiling a list of loc reviewers that are willing to help out with reviews, both consisting of Crowdin mods and cap holders. Also, we should inquire cap holders and new recipients who's been granted a cap based on translation work if they wish to take on the role of reviewing future candidates from their language. By doing so, we can effectively create a bigger pool of people that are on-call, which should help reduce wait times.
#8
ωσΚ Sep 21, 2022 @ 1:52pm 
Originally posted by Yossef⭐:
** EDIT 21/09/22 **

I was thinking about some other way to improve the current voting process, instead of reaching to 5 votes (either by granting or rejecting the wiki cap), we can do "Best of 5" and remove the "abstain" column all together, similar to what Grampa Swood mentioned. This way it will always end up with the user receiving or not the Cap. Moreover, this way we would only need 5 active staff members to vote, instead of requesting the presence of everybody, in a way, we alleviate that burden.

If by any chance there is an an even number of active staff members, by default a "No" would be added, this way it will always need the majority of staff members to agree.

How do we decide who is "active"?
If a staff member have not been participative (either IRC or Wiki itself), for X amount of time (5-6 months?), then the staff member in question would receive internally an "On hiatus" or "Inactive" status and won't be eligible to vote. Moreover, if a staff member becomes active *AFTER* the user have been nominated, the staff member in question would *NOT* be eligible to vote as well.

I can create an excel file (or Google Docs), with the registry of the activity of the staff members, this file will only be shared with the other staff members. The purpose for the file is to easily see which Staff members are currently active and eligible to vote, more or less if needed, within the same file I can create a database that tracks the amount of times a staff member voted (either, for or against granting the cap, or in general).

This are some thoughts that pops to my head during my day, I'm happy to hear your thoughts.


  1. I agree with the removal of the option to abstain; either you vote or you don't. It is rarely used nowadays anyway, and we have some staff members that do not wish to vote due to their own reasons, so it really doesn't serve any useful purpose.

  2. I think that penalizing inactive staff by stripping them off of their vote privileges will do more harm than good. Although, half a year of complete inactivity would qualify as going AWOL, and they'd likely have been demoted by then.

  3. A database or Google Doc sounds nice to have, but given how little of a team we are, I'm not so sure about its overall usefulness or if the maintenance work would be worth it.
Last edited by ωσΚ; Sep 21, 2022 @ 2:01pm
#9
ωσΚ Sep 21, 2022 @ 1:59pm 
Originally posted by Dereko | wiki.tf:
Dereko's ideas has been presented in Wok's post, huge thanks for the thought exchanging.

With several users of our Wiki recently promoted to moderators, I'd say I am positive that we can conduct the staff reviews in a fairly satisfied efficiency provided the solutions mentioned in Wok's post.

I want to stress one of my points mentioned in the postbin: we could make a stricter barrier before a nomination become a topic for staff discussions.

(e.g. a nominee must receive nominations from a certain number of active editors before we start conducting the reviews, while those nominations which are considered not sufficient enough would be removed.)

By doing this, we can transfer some burden from reviewing process to nominating process, as well as to improve nomination quality.

  1. Yes, the recent increase of staff would contribute immensely towards a faster nomination process, but only if a good handful of staff members are willing to do their part and vote in a timely manner.

  2. I'm not entirely sure about setting up a stricter barrier, as it is already stated on the nominations page that we – the staff – and I quote, "...reserve the right to veto a nomination if the candidate is deemed ineligible at the time of the nomination". We've utilized this right/reasoning in the past, so eliminating poor candidate entries isn't really a problem.
#10
ωσΚ Sep 21, 2022 @ 2:10pm 
Originally posted by Mайкл282:
Some of my observations (yes, light on the suggestions):

1. With the present system, most >passing< votes of the last 13 votes took only two months. IMO, 2 months is not a problem, nor is it unexpected that at least one of the volunteer voters would need 2 months to get their stuff together for a fair vote.

2. Yes, some votes do take much longer, so, the curiosity is, why? In some cases, there may be a problem or close call with the candidate. I am hoping for improvements to the long votes, but I want people to consider that most of the time, there is not a problem (if we can replace STS).

3. If a voting staff is choosing not to vote on a specific candidate, IMO, they should let the voting staff know. I think the wiki vote log is appropriate for such notification (cf. Nikno).

4. My 2017-18 vote took nine months, /supposedly/ when Mods were much more active.

5. As far as screening candidates goes, I have seen that done within the last two years (Removal of nominations before one or two votes.)

6. A reduction in Valve releases is natural; this is not a “caring” thing.

7. Therefore, a reduction in Wiki activity is natural.

8. Therefore, a reduction in Wikicap qualifying activity is natural, assuming no reduction in expected qualifications.

9. Therefore, a reduction in Wikicap nominations, votes, and awards is natural.

10. Despite statements otherwise, the number of voting staff is not greatly changed in the last 8-9 years. That said, an increase back to 9-10 voting staff would not be bad, but maybe not warranted given the Valve release rates.

11. Consequential to 6 through 10, a reduction in staff workload is natural and expected. My votes are not delayed because I have too many votes to do.

My original, longer disposition may be read here : https://pastebin.com/D9RePMaG

  1. 2 months is a fair wait time, yes, and certainly a whole lot better than previous years' wait time, where at one point a user were held in queue for an entire year, and mind you, there was absolutely nothing troubling with that user in terms of making a clear evaluation, which to my observation wasn't even due to staff inactivity but sheer procrastination. Hopefully any of these takes will help prevent that and reduce the wait time.

  2. I believe the reason as to why some staff members take long to vote might be due to a number of reasons such as being busy with life, not finding the right time, or simply wanting to conduct a thorough analysis of the candidate. Granted, any voting staff should thoroughly go through the nominee's contributions and give a substantial enough reason regardless. It does not have to be a wall of text, just merely going over the important bits would suffice.

  3. Yes, those staff members that do not wish to take part in voting or would like to abstain should make it known in the cap log, or in the comments under the staff Steam group's announcement vote reminders.

All other points above are somewhat self-explanatory and as you said; natural. We will, inevitably, face this issue again sometime in the future, and only time will tell when it's finally time to initialize archive mode.
#11
ωσΚ Sep 21, 2022 @ 2:35pm 
Originally posted by Grampa Swood:
My take on it is that this issue exclusively applies to the translator side of things, so we should either remove or update the hiatus notice ASAP. It's not fair for translators to block people who contribute a lot of non-image edits that would otherwise be eligible.

As for the reviews, I think it's universally agreed that we should go with old Cap holders/former STS mods/Crowdin mods. I don't see an issue with this and I'll agree to that.

As for the voting process, I agree with Gabriel's proposal of making it a more private affair than it currently is. I also think a time limit (i.e. 6 months, just to name anything) and then seeing if a minimum of 5 people voted. Whichever option has the most wins (with abstain/tie defaulting to a no, unless there's someone to break said tie). Setting the expectation that the Cap vote may take long is not necessarily a bad thing, but setting a hard time limit means that it can never be /too/ long without any verdict whatsoever.

As for the issue that's being brought up of "devaluing the cap for past recipients", that's completely false. Caps used to be given out for ridiculous reasons. See the approved nomination table with backings such as "Has been part of the wiki for quite some time now. [...] he has over 1400 edits and I see him every-time I'm on the Wiki IRC.", or "been helping me since I signed up on the wiki about 4 months ago. Has over 1000 edits since joining a year ago", or "consistently made a thousand edits of half a year. Often leaves wikichievements and positive comments".
If getting 3 staff votes is "devaluing" it, I don't think it had any value whatsoever to begin with. If anything, the current cap is more valuable because of how much harder it is to actually get it.


Not sure if I missed anything, but I really do wanna stress that devaluing the cap is non-existent. If I did miss anything, let me know.


  1. You could say that, yes, but ultimately, the issue also lies in staff being unable to vote in a timely manner. This has been an issue for years, and I'd agree that it actually has gotten somewhat better, but it varies. Of course, being a staff member is entirely voluntary, and you aren't really required to vote. However, volunteer work or not, we should at the very least set a ceiling for the nomination duration to prevent wait times longer than necessary.


  2. Indeed, there's really no other way. Once that reviewer list is finished, it should help speed things up.


  3. By making voting/candidate evaluation a complete private affair, that would mean abolishing the current nomination system, which ultimately kills transparency on the process of how users are elected as cap candidates. I think that it would be too big of a sudden change to make and would create a lot more confusion than putting the nominations on hiatus. Personally, I feel that the whole nomination system gives people the impression that the Wiki Cap is a right given for simply contributing, whereas having the Wiki Cap distributed privately would make it a more authentic reward granted by the staff based on their evaluations and as a token of grattitude for a job well done.

    But, as I've mentioned in the post, this take will require staff to actively watch users' contributions and bring up any potential candidates to the rest of the staff, discuss them, and then reach a consensus.


  4. I'd like to think that the whole thing about devaluing the cap is a subjective matter. I did explain the reason as to why it may be a bad idea to reduce the vote requirement count, and if we're going to make any changes to the nomination system, it should be something less direct than just changing the vote count, as we should still try to make the changes fair for past recipients. It may not be entirely possible, though.
Last edited by ωσΚ; Sep 21, 2022 @ 2:39pm
#12
ωσΚ Sep 21, 2022 @ 3:14pm 
Originally posted by Ashe wiki.tf:
1. I don't think there is a problem with the nomination system, because, after all, mods 1) determine the validity of a nomination and 2) decide if the nominated user deserves the cap and 3) it is not hard to distinguish an organic nomination to a friend nomin.
2. Friend nomination: This is weird because it is valid but it doesn't make sense if you consider the "participating in the IRC", and since trying to not be sociable or talking with other users sometimes can be counterproductive.
3. I don't have a problem with the devaluing of the cap. I agree with the point that Swood states, and we should look forward, vote with good judgement and not think too much in the mistakes made in the past.


  1. That's not really the issue at hand, though. Concerns of bias are valid, but if any staff are caught in the act of blatant bias/nepotism, thus violating NPOV, they may be relieved of partaking in future votings.

  2. You seem to have somewhat misunderstood this part. The issue with blatant friend nominations is how openly biased they tend to be, and how it just praises the nominee without adding in substantial feedback, thus the lack of substance gives us nothing to work with and might end up causing more confusion than anything for the voting staff.

  3. I'm not sure where it's stated that we frown upon nominee's past mistakes, if that's what you mean. If anything, having made mistakes in the past and having gained the knowledge to fix those mistakes later on is a sign of improvement as well as an indicator for a more careful editing etiquette, which should be commended instead.
#13
Yossef ⭐ Sep 21, 2022 @ 11:22pm 
Originally posted by Wok:
Originally posted by Yossef⭐:
Hi,
As we know, the Cap situation hasn’t been easy in the past few years. And I totally understand the concerns people are having while distributing the Cap.

I made a pastebin a while ago addressing some points.

https://pastebin.com/DxCvUg3r

Regarding the current Cap distribution system, I suggest in making some reforms. Its no surprise that the old system is no longer as sustainable as it was since its implementation a decade ago. We can start perhaps, by implementing one of the ideas I mentioned in my bin.
Cap holders that are image/video makers, can partake in voting for nominees that are being nominated for their image/video contribution. This way the voting pool is bigger and can make nomination process faster.

We can use this idea or perhaps other ideas as a pilot and see how this reformed system develops.

I’d like to hear what y’all think.

  1. Having image/demo makers get a word in feels quite similar to the process of reviewing loc candidates, only that it's intended for non-translators. I do like the idea; however given that we aren't impeded in the same way as with evaluating translations, images/demos are generally no issue to judge the quality of. I just don't see a reason to contact someone to evaluate something that we are already capable of doing in the first place, which could also end up dragging things out.

    Even if the goal is to establish a bigger voting committee, I don't think it's fair to equalize image/demo makers' verdict to a vote, because why should their voice be higher compared to loc reviewers? Moreover, they still wouldn't be able to do the voting themselves due to page protection.

    In theory, if we gave both loc reviewers and image/demo makers' a vote privilege, it would leave little staff interaction during nominations, which admittedly, is what we're aiming for, meaning that staff would only have to reach out to those privileged users. But in my opinion, it just doesn't feel right; like, the Wiki Cap is granted by the Wiki Staff, and having to rely on third-parties to do this feels like some kind of big corpo move to me and just kills the spirit.


  2. While STS is no more, the majority of veteran translators/mods have been transferred over to Crowdin. Now, I still find it a bit puzzling to navigate Crowdin and get in touch with other users, but it's the only alternative to STS we have. I believe our chances are much higher at getting someone to review loc candidates than getting in touch with some random people at Wikipedia, but it's not exactly a bad idea.

    I too feel that loc teams that lack activity are left out – excluded, even – from the chance of getting nominated. Your take could work well enough as an exception for loc teams with low activity/sole translators; by having the potential candidate contact staff and explain the situation that their loc team is lacking in active members, staff could then determine whether or not they are deemed eligible for a nomination and add them to the queue accordingly. This would of course be stated under the Wiki Cap project page.

    We are still in the middle of compiling a list of loc reviewers that are willing to help out with reviews, both consisting of Crowdin mods and cap holders. Also, we should inquire cap holders and new recipients who's been granted a cap based on translation work if they wish to take on the role of reviewing future candidates from their language. By doing so, we can effectively create a bigger pool of people that are on-call, which should help reduce wait times.

Regarding your 1st point:

I see where you are coming from, and I agree, image/demo nominees should be treated equally as the loc team. My initial goal was to alleviate the voting burden of the staff members by granting voting privileges to other users. This way the nomination process in theory, would be faster.

Regarding your 2nd point:

If a database of the available Crowbin mods/Cap holders is on the making for the loc nominees, all good by me. Perhaps making a Google Sheet/Excel table with the contact information, language, etc. If needed, I can build one and share it with the staff members.

For smaller and less active languages- We could start making a rough draft on the additional rules in the Wiki Cap project article. Again, exclusively for the users from loc teams that are less active.
#14
Yossef ⭐ Sep 21, 2022 @ 11:53pm 
Originally posted by Wok:
Originally posted by Yossef⭐:
** EDIT 21/09/22 **

I was thinking about some other way to improve the current voting process, instead of reaching to 5 votes (either by granting or rejecting the wiki cap), we can do "Best of 5" and remove the "abstain" column all together, similar to what Grampa Swood mentioned. This way it will always end up with the user receiving or not the Cap. Moreover, this way we would only need 5 active staff members to vote, instead of requesting the presence of everybody, in a way, we alleviate that burden.

If by any chance there is an an even number of active staff members, by default a "No" would be added, this way it will always need the majority of staff members to agree.

How do we decide who is "active"?
If a staff member have not been participative (either IRC or Wiki itself), for X amount of time (5-6 months?), then the staff member in question would receive internally an "On hiatus" or "Inactive" status and won't be eligible to vote. Moreover, if a staff member becomes active *AFTER* the user have been nominated, the staff member in question would *NOT* be eligible to vote as well.

I can create an excel file (or Google Docs), with the registry of the activity of the staff members, this file will only be shared with the other staff members. The purpose for the file is to easily see which Staff members are currently active and eligible to vote, more or less if needed, within the same file I can create a database that tracks the amount of times a staff member voted (either, for or against granting the cap, or in general).

This are some thoughts that pops to my head during my day, I'm happy to hear your thoughts.


  1. I agree with the removal of the option to abstain; either you vote or you don't. It is rarely used nowadays anyway, and we have some staff members that do not wish to vote due to their own reasons, so it really doesn't serve any useful purpose.

  2. I think that penalizing inactive staff by stripping them off of their vote privileges will do more harm than good. Although, half a year of complete inactivity would qualify as going AWOL, and they'd likely have been demoted by then.

  3. A database or Google Doc sounds nice to have, but given how little of a team we are, I'm not so sure about its overall usefulness or if the maintenance work would be worth it.

  • Unless another staff member disagrees, we can start by removing "abstain" column.

  • By giving a staff member half a year to show some kind of activity is more than enough, in my opinion. Of course, we would have to announce this "rule" before actually putting it in practice. Don't forget, voting also count as an "activity", this means that the staff member in question wouldn't be considered as "inactive" even if that staff does not do edits in the Wiki or participate in the IRC. I don't think that it would cause any harm if we announce it first, and again, you can't really complain if you were out of sight for over half a year.

    Assuming we use that "Best of 5" system, we would only need a maximum of 5 staff members nonetheless, and the reasoning behind it again, is for faster nomination process but also deal with Staff inactivity IF it happen, again, we would only need a maximum of 5.

  • We could always try, I can build the staff database handle the it. I'd have to share it with y'all. Assuming we decide to try this.
#15
< >
Showing 1-15 of 50 comments
Per page: 1530 50

All Discussions > General Discussions > Topic Details
Date Posted: Aug 28, 2022 @ 11:34am
Posts: 49
Start a New Discussion

Discussions Rules and Guidelines