Jump to content

Requests for comment/Bureaucrats on small wikis

From Meta, a Wikimedia project coordination wiki

The following request for comments is closed. Withdrawn by requestor.

Hi all, simple proposal today. Stewards need to evaluate whether small wikis are eligible for local bureaucrats, but this is done on our own judgement or consensus within our group. I would like to expand that and add some legitimacy through an RfC on the matter. Setting a quantifiable limit on this would add legitimacy to our process, and help small wikis know the levels of local activity they need in order to have local bureaucrats. This comes after I have needed to decline the third RfB for this year (out of three, I might add), and I am not happy without being able to reference some policy to the communities as to why I can't grant their permissions.

I propose that in order for a wiki to gain local bureaucrats, there must be an RfB process lasting for a week in time, during which at least ten active, local users must support the candidate, and there must be 80% support overall. This process would also be subject to local wiki policies, though those policies could only be more - not less - restricting on whether or not a candidacy was successful.

Active local users are here defined as those who have made contributions outside of the vote in which they participated. These contributions can be minor, but must not be associated with the vote in any way (i.e. no gaming the system).

Please say what you think, and feel free to propose alternatives to the numbers I've given above. If I have missed anything in the preamble here, please also add it! Thanks. – Ajraddatz (talk) 02:29, 10 September 2016 (UTC)[reply]


  • Support 10/80% as nominator. – Ajraddatz (talk) 02:30, 10 September 2016 (UTC)[reply]
  • Would this proposed guideline also apply in cases where a local wiki with bureaucrats, but none of them active, has less strict local policies? --Vogone (talk) 02:55, 10 September 2016 (UTC)[reply]
    Yes, I think so. The standards of the past were much less stringent than what we currently enforce. Of course, if the old 'crats were still around then they could (still) do whatever they wanted. – Ajraddatz (talk) 03:16, 10 September 2016 (UTC)[reply]
    I mean cases like some of the Wikiversities, which don't even require a "RfB", or Spanish language Wikipedia (this is a hypothetical one, since it's highly unlikely this wiki will ever reach such a low level of activity) which doesn't distinguish between administrator and bureaucrat permissions. Would that mean these systems all automatically "die" in case none of the current bureaucrats bothers to fulfil requests? --Vogone (talk) 11:48, 10 September 2016 (UTC)[reply]
    I suppose so. I think it's important to have a uniform standard when stewards are granting the permissions. How could we possibly justify giving bureaucratship after 100 supports and 100% support ratio on one project, but then with a simple request and one support on another? It doesn't make sense. Once they are big enough to have local crats, then they are free to do whatever they want, but until then I think that there needs to be one standard. – Ajraddatz (talk) 16:17, 10 September 2016 (UTC)[reply]
    All of this makes sense, but the traditional fear of stewards to action on wikis where local users exist could make wikis come to a halt. I am speaking out of experience, we had such a situation on betawikiversity where such processes took up to 6 months until a steward who acted on requests has been found. Promoting a local user to do the actions might feel "better" to some stewards than "intervening" and taking over the bureaucrat tasks despite some users still being assigned to the bureaucrat local group. --Vogone (talk) 17:56, 10 September 2016 (UTC)[reply]
  • Support Support strongly. When stewards have given out crat rights generously and prematurely in the past with the rationale "trusted user" (think several years ago), often one of two things happen: 1) the candidates have not demonstrated that they are committed to the project, and subsequently go inactive (the end result is a lot of confusion caused by local users looking for assistance from inactive crats, followed 2 years later by AAR), or 2) without a lot of community scrutiny, we find out that the crats aren't so "trusted" after all, and start handing out administrator rights like candy, or use their power as the sole bureaucrat for intimidation and to control the wiki and its content, since they can appoint whomever they want as admins and can keep anyone blocked. Stewards are often powerless to intervene in these situations, and they are forced to direct them to start a RFC on Meta, which is full of all sorts of complaints about admins abusing their privileges on small wikis. The sad truth is that nobody really cares about RFC, which is basically a giant trash can disguised as a complaint box; the RFCs eventually get closed as inactive after 2 years, and action is rarely taken (I can only think of 3 cases in the past several years where stewards have done anything, and this was after several weeks of prodding from the community, much of it justified). Will this proposal solve the problems of 900+ Wikimedia wikis? No, but I firmly believe this is a step in the right direction. --Rschen7754 03:40, 10 September 2016 (UTC)[reply]
  • Support. --Krd 05:37, 10 September 2016 (UTC)[reply]
  • Object I think this RfC lacks some other interesting questions. What the requirements for a candidate should be to run for an RfB? What the requirements should be for voters to be able to vote on a RfB? We surely don't want votes flooded with votes from accounts with 1 to 30 edits, so we have to discount them and again go back to our own judgement and practice, which is what this RfC seemingly tries to avoid. I oppose 80% support as it's overkill, even more when bureaucrats have been progresively loosing rights, and would require 75% as in RfAs. I'm content with requiring at least 10 voters, but we should state clearly who is entitled to vote to avoid botched or manipulated votes. —MarcoAurelio 10:29, 10 September 2016 (UTC)[reply]
    @MarcoAurelio: WRT requirements for voters, I have already established that above based on current practices - i.e. defined that eligible votes are broadly speaking active on the project outside of the RfB. I don't feel that a strict number is useful or needed, but rather that can be left up to the judgement of the steward closing the request. It's pretty clear to us already who is an active member of the community on these requests, and who isn't, and I don't see any indication that we've had difficulty figuring that out in the past. We've never had requirements for bureaucrat candidates before, but I think a sensible one would be for them to hold either permanent adminship, or temporary admin for a year which would then become permanent automatically upon passing the RfB. Finally, the 80% mark is really just a number that's slightly higher than the 75% usually required for admin, and I am not fixed on it at all. It is also not an issue in most/all cases, since the requests come to us with 100% support but then we start discounting votes. Also, this is meant to be an RfC and discussion - why just flat out oppose, rather than work towards a better solution? What do you have in mind? As I said above, this isn't a fixed proposal. My goal here is to emerge with something usable, not get a number of supports and opposes for my exact wording. – Ajraddatz (talk) 16:11, 10 September 2016 (UTC)[reply]
    I agree establishing fixed edit count requirements and similar things would not be too useful. And whether it's 75% or 80% is mathematically not even a difference in case of 10 participants (in both cases 8 supporters would be needed). In fact, on small wikis (with 10-20 contributors) it's even more of an issue if 2 people oppose promotion than on a wiki with 500 contributors. --Vogone (talk) 17:42, 10 September 2016 (UTC)[reply]
    @Ajraddatz: You said, I propose that in order for a wiki to gain local bureaucrats, there must be an RfB process lasting for a week in time, during which at least ten active, local users must support the candidate, and there must be 80% support overall. This process would also be subject to local wiki policies, though those policies could only be more - not less - restricting on whether or not a candidacy was successful. I'm fine with that but with requiring 80% support, which I think we need 75%, and leave only such high threshold to advanced sensitive permissions, specially since local policies, according to your proposal, can't be less strict than this. If we start requiring 80% for bureaucrats somebody will come later and require 85/90% for CU-OS, or 95/100 for steward. Where did I made a flat oppose? I proposed changes and I stated my objections and my support to certain provisions, so it wasn't certainly a flat oppose. It was not even an oppose. Happy to engage in further discussion to get this rolling. I think that we also need a provision stating that if a bureaucrat has been requested to do some right changes and he's not done so in X time, stewards can do it. Best regards, —MarcoAurelio 10:02, 11 September 2016 (UTC)[reply]
    Also, no bureaucratship for no permanent admin. —MarcoAurelio 17:17, 11 September 2016 (UTC)[reply]
    Good ideas, actually. No issues lowering support margin to 75% (indeed that makes sense as a "floor"), and agree that permanent adminship should be a requirement as well - we have fewer issues with that as well, so we might be able to get away without another discussion on defining standards for it. – Ajraddatz (talk) 00:17, 13 September 2016 (UTC)[reply]
  • I'm a big fan of the idea that bureaucrats need admins and that advanced right holders should come in pairs to prevent centralization of power in the hands of one individual (yes, bureaucratship should not come with any power but rather should be measure of trust and the power should remain with the community, but it not always it so). So I think that levels of support are really not a good measure of whether a bureaucrat is appropriate. I suggest that the requirement for assigning the 'crat should be 5 admins and that there be two bureaucrats at least. Snowolf How can I help? 15:44, 11 September 2016 (UTC)[reply]
    • What if one of the bureaucrats goes mostly inactive? That is a flaw in how the similar policy works with CU/OS (which probably should be addressed too at some point.) --Rschen7754 16:44, 11 September 2016 (UTC)[reply]
      • That is indeed a problem, which could be partially solved by changing to "two active bureaucrats", however I was trying to be consistent with the CU/OS policies and leave inactivity requirement for a different time. Snowolf How can I help? 00:10, 13 September 2016 (UTC)[reply]
        • CU/OS deals with tools that cannot be scrutinised by regular users. Bureaucrat and admin rights have no such components, so I'm not sure why there would need to be multiples for the same principle of mutual control. The community can always report issues (to nobody right now), since they can see all in that case. – Ajraddatz (talk) 00:17, 13 September 2016 (UTC)[reply]
          • Bureaucrat actions are publicly logged, but that doesn't solve the problem, given the high barrier that there is to providing effective accountability. It is hard to even get a consensus of stewards to act in even the most clear-cut cases of admin/crat abuse; I've seen the discussions on stewards-l and off. That leaves the single crat with virtually absolute power. --Rschen7754 00:44, 13 September 2016 (UTC)[reply]
            • +1 to this statement which also aligns with the "fear" I described above. --Vogone (talk) 01:07, 13 September 2016 (UTC)[reply]
              • I'd propose to state clearly that when the bureaucrats for a project have been requested to perform a duty for which they have been elected for (ie: bot flagging/deflagging, promotion of admins), and such bureaucrats once asked individually or in the relevant request page, and are inactive for 2 weeks, stewards can freely assume the role and perform the actions requested if there's consensus to do so. That'd cover inactivity. On the other hand, what about bureaucrats not wanting to perform an action because they don't want to and such inaction is not supported by policy? Should they appeal to us? Under which policy? —MarcoAurelio 07:40, 13 September 2016 (UTC)[reply]
                I would like to suggest that the discussion about stewards acting as bureaucrats on wikis where there are appointed positions should be a separate discussion, 1) because it isn't necessarily small wikis, and 2) as its implementation requires comment from the broader populace. Such a change in stewards' ability to act in a filled role has alignment with appointments, though it also has an alignment with AAR. My opportunity to comment clearly aligns with AAR reviews. That said, I am in favour of granting stewards the ability to act in a role, and believe that clear expression of what is reasonable time to wait prior to escalating a request to stewards should be stated.  — billinghurst sDrewth 05:23, 5 October 2016 (UTC)[reply]
  • This is a difficult question. This topic has been discussed at least since Requests for comment/Minimum voting requirements, of which I am always reminded when a bureaucratship request comes up on SRP. As MarcoAurelio says, the problem is that many different and difficult things (like voting requirements) would have to be defined in order to be able to make a clear policy like "10 votes, 80% support" about it. I think that the current situation in which stewards decide without a clear written policy does work well, but I would also not be opposed to the creation of some policy/guideline which codifies the ideas that are behind the decision-making already. I would appreciate if more people commented on whether they think there should be some policy or not. --MF-W 23:09, 14 September 2016 (UTC)[reply]
    I am no fan of codifying every practice myself, but it would be nice to have something to link to when requests for bureaucratships arise. Maybe even a description of current practice, rather than hard-and-fast rules. – Ajraddatz (talk) 23:24, 14 September 2016 (UTC)[reply]
  • Oppose. This proposal looks like a solution in search of a problem. I see absolutely no problem with how the system works now: we do not promote bureaucrats on small wikis without a strong community consensus (whatever you mean by this), which in practice means almost never. This proposal, on the one hand, seeks to impose some rather arbitrary requirements, which will change little in this practice but can be open for gaming. On the other hand, some other restrictions like requiring wikis to have at least two sysops/bureaucrats will be likely counterproductive and, in addition, has no basis in any policy or practice. Their imposition will require a Wikimedia-wide consensus, which this RFC with a low number of participant will not provide. Ruslik (talk) 20:39, 17 September 2016 (UTC)[reply]
In the past year there have been 10 requests for local cratship that have been declined by stewards with no policy justification because we felt that there was not enough of a local community to warrant it. We had no policy basis to make such a decision. s says "stewards have responsibility for technical implementation of community consensus" - how can we possibly justify our practices in light of this? This is an attempt to codify our existing practices, to provide some sort of actual basis under which we can act. If you think that this RfC should be better advertised, then you are of course free to help advertise it. – Ajraddatz (talk) 20:47, 17 September 2016 (UTC)[reply]
"how can we possibly justify our practices in light of this?" Very simple: there was no consensus. Ruslik (talk) 19:16, 18 September 2016 (UTC)[reply]
So a local vote with 18 supporting votes, and no opposition, counts as no consensus? We have currently no basis to say that. – Ajraddatz (talk) 19:21, 18 September 2016 (UTC)[reply]
Comment Comment historically, there have been clearly problems where bureaucrats have been allocated rights far too early in the history of a wiki — demonstrated examples of nepotism, personal rather than community opinion, power-trips, disappearance, and the like — and these problems have contributed to lack of growth of a wiki. As a consequence there has followed a general reticence to allocate bureaucrat rights due to the lack of size of a community. There has even been situations that people have an expectation that having bureaucrats is reputational and on its own important to a wiki; which could be considered unhelpful or overly introspective.

As the aspects of a bureaucrat are now reduced there should be a clear demonstration that bureaucrats are required, ie. appointing admins, granting other local rights. To do that I would think that initially there should be an idea on minimum number of admins (10???) that a community has as a demonstration of community need for a 'crat, rather than a focus on the number of votes to appoint a bureaucrat. A community with suitable number of admins will, in itself, generate enough traffic in votes, and in the appointment of admins & bots to clearly justify the appointment.

As Snowolf said we do need to consider multiple appointments, as once 'crats are appointed stewards become emergencies.  — billinghurst sDrewth 05:13, 5 October 2016 (UTC)[reply]

  • Support Support 10/80% per nom and I consider that even existing bureaucrats on smaller wikis should also be subject to a vote of confirmation in the same way as proposed here. If unable to be supported by at least ten active users or 80% of eligible voters, the bureaucrats should quit. Most Chinese wikis with few active users have zero bureaucrat.--Jusjih (talk) 17:08, 5 October 2016 (UTC)[reply]
  • I like the idea, but can't support this RfC because of the numbers (so per Snowolf, Ruslik0 and Billinghurst, et al). Trijnsteltalk 17:55, 11 October 2016 (UTC)[reply]
Comment Comment. Looks a nice proposal. However, I am not confident that would fix the problems encountered just by establishing a threshold for approval (i.e. 80%) and defining who are those active users that could partake in such requests for bureaucratship. I also think 80% is overkill, anyway. We should go further, and define how long nominees should have been on a small wiki for local voters to determine whether their candidates are trustworthy or not (as pointed out by Adrian). Will it depend on the size of the wiki? on its number of edits a day? We should also bare in mind that not every discussion process is mandatorily a vote, when the approval is simply determined by surpassing a numerical threshold. In some wikis this process may require an evaluation of rationales presented. So, how should we close such discussions? What should we consider for? Furthermore, should we always endorse the right of every Wikimedian with an account to participate as long as they are long-term editors?, even if they don't have any contribution on that wiki? or not? Could local administrators help us handle things in nominations where consensus is unclear and there is no threshold? RadiX 05:31, 15 January 2017 (UTC)[reply]
Comment Comment Rogue crat has a greater ability to intimidate community & kill participation than a rogue sysop would. Thus some number of active sysops prerequisite (10?? per billinghurst above & Small_and_large_wikis#Principles) seems reasonable. A mandatory confirmation in 2 years' time might be a good deterrent from sysop/crat abuse too.--Frhdkazan (talk) 15:07, 28 January 2017 (UTC)[reply]

Semi-arbitary break[edit]

  • If you don't want non-steward voices here, just hat this. But as a small-wiki 'crat, perhaps I can provide a slightly different point of view.
Background information not directly addressing question, but so that you know where I'm coming from
  • As a note, the wiki on which I am sysop and 'crat, Ladino (Judeo-Spanish) Wikipedia, more or less follows the approach of the wiki which to a great extent is its parent, Spanish Wikipedia. All four of us who are sysops are also 'crats. At the moment I'm the only one really active, through two of the other three do appear from time to time, and I can reach them by email if I need them.
  • When I was elected, the vote was probably borderline by the stewards' normal standard for making my admin status permanent. (By that, I mean that the number of votes was small. But there were no objections, and the RfX stayed open about two weeks.) But because the current sysop-'crats existed, they were able to clear the election and promote me.
  • I have now been a sysop and 'crat on ladwiki for about 15 months. I have effectively not been asked by others to undertake any 'crat-only tasks in that period. I undertook one 'crat-only task on my own: I received consensus (well, lack of objection) to deflagging some bots on ladwiki. The bots were uniformly old interwiki link bots, none had made a single edit on ladwiki in at least three years, and I notified all bot owners ahead of time.
  • On the one occasion I knew I would be away, I notified the SWMT so that it would keep an eye on admin tasks while I was away. I assume the stewards would have noticed the Wikibreak templates on my talk page and would have acted if a 'crat task had been necessary. (Break was 1.5 weeks long, not massive.)
  • I also hover around the new Jamaican Patois Wikipedia, where my most significant role has been to manage the (temp) sysop elections there. Those were all closed by stewards as temporaries, and rightly so, but I wanted to make sure the elections were clean.
In that context, then, let me suggest the following:
  1. Someone mentioned the question above of what happens when all 'crats go inactive. Regardless of the rest of this discussion, I would strongly favor the creation of a non-responsiveness period, after which stewards (or, in case of sysop tasks, global sysops) would be empowered to act.
    • I would construe non-responsiveness fairly tightly, of course: if a 'crat or sysop responds that s/he is unwilling to fulfill a request, that's not non-responsive, and that requires a different discussion.
    • I also don't know whether the non-responsiveness period should be two weeks or a month. But certainly a month should be more than enough time, and after that stewards should certainly be free to act.
    • Finally, I'm not sure if my informing the stewards that I would be away, for example, would be sufficient to let you act more quickly if I really technically have other 'crats working with me. Quite possibly it wouldn't.
  2. I think the idea of having a fixed number of permanent administrators at the time of the initial appointment of 'crats is also a good idea.
    • This would de facto solve a lot of the other problems. Until that point, only stewards will have promoted sysops. And you are already reluctant to promote permanent sysops until communities reach a certain size. So that, by itself, will prevent the promotion of 'crats until the community reaches a certain size.
    • Once a community is sufficiently large to have four (say) permanent sysops, then other numbers (like 10/80% or 10/75%) are less likely to be problematic.
  3. I think that for appearance's sake, the first two 'crats should probably be appointed as a pair, for reasons stated above. But also for reasons stated above, I don't think it matters too much if one 'crat ends up going inactive. More damage, in some ways, can really be done by rogue sysops than rogue 'crats. Rogue 'crats generally can't deflag sysops or other 'crats any more, after all.
    • One change that might make sense in this setting is to prohibit 'crats from promoting others to 'crat unless there are at least (four?) sysops.
Look, there are two important truths to this whole question that are going to require an explicit solution if you are that worried about rogue 'crats:
  • As long as small wikis have 'crats—whether as a descendent of an unbroken line of 'crats from earlier times, like I am, or because you admit new 'crats consistent with this discussion—it will be hard to prevent abuse outright if a 'crat is bound and determined to be abusive. So either (a) one forbids the possibility of 'crats in small wikis, or (b) one sets up a more rigorous appeal process to the stewards.
  • I think you'd be better off focusing on a process that actually allows stewards—perhaps augmented under supervision by global sysops or global rollbackers, if they speak the language—to feel they can get involved without killing the autonomy of the small-wiki community. If pure small-wiki community autonomy is truly a higher priority than autonomy-with-oversight, then ban small-wiki 'crats outright and minimize the possibility of abuse in the first place. If autonomy-with-oversight is reasonable within the context of the Wikimedia community, then create a process with enough teeth that you can actually exercise the oversight function. I do believe that such oversight is within the remit of stewards, and I'd encourage you to move in that direction. StevenJ81 (talk) 18:09, 15 September 2016 (UTC)[reply]