Requests for comment/Minimum voting requirements

The following request for comments is closed. This RfC has long reached the point when any possibly agreed consensus is too far in the past (most of the sections date back to 2010 and there's been virtually no activity since 2011) to ever be enacted. Should somebody feel the subject of this RfC needs to still be settled, they should start a new RfC, to gather fresh opinions and fresh consensus. Snowolf ^{How can I help?} 05:27, 17 July 2013 (UTC)[reply]

::::Closed this discussion, see draft below fr33kman 05:57, 7 March 2011 (UTC)[reply]

What this is

This is a proposal to create a policy specifying minimum numbers and approval percentages to promote users on projects to administrator or bureaucrat without local bureaucrats.

Why this is needed

Stewards are currently charged by the Stewards policy to not decide, yet there is no policy or guideline in place specifying when consensus has been reached, nor when the consensus is considered valid.

Examples: Someone wants adminship on a project with no local admins, they vote for themselves. Most users would not think this constitutes a meaningful election, but certainly 100% approval from 100 different users would. Would three users voting for someone be enough to appoint a bureaucrat?

What we need

Minimum requirements to elect Importers

Suggestion:

Temporary: advisory notice with no opposes for temporary

...or 1 + 1/2 –SJ +

Permanent: Three supports over a week for permanent access,

What about the overall support? 50%? --MF-W 16:31, 8 March 2010 (UTC)[reply]

3 + 1/2 –SJ +

For temporary transwiki import rights: notice on local community with no opposes. For permanent: 3 voters + 2/3 support over a week. — Dferg (talk) 18:18, 17 April 2010 (UTC)[reply]
We should really only be granting transwiki import rights. XML import is insecure, which is why we don't use it under normal circumstances. – mike@meta:~$ 01:29, 13 August 2010 (UTC)[reply]
Agree. --dferg ^{☎ talk} 15:20, 26 September 2010 (UTC)[reply]
I suggest 2/3 support ratio without any lower limit on the number of supports. It does not make sense to grant it temporally (unless specifically requested) as this is an insignificant permission. Ruslik 11:33, 12 July 2011 (UTC)[reply]

Minimum requirements to elect temporary Administrators

Suggestions:

Three months: Advisory notice, no oppositions.

...or only one support. --MF-W 16:31, 8 March 2010 (UTC)[reply]

No opposition, or at least 1 + 1/2 (50%) support. –SJ +

IDK, 50% pro implies 50% con and that's a significant amount of opposition. fr33kman 01:24, 11 October 2010 (UTC)[reply]

Six months: Election, at least two supports, 80% support

80% for 2-4 votes means all must be supports. I think 2/3 support is enough. --MF-W 16:31, 8 March 2010 (UTC)[reply]

Agreed, at least 2 + 2/3 support.

Make that at least 1 vote. You're making people run to meta time-and-again. Seb az86556 03:09, 2 August 2010 (UTC)[reply]

A year: None, either a six month temporary at most or grant permanent adminship.

Agreed, can get 6 months repeatedly. –SJ +

Yes, 6 months min! 3 months is useless. I'd actually prefer 12 months but ... fr33kman 01:24, 11 October 2010 (UTC)[reply]

A means of privately opposing should be offered, per comments elsewhere on fiefdoms. Triona 08:41, 3 September 2010 (UTC)[reply]

Whenever it continues, no opposition or at least one and over a half support. Just saying "one vote at least" seems fine in the first glance though, but for Wikipedia-sister, it could be too high in some occasions. I have seen some sister projects with one and only administrator and active contributor. Even on that wiki there will be some needs for using the tool, mainly for localization, and sometimes removing spams. --Aphaia 17:49, 26 September 2010 (UTC)[reply]

Minimum requirements to elect permanent Administrators

Suggestion: A minimum of five supports and 75% overall support.

I think 2/3 support is alright. Individual wikis will choose their own policies; since en:wp has quite a high standard and is only at 80%, requiring all wikis to adopt 75% seems overkill. –SJ +

Is this really a problem? How many wikis have such conflicts? --Nemo 09:15, 13 August 2010 (UTC)[reply]

If you mean, "How many wikis need such guidelines", I'd have to point you to SRP any given day. There are, at this moment, two SRPs for perma-admin rights which started out as two votes. I really like the five vote minimum thing, but would go lower if they allowed for automatic removal of inactive admins. Kylu 00:59, 15 August 2010 (UTC)[reply]

I think, 2/3 is fine enough. No need to overly socialize the administrator flag. Easy come - easy go. As for minimum of five supports, I think it's right. Dr Bug (Vladimir V. Medeyko) 14:23, 26 September 2010 (UTC)[reply]

I'd like to see a requirement for a minimum of two permanent admins per wiki for the same reason it is required of CUs. We've had numerous cases which might have been avoided had this been in place. Currently, we are granting people fiefdoms - we should create situations where that's less likely. – mike@meta:~$ 01:31, 13 August 2010 (UTC)[reply]
Yes, this may be sensible (even if it's not the same as CUs, because sysops actions are publicy logged), but not every wiki may be able to find two sysops, unless one is a "fake" sysop (cf. 'crats below). --Nemo 09:15, 13 August 2010 (UTC)[reply]

What about those that currently have only one? Seb az86556 10:34, 15 August 2010 (UTC)[reply]

I propose that those should be converted to 6month renewable temporary sysopships until the project meets minimums both in number of sysops and community participation (see below) Triona 08:18, 3 September 2010 (UTC)[reply]

I think it doesn't make too much sense, as administrator's actions are public. Dr Bug (Vladimir V. Medeyko) 14:23, 26 September 2010 (UTC)[reply]
I agree with Dr Bug; it is easy to discover when an admin does nonsense, and in the few cases we had when people were trying to (or had already) seize a wiki, they were desysopped by stewards quite soon after the discovery. Two required sysops could have fun blocking each other, but don't do any control that could be more useful than the control the log-reading community does (as opposed to the control two CUs who have access to the secret logs perform on each other). --MF-W 20:06, 12 October 2010 (UTC)[reply]
I'd like to see a requirement for a certain size of community (judged by number of unique editors in good standing within the last 30 days) with the timeframe for a vote dependent on the size of the community:
- Less than 50 active users (as defined above). Temporary sysopping only.
- Less than 100 active users - vote has to be open 30 days. Must already have recently held one 3month or longer term as temporary sysop, or be at least 3 months into such a term. (This is to insure that the community on a small wiki, which may be especially vulnerable to domination by an abusive administrator, is familiar with and comfortable with the manner in which sysop rights will be used by the candidate)
- Less than 500 active users - vote has to be open 14 days.
- 500 or more active users - Per local policy, or 14 days.
The point of this would be to make sure that there is enough of a community that the concept of "broad community support" is meaningful, and to allow enough time for exposure to the community. Triona 08:44, 3 September 2010 (UTC)[reply]

I don't think it's a good idea. Small wikis need administrators, and 20 active users is enough to start from. Dr Bug (Vladimir V. Medeyko) 14:23, 26 September 2010 (UTC)[reply]
Small wikis have admins as part of the global sysop wikiset. What you need is trusted people who can read and write the language. It may take time to build that trust, and we've seen what happens when you elect people before knowing them well. Kylu 15:09, 26 September 2010 (UTC)[reply]

Per Mike's comment on fiefdoms, I'd also strongly like to see that contributors to small projects have the option to oppose in private, so as to prevent false consensus through intimidation. Triona 08:44, 3 September 2010 (UTC)[reply]

These numbers indeed are way too high. Apart from definition problems (what is an active user? how many edits in how much time? good standing - who defines it?), 50 users active/here: voting is a number not even needed for electing checkusers. There are very active communities that only have around 5 'permanent contributors' who surely would complain if they had to get another 45 users in order to ever gain permanent sysop status. Also, they don't need votes open for 30 days or previous temp statuses to become "familiar with and comfortable with the manner in which sysop rights" will be exercised, but there are also often less active communities where electing sysops leads to great problems. IIRC, the purpose of this RFC was to define rules when sysops/crats can be elected by small wikis for permanent status, because stewards don't have a policy to follow so far; and these small wikis are mainly not fearing vandals taking over their wikis but are complaining why they aren't allowed to have sysops or a bureaucrat. Therefore, it might be good to set some basic rules likes the proposed minimum of five supports and 2/3 overall support which can then be modified by the communities according to their needs, e.g. if you have fiefdoms, introduce unanimous secret elections blabla etc. The important thing would then be to determine the way how the projects can modify the general policy (how many votes, ...). --MF-W 20:06, 12 October 2010 (UTC)[reply]

The spirit of this is accepted, but the numbers are way too high. Mike's proposal of at least two admins makes more sense. Seb az86556 16:06, 3 September 2010 (UTC)[reply]

I will express some of my thoughts here. I'm from small wikis (bnwiki and bnwikt), and a temp sysop in bnwikt. In my view, 5 supports with overall 80% support is enough for any wikis. But for the wikis with 20-30 active users, it shouldn't be more than 3/4. Users who extended their adminship several times and the action log is not disputed (as it is public so we can verify) can be considered as trusted, and we can grant them for permanent adminship for 2/3 support and no oppose from the local discussion page. — Tanvir • 04:56, 26 October 2010 (UTC)[reply]

On a project which are using the Proofread Page-Extension, there is critical to have somebody with the Administrators-tools. There is a lot of maintanance around the extra namespaces and MediaWiki-templates, that cannot be handled without such tools. I have never seen any need for 'admin-oversight' on such a wiki. The conflicts you find on Wikipedia-projects, selldom exists on such projects. -- Lavallen 14:37, 14 May 2011 (UTC)[reply]
My suggestion is that for promotion we should set a 75% support ratio over a standard period of one week, prorrogable to another week if no discussion has occured or the result is borderline. A minimum of 5 users must participate in the RfA (either supporting or opposing) and there must be 2 sysops per wiki for mutual oversight. 80% of support and 2 weeks of discussion seems overkill to me. My 2 cents. -- Dferg ^{☎ talk} 09:04, 11 July 2011 (UTC)[reply]
I suggest 2/3 support ratio and at least 5 supports from users who were auto-confirmed (or similar condition) when the discussion started. I also want to note that in enwiki the normal promotional threshold is 75% with 70-75% being the bureaucrat discretionary range. So 2/3 for a small project looks reasonable. I do not think there is a need to have two administrators: in case of inactivity there are global sysops. (Bureaucrats are different as there is no global bureaucrats.) Ruslik 11:44, 12 July 2011 (UTC)[reply]

Minimum requirements to elect Bureaucrats

Suggestion: 15 votes over a two week minimum period, 80% support. Two bureaucrat minimum per project, and one year of inactivity results in loss of permissions.

10 + 3/4 support, with 2 bureaucrats needed before either is promoted. The elections can be staggered; one crat can be elected but not promoted until a second election completes. –SJ +

I think that two bureaucrats should not be an obligation. Bureaucrat abuse can be only in granting or not granting sysop or bureaucrat flags without community consensus. If a crat clearly refuses to grant a flag when community supports granting this flag, it can be granted by stewards under conditions mentioned above. If a crat grants some flag without community consensus, the second bureaucrat will not be able to help anyway. If one bureaucrat resigns, why the project should wait until someone else will be elected? I think that if the project wants to get a crat who is in good standing, why not? — NickK 22:12, 14 March 2010 (UTC)[reply]

10 + 3/4 support. "no 2 bureaucrats" per NickK . SergeyJ 22:37, 14 March 2010 (UTC)[reply]

I don't see the point of automatic removal: this is something which local projects definitely want and need to decide themselves; if inactive bureaucrats cause problems to stewards, then the solution is the following section.

No 2 'crats minimum per NickK.

15 votes are way too much, and perhaps even 10. With such requirements, we would encourage "meatpuppeting" from big projects. This may be not too harmful (e.g. you can imagine that the local it.wikiquote 'crat can be a it.wikipedia 'crat or another it.wikipedia trusted user elected with some 10-15 votes from users not active locally so that the community is initially "supervised" and counseled by a trusted almost-local user) but I don't know if it's useful; maybe it would be better to ask 5 votes but from really active members (say, at least 500 or even 1000 or 2000 edits) to avoid sock- and meat-puppeting (and maybe a 4/5 or even 9/10 support); or maybe both reuirements, as alternatives. Example: some Italian sisterprojects are fairly active, but the core community has usually 5-7 members who participate in such meta-discussions and votes (which are always unanimous), and that's fine, I don't see why we should force users who don't like it to participate. --Nemo 08:50, 13 August 2010 (UTC)[reply]

That's the issue, really... it's not so much that we want a huge number of "votes" as it's that in selecting a bureaucrat, we're giving up any ability to mediate on the local project: The actual permissions of a bureaucrat are rather boring: Rename users, assign admins or new bureaucrats, and flag/deflag bots. The position itself is slightly more than this, though, in that bureaucrats tend to be the "voice" of any non-arbcom-having project and are generally trusted by the local community to weigh and determine consensus. Getting checkusers or oversighters? Generally it's the bureaucrats who tally the votes, strike some as invalid, and represent their project to the stewards. Having a large local population to spread around such social power is far more beneficial, I think, than making it easier to get such permissions in the first place.

Not to give anyone nightmares, but could you imagine if I were the only steward, for instance? Yikes! :D Kylu 01:09, 15 August 2010 (UTC)[reply]

I think 70%/10 supports should be ok. No need to have at least two bureaucrats, I think, because bureaucrats actions are public. The better way, I think, that stewards shouldn't reject to commit respective actions in wikis that have less than two bureaucrats. Dr Bug (Vladimir V. Medeyko) 14:28, 26 September 2010 (UTC)[reply]

Admin actions are public too, but it's still possible to abuse one's admin rights. A bureaucrat action like "Let me get my ten buddies on here, we throw together a 'successful' bunch of RfA's, then close them as WP:SNOW before the locals have any idea what's going on, and we'll own the project" is easily detectable but terrible to fix (policy-wise) after the fact, since we don't have anyone who is actually allowed by policy to decide that this sort of abuse needs to be corrected. Stewards have the buttons to do so, but we can't manage to get people to understand that one or two votes just isn't enough. Now, put a dispute resolution mechanism in place globally with the authority to revoke the permissions of abusive users and I'll change my stance. Kylu 15:03, 26 September 2010 (UTC)[reply]

75% support with a minimum of 15 votes in support. Minimum 2 bureaucrats per wiki to be removed if completly (no edits/logs) inactive in 1 year. --dferg ^{☎ talk} 15:15, 26 September 2010 (UTC)[reply]

I would prefer 15 votes + 2/3 support. Some projects have a local policiy, which requires 2/3 support. Holder 16:04, 2 October 2010 (UTC)[reply]
Speaking from the candidate's view, I'm feeling much more supported by 10 pro's and 0 no's than by 10 pro's and 5 no's (= 15 votes + 2/3 support). --Murma174 08:43, 29 October 2010 (UTC)[reply]

Minimum 10 votes with 80% support. 15 is too many in my view. — Tanvir • 04:33, 26 October 2010 (UTC)[reply]

10 votes + 80% support sounds reasonable IMO. But what to do against abuse, as Kylu mentioned above? I'd say, abuse should be discussed individually on meta. Stewards have the power to grant the rights, why not withdraw them with good reasons and consensus? A bureaucrat doubtless is a sort of "voice" of the project, that's why he/she should receive 10 votes / 80% support not only once in his lifetime, he/she always should be backed by a majority of users. --Murma174 07:00, 27 October 2010 (UTC)[reply]
I can't speak for other stewards, but I'm not sure I'd be comfortable wielding the (political) power to yank bits from anyone who is simply unpopular, without some sort of local policy in place already to allow for it. Even limited as we are, there's always potential for abuse and I'm loathe to expand any community authority for stewards. The funny thing is, the best other stewards I know are the best because they're process wonks and absolutely terrified of doing anything remotely against consensus: I'm not sure if the concept of abusing the mighty powers we wield (haha) has occurred to some of them yet. They're probably still busy decorating the inside of the lamp, though... Kylu 03:55, 28 October 2010 (UTC)[reply]
10 votes + 75% support by community + 100% support by all local active (30 days) admins. There is no need for two bureaucrats because a second bureaucrats cannot "control" the first one (no deadmin, no log review like OS) Merlissimo 09:02, 28 October 2010 (UTC)[reply]
Might it be easier to state that as "10 votes + 75% community support, plus active local administrators may veto the promotion." perhaps? Kylu 21:09, 15 November 2010 (UTC)[reply]

I support -any- minimum, but I would like to see at least 15 and 75% to be honest. Ottava Rima (talk) 23:23, 17 November 2010 (UTC)[reply]
I have to quote almost verbatim Nemo's comment. I'm a 'crat on it.source and I think that Nemo quoted our situation: in my view when a small wiki takes off 15 votes are way too much, and perhaps even 10; such requirements encourage harvesting votes from bigger projects. This may be not too harmful but would it be useful? If you wanted a fair RfB the usual requirments for voting involve user activity more than some arbitrary amount of votes, but this cannot be applied to newborn small projects unless you appoint temporary adminship or bureaucratship until users get some decent editcount.... I sense some clumsiness in this process.

Example1: it.wikisouce is a fairly active project, but our core community has 5-7 members who actively participate in such meta-discussions and votes (which are always unanimous), and that's fine: I don't see why we should force many users uninterested in metadiscussions or votes to participate.

Example2: vec.wikisource can't count 15 active users because it's been live for too few days, but when it was hosted in oldwikisource everyone knew who was the most acrive user. This user, of course, applied for bureaucratship, but it could take some time before he gets 15 votes (there aren't 15 active users on this projects, so it's a natural consequence if someone came from it.source or oldwikisource): is it useful?

My two cents: When new projects spring out of Incubator or OldWikisource etc. a formal election should involve comments by users from those projects more than a fixed number of votes: nowadays no project achieves its subdomain without months or years of developement by dedicated users controlled by local admins who usually cover important roles in many wikis. In this way, if no objection is raised against a candidate within a week or two, there's no real need for a formal vote. when a project has a 'crat/admin it can quietly go ahead until there's enough population to hold proper votations. εΔ ω 17:35, 22 November 2010 (UTC)

Useful? Since when are we talking about "useful"? This is about rules and regulations... :P (I'm afraid I'm only half kidding, though) Seb az86556 18:49, 22 November 2010 (UTC)[reply]

I would suggest 10 votes supporting the user. --Satdeep gill (talk) 05:01, 2 December 2014 (UTC)[reply]

When are local bureaucrats considered non-responsive?

Suggestions:

To remove an inactive bureaucrat: One year of inactivity (automatic)

Inactivity as in, no edits to any Wikimedia project? Then yes. If one is active anywhere and has a valid email, it should be possible to track them.

Strong oppose to this, see above. --Nemo 08:57, 13 August 2010 (UTC)[reply]

To perform bureaucrat functions locally by a steward: One month of no local bureaucrat activity.

Clarification is neccessary: Is bureaucrat activity only a bureaucrat-rights related action or any action/edit by the bureaucrat? I'd prefer the latter. I also suggest that before stewards may perform bureaucrat actions the local crats (active and non-active ones) should be notified; and stewards should wait 3 days then before they act. --MF-W 16:31, 8 March 2010 (UTC)[reply]

+1 –SJ +

Absolutely, every action/edit should be considered. On small wikis you don't have a chance to use 'crat rights every month, even if you're very quick in fulfilling requests. --Nemo 08:57, 13 August 2010 (UTC)[reply]

To bypass a local bureaucrat, either promoting a new bureaucrat when a current one does not follow consensus or removing the local bureaucrat as a result of no-confidence: Two weeks, 15 votes, and 80% in-favor of bypassing the local bureaucrat(s).

This seems too high to me; a quite small minority of 21% can hold 'their crat' even if he destroys the good ambience on a wiki. 2/3 in favor should be enough. --MF-W 16:31, 8 March 2010 (UTC)[reply]

15 + 1/2. –SJ +

I would say that it's better to remove the 'crat or to add another one (if the community can elect one 'crat, it should be able to elect one more), but I'm note sure. What's the usual no-confidence quorum? On Italian language wikis where such a process is defined, to retain sysop/'crat status you have to pass a confidence vote with a 2/3 (or 3/4) majority. --Nemo 08:57, 13 August 2010 (UTC)[reply]

There isn't one, that's part of what this page is for. There's a no-confidence section below though. I'd also like to start some sort of procedure for recalling other positions, when there's not one locally, but I don't want to be the only one writing sections here. For that matter, I'd like to make some sort of recall procedure when a steward goes nuts too, but as it's not a matter regarding local rights, I'm not sure this would be the appropriate page for that discussion. As much as some users might claim I'm a terribly evil and unethical person, I'd be more comfortable were there some process of kicking my sorry arse out than simply waiting for the next confirmation. :) Anyway, there would be the obvious exemptions of "system administrators" and "staff", as they're employees and such review of their actions is in the purview of the Foundation itself, of course. Kylu 01:38, 15 August 2010 (UTC)[reply]

I'd like to suggest everyone to word carefully. Technically "no edit" isn't same with "no sysop/'crat" action, and you would like to make it clear which you really want to say, or to state explicitly each local community could give their own definition: while it isn't likely to happen for b'crat, admins can make actions without editing wiki pages (occasional blocking, speedy deletions etc.). I've seen a confusion and dispute around these two terms; a wiki community whose automatic removal policy said "no edit during x month" has argued whether an admin who operates a bot blocking open proxies through his admin account (so a heap of admin actions he has made) could be seen as having "edits" or he should be desysoped because of "no edits". We'd like to avoid such a drama widely, eh? --Aphaia 02:11, 15 August 2010 (UTC)[reply]

I think 6 months of no editing on a project should warrant de-cratting but 1 year is good too. Ottava Rima (talk) 23:24, 17 November 2010 (UTC)[reply]

Removal of inactive administrators on small projects?

What qualifies as small? fr33kman ^{t - c} 03:23, 15 August 2010 (UTC)[reply]

Maybe the small wikiset? — Tanvir • 05:09, 26 October 2010 (UTC)[reply]

Maybe "projects with only inactive administrators"? Kylu 01:18, 27 October 2010 (UTC)[reply]

Naw, that's not the point. The point is the security risk of having dead accounts hacked and have some vandal run amok. Seb az86556 10:23, 27 October 2010 (UTC)[reply]

Suggestion: Five votes, 80% approval, over two weeks.

Seems ok to me, but what is a "small project"? Maybe a wiki where global sysops have access? --MF-W 16:31, 8 March 2010 (UTC)[reply]

4 + 2/3. –SJ +

Is this the minimum to remove one sysop or to create a local policy whatsoever to automatically remove inactive sysops? I don't see the point of removing individual sysops due to inactivity. 5 + 80% seems fine. --Nemo 09:02, 13 August 2010 (UTC)[reply]

Some people strongly oppose to remove "inactive" admins (I've met oppositions on my home wiki, EnWQ too), and consensus may vary from wiki to wiki, so I see here necessity to define "small wiki" and inactivity much more detailed.

I'd like to add "either without no local policy on deadminship or explicitly agreeing to opt-in this deadminship policy" to "a wiki where global sysops have access". Small wikis could have their own policy, and some active wikis which are not automatically taken care of by g'admins might opt-in global adminship. --Aphaia 02:22, 15 August 2010 (UTC)[reply]

Suggestion: Inactivity for more than a year -> automatic removal.

Suggestion: Inactivity for more than a year -> automatic removal. Seb az86556 03:10, 2 August 2010 (UTC)[reply]

I'd think that would go with Removal of inactive administrators on small projects? above. Also, should this be automatic as in "we need to patrol regularly for inactive admins" or "when such an inactive admin is reported"? Kylu 11:44, 2 August 2010 (UTC)[reply]

(Moved) "When reported" of course. And that should refer to logged actions, not some token edit. Seb az86556 23:33, 2 August 2010 (UTC)[reply]

Strong oppose to automatic removal: projects should decide themselves (see also above for 'crats). --Nemo 09:02, 13 August 2010 (UTC)[reply]

What use is it to have people who never do anything?

Etse@chr absent 2004

Gmaxwell@chr absent 2006

ᑏᑎᕉ@iu absent 2006

ᐃᖁᐆᕐ@iu absent 2006

Zanimum@ik absent 2007

and so forth... Seb az86556 20:57, 13 August 2010 (UTC)[reply]

And why should you mind? Some projects like to leave the flag to their sysops even if they're inactive, leave them to do so. E.g., as an it.quote 'crat I would always re-add sysop flag to all inactive sysops, were they removed by stewards. The community wants so, and you can't force the community to remove sysops bits to trusted users. --Nemo 21:52, 13 August 2010 (UTC)[reply]

I understood this as a proposal for projects w/o crats ("on small projects"). Maybe I misread this. Seb az86556 22:09, 13 August 2010 (UTC)[reply]

This is for communities who want to remove the admins, Nemo, because that user is inactive. If there's bureaucrats, they're large enough to already have a policy of some sort in place. We can't actually force anyone to do anything, it being all-volunteer and all. Kylu 22:48, 13 August 2010 (UTC)[reply]

Thank you for the clarification. But if you say that only a "notice" is needed, every user can request the removal, so you can't know if the community wants it. If it's really an issue for stewards (and IMHO it shouldn't, because their "liberty" is always conditioned by active sysops only, so it's better to define "active"), just create a global policy which projects can opt-in with the above-mentioned vote; or just follow the original suggestion of a vote for each sysop the community wants to remove (which would be only a "discount" on usual required majorities, if I understand Kylu correctly). --Nemo 00:28, 14 August 2010 (UTC)[reply]

I was thinking "inactive" as in "no logged actions or edits at all in X amount of time", where X is definable by local consensus or, lacking consensus, a six month default. You're absolutely right though that activity should be defined, and you're in the right place to give your suggestion as to how much activity it should be! :D Kylu 01:00, 14 August 2010 (UTC)[reply]

I'd even be more lenient and say 1 year w/o logged action. I'd say that's reasonable. Seb az86556 09:17, 14 August 2010 (UTC)[reply]

What are you discussing about now? Just the definiton of "inactive sysops" to be used when applying the rule suggested above (5 votes, 80% etc.) or that the requirements to remove a "inactive sysop" should be that after 6 months / 1year /... of no action, anyone may request that stewards remove the sysop's rights? --MF-W 18:30, 14 August 2010 (UTC)[reply]

Good point. Let's split this Seb az86556 00:31, 15 August 2010 (UTC)[reply]

Definition of "inactive"

(this section is for opinions on the definition of "inactive sysop" to be applied if/when one or both of the above come into effect)

Suggestion: No logged action in 12 months. Seb az86556 00:31, 15 August 2010 (UTC)[reply]

Works for me. I assume we drop them a notice and if they don't respond or act on whatever the complaint is within (eh) a week or so, they get the boot? Kylu 01:42, 15 August 2010 (UTC)[reply]

I'm not sure if it works for me (note: I'm a sysop on very small wiki so here could be my COI). I rarely visit it / once in some months, and if I found something to do, I did it, but it happens rarely. In most cases someone (from SWMT, usually) has done it, I'd just thank them. It seems to work, since no one on the wiki has complained. If you would like to desysop me, it doesn't matter (I got it for l10n mainly and there was no translatewiki yet, but the time has changed many things since then). But I guess it would be the case for many small wikis, and some would mind - notice and one week could be too rush for them? I don't know ... --Aphaia 02:30, 15 August 2010 (UTC)[reply]

We could stretch the notice to be posted on both the wiki in question and, if the user is unified, their Meta talkpage also. Would you prefer "logged action or edit" instead? Don't worry about your COI really all that much, I just try to think of what is fair for both sides: I don't want to be stuck with nobody but an inactive crat/admin on one hand, and don't really want to be booted out because I went on a three month wikibreak on the other. I almost wonder if we need an "inactive" flag that people can set to show that they're missing for a bit and that visitors should pester the stewards/global admins instead... Kylu 02:49, 15 August 2010 (UTC)[reply]

I don't think we should be satisfied with "token edits" here. Somebody who clearly doesn't care should be removed. It's simple: "you haven't been giving a damn in years, and now that we notify you, you suddenly make some random edit just to keep your trophy-flag, and then you're gone again while others are actually doing stuff" -- that's what it seems like to me. Seb az86556 10:40, 15 August 2010 (UTC)[reply]

：I agree "token edits" are not beneficial, but it would be an inevitable side effect of having a numerical measurement. I guess "logged action or edit" would work better. For example 1) some wiki culture don't see the point of inactive desysoping clause. We at global community have not to impose them a criteria which might not work well in their editing community culture. 2) Even in meta, some people have found adminship beneficial even they are not actively using tools - editing protected pages, review the deleted pages etc. "logged actions only" wouldn't cover this kind of tool usage. --Aphaia 10:56, 11 September 2010 (UTC)[reply]

No logged action and less than 10 edits in 12 months. — Tanvir • 05:05, 26 October 2010 (UTC)[reply]

Possible abuse

Local policies give room to abuse, apparently, see some doubts on Requests for comment/Userrights on hi.wiki. Nemo 23:00, 9 March 2012 (UTC)[reply]

Temporary removal of inactive administrators taking leave, on request

Suggestion: On the subject's request. Re addition of the rights at the local project.

What are "inactive administrators taking leave, on request" and what is "Re addition of the rights"? --MF-W 16:31, 8 March 2010 (UTC)[reply]

+1 (admins sometimes request to have their flag removed by stewards; but then sometimes want stews to reinstate it as well) –SJ +

So, someone has a Full House set of permissions (admin, bureaucrat, oversight, checkuser) and goes on leave, so you remove his permissions. Six months later, he wants his permissions back. Do you require a new local election for OS/CU, or can it just be regranted once they have admin & bureaucrat back? What if they only grant admin and deny bureaucrat? Lots of little holes that have "obvious" interpretations which aren't codified anywhere. Ionek 17:32, 9 August 2010 (UTC)[reply]

And what if a user "voluntarily" resigns during a no-confidence vote which he's failing and then wants his tools back? Obviously this would apply only to wikis without local 'crats; where there are no local 'crats, temporary flags can be given by stewards in the usual manner, I suppose, and where some local vote is needed a semplification would be fine, but maybe at least a local notification with no opponents (or something like that) would be useful. Anyway I don't see the point of resigning due to inactivity (whoops, I did that once! but I would just re-run for election, and inactivity was not the only reason). --Nemo 09:09, 13 August 2010 (UTC)[reply]

I think that specific situation (voluntarily resigning during a no-confidence vote) would kinda more fit in the next section, actually. Kylu 01:44, 15 August 2010 (UTC)[reply]

Removal of administrators against their will

Suggestion: On lack of confidence in the local administrator, the membership of the project should be able to remove said administrators.

Typical reasons for a lack of confidence in local administrators are: Abuse, neglect, inattention.

Invalid reasons for such a vote, which will result in dismissal of the complaint, are: Age, location, handicaps where reasonable accommodation can be taken (see ADA 1990), race/ethnicity, caste, orientation, religious beliefs, political affiliation, tribal affiliation, and contributing to other projects.

Projects with no local bureaucrats or arbitration committee

Suggestion 1: Removal requires a greater vote than the minimum to elect an administrator, both in percentage and minimum duration.

Suggestion 2: In the event that the local discussion regarding the removal is disrupted (for instance, the administrator summarily bans the editors discussing the removal and deletes the vote), said administrators rights will be immediately removed and actions regarding the discussion reversed by stewards, in order to allow for discussion. Further disruption in the form of vandalism results in the (former) administrator being banned from that project until the discussion is finished.

It almost works for me. I'd suggest a slight modification: not "a greater vote" but "a same or greater vote"; imagine a wiki has two and only two active editors and both have admin right. Or imagine a wiki whose policy said "adminship is granted only on full consensus". A greater vote could not exist in those cases I'm afraid. --Aphaia 02:37, 15 August 2010 (UTC)[reply]

Projects with local bureaucrats and/or arbitration committee

Suggestion: Projects with either local bureaucrats or arbitration committee are encouraged to develop a method of no-confidence recalls to remove administrators in cases as mentioned above. Stewards are still requested to perform rights removals in the event of an emergency. (Needed: Examples of emergency and non-emergency behaviors, to clarify future situations.)

Proposal: By default, on projects with an arbitration committee, removal of permissions should be an authority vested in that committee, unless there is local policy to the contrary on file with WMF Triona 07:44, 3 September 2010 (UTC)[reply]

Consensus guidelines for other issues

Examples: Opting in/out of global bot and/or global sysop wikisets.

A to-be-determined minimum number of active, reachable admins, sufficient to give the community acceptable response times at all hours, and a minimum size of community should be a requirement to opt out of global permissions, temporary permissions, and/or emergency permissions. This is to insure that "healthy" self-governance exists for these important functions before a project opts-out of small-wiki assistance programs. Triona 08:31, 3 September 2010 (UTC)[reply]

A couple minor points:

Modifying a global permission group which does not rely on wikisets (global rollback, for instance) should only be doable via a review of that group, as the proposal was passed specifically with global application in mind.

Your exceptions would only apply to community-implemented groups, of course; Positions created by the Foundation and emergency actions taken by those with the ability to implement them are simply not negotiable: your.wikipedia may not opt out of having ombudsmen review their checkuser logs, for instance. Always keep in mind that the staff and sysadmins will do whatever needs to be done to protect the Foundation and its assets regardless of our desires. Kylu 21:21, 15 November 2010 (UTC)[reply]

When should Local policies should take priority

Important question. Many wikis have local policies in place. This proposal needs to address:

When do local policies take priority?
What is required for the foundation and stewards to recognize the local policy (ie ratification requirements)?
When does the global policy overrule a local policy?

Elaborating a bit - this would seem to require that the global policy have several parts.

A default policy, which is set by the global community to apply to all projects which do not have local permissions policies, or which do not have enough local community for the foundation to recognize the local policy as valid policy formed from consensus.
A ratification policy, which determines the steps and required participation to adopt a local policy and for the foundation to recognize it's validity.
A global policy, which specifies the limits on local policies, sets minimum numbers of privileged users for a project to be considered healthy and for permissions above sysop to be retained locally, sets when permission requests may be processed in spite of local policy, and how to determine if a project no longer has sufficient participation to have it's local policy recognized (collapse of community, collapse of local governance).

Hopefully this makes some sense Triona 07:54, 3 September 2010 (UTC)[reply]

I was thinking, "Once there's local bureaucrats, handling the matter of who becomes sysop and bureaucrat is up to them." though with the limitations of #Removal of administrators against their will taken into consideration. My primary concern is that someone could finagle some friends from another project to follow, do some edits, then get themselves and their friends into positions of technical power and "rule" the project despite the wishes of other contributors. Not every project is the size of en.wikipedia, and I've noticed that there are a number of projects whose policymaking system seems biased towards entrenching those with authority there already. If my own position is precarious because of the implementation of fairness, that's a wonderful price to pay for the long-term stability and good over all the projects. ;) Kylu 16:52, 3 September 2010 (UTC)[reply]

I also think we may want to consider the registering of local policies with respect to permissions/promotions with the foundation, with a summary of those policies and the state of local governance and permissions available on meta (in a language that at least the majority of the stewards can understand) for the benefit of stewards in evaluating requests here. This would have tables that look something like this:

en.sampleproject

Active bureaucrats 2 as of 07:37, 3 September 2010 (UTC)

Active sysops 24 07:37, 3 September 2010 (UTC)

Promotion to bureaucrat Handled locally or by stewards according to [[Permissions Policies/en.sampleproject/bureaucrat]] last updated 07:37, 3 September 2010 (UTC)

Promotion to sysop Handled locally by bureaucrats according to [[Permissions Policies/en.sampleproject/sysop]] last updated 07:37, 3 September 2010 (UTC)

Global sysop Included, project within small wiki thresholds.

Notes Project has sufficient active sysops that temporary sysopping should not be needed.

I think this would give us a good base for handling local policy considerations in small wikis Triona 07:38, 3 September 2010 (UTC)[reply]

Added some formatting, apologies for editing your post. :) Kylu 21:23, 15 November 2010 (UTC)[reply]

ABOVE CLOSEDI've closed the above thread because a pretty good idea of needs, wants and must haves has come out. I've drafted a new version below for us now to discuss. In my opinion, I see the consensus I've gleaned out of the above discussion as being represented in the below draft. fr33kman 05:57, 7 March 2011 (UTC)[reply]

Draft of Guideline

This page in a nutshell: There are certain rules and criteria regarding access to admin and bureaucrat status on small projects. Also, nothing in this proposal affects sites deemed large enough to have local over-riding policies about this matter.

Temporary importer

Local user places a notice on the local site's equivalent of the Village Pump or Administrators Noticeboard.
Waits 24-48 hours for objections. No supports required, opposition requires full discussion.
Posts the request on SRP after 24-48 locally.
Steward can change right at this point, with removal without notice after term expires.

Permanent importer

Local user places a notice on the local sites' inequivalent of the Village Pump or Administrators Noticeboard.
Waits 1 week and obtains 2/3's support of at least 5-10 people voting
Steward can change right at this point.

Temporary administrator

< 1 week - Used for a very specific task only that is monitored and immediately revoked upon expiration or abuse. Can ask any steward for temporary admin for a maximum of one week on any small wiki without active administrators. <<placed here by fr33kman>> not part of the above RfC.

3 months - User posts an advisory notice on local wiki, granted if no oppositions.
- (user can request extensions without local notices, only for 3 months at a time)

6 months - User posts an advisory notice on local wiki. 2-4 support & 2/3's support over 5 day election.
- (user can request extensions without local notices, only for 3-6 months at a time)

Permanent administrator

There must be a minimum of two admins locally at all times for oversight.

Candidates for permanent adminship must be elected by a minimum of 5 votes over a minimum of 2 weeks, with a support ratio of 80%.
Comment - 80% support looks overkill to me. 75% is better and it also seems to be the standard cross-wiki-criteria for getting adminship. The same happens with 2 weeks: I think that one week is enough. We can, however, extend the vote one week more if no consensus has been reached in the first week. If no consensus is reached after 2 weeks the request will be closed as unsucessfull. The requirement of at least 2 admins locally for oversight is OK with me. -- Dferg ^{☎ talk} 12:18, 12 May 2011 (UTC)[reply]

Agree that 80% support is way too much, many project have lower requests for bureaucrat, and normally the level for sysop is between 2/3 and 3/4. I don't understand why we need to have two active sysops at all times... if not, than what? For small wikis one active sysop is already an achievement, and one active sysop who knows the language is much better than permanent need to ask stewards who don't know the language. Keep in mind that for many small projects it's already not to easy to find one constantly active user who is motivated to be a sysop, and if he doesn't violate any rules local community may be happy with him — NickK 22:25, 12 July 2011 (UTC)[reply]

Bureaucrat

A project must have at least six to ten administrators to to elect bureaucrats. There must be a minimum of two bureaucrats locally at all times for oversight.

Candidates for bureaucratship must be elected by a minimum of 15-20 votes over a minimum two weeks, with a support ratio of 80%.

Comment. 15-20 votes cannot always be summoned on sv.wikipedia for a cratvote. And two crats at all times. Are you afraid that our stewards will run out of work? Sounds like only the top 10 projects will have there own crats in the future. -- Lavallen 17:49, 12 July 2011 (UTC)[reply]

Again why six to ten sysops and 15-20 votes? Some projects with 5 sysops can be rather active and need user renamings and managing bot flags which is impossible without crats — NickK 22:25, 12 July 2011 (UTC)[reply]

I would like to request comments if a wiki should have at least three bureaucrats or none. When I was a bureaucrat on Chinese Wikisource, the only other bureaucrat became inactive. Despite repeated notices, he never answered, so his flag was removed. When I became the only bureaucrat, I also resigned. In my opinion, even two bureaucrats can easily become both inactive. To avoid a wiki whose bureaucrats all become inactive, at least three bureaucrats (or even more) or none may be better.--Jusjih 17:24, 8 August 2011 (UTC)[reply]

I don't think this is necessary - it's not a huge problem if bureaucrat tasks on a wiki that normally wouldn't elect 3 bureaucrats fall back to stewards because the bureaucrats there become inactive. This would just set a too high requirement for wikis which want to elect crats (but have less than 3 willing/accepted candidates). I agree with NickK that also wikis with less than 6-10 admins should be able to elect a crat, and this would cause them to give half of their admins bureaucrat status, which might not be desired by them. --MF-W 18:24, 8 August 2011 (UTC) Addendum: e.g. de.wikipedia got along with just 2 crats for years --MF-W 18:39, 8 August 2011 (UTC)[reply]

Thanks for the reply. Any wiki with just one bureaucrat should be asked to either elect one more bureaucrat or to remove the only one bureaucrat, who may still be an administrator if the flag is already on. How do we start the global policy to formally require two bureaucrats in each wiki or not at all? Do we have any tool to check the number of bureaucrats in each wiki?--Jusjih 10:09, 9 August 2011 (UTC)[reply]

We can use this toolserver tool: [1]. I think it would be the best to only ask/propose them to elect a second bureaucrat at first, with reference to the discussion here and the advantages (when one bureaucrat is inactive etc.) - as the adoption of global policies can take some time and is often a complicated process, it would be better to make a complete policy proposal about all voting requirements that are discussed here. --MF-W 10:57, 9 August 2011 (UTC)[reply]

Thanks again, for the tool link, where I see 122 wikis with single bureaucrats. I propose the following message to be sent to each single bureaucrat, and please reply if any improvement should be made:

"Requests for comment/Minimum voting requirements#Bureaucrat is discussing whether to start a global policy to require each wiki to have at least two (2) bureaucrats or none at all, to address the problems in case all inactive bureaucrats may require stewards to "step on their toes" to promote users, etc. As you are the only bureaucrat in this wiki, would you please have the second bureaucrat elected locally, such as nominating a trusted user? If you do not expect to remain very active, please also consider voluntarily resigning as the bureaucrat, so the stewards can easily promote users, etc."

As some smaller wikis with single bureaucrats will probably not get the second bureaucrats, I also propose politely asking these single bureaucrats to voluntarily resign. Once again, please reply if my proposed message should be improved. Thanks.--Jusjih 10:48, 13 September 2011 (UTC)[reply]

There is no consensus that no project should have 1 bureaucrat, and asking active local bureaucrats to resign their tools would be a step in the wrong direction IMHO. Jafeluv 11:55, 21 September 2011 (UTC)[reply]

Of course I would never ask any active bureaucrat to resign. In case the only bureaucrat in a wiki remains active, my very last sentence "If you do not expect to remain very active......" would be left out. Smaller Chinese wikis do not need bureaucrats, but I do not ask existing ones to resign if they are sufficiently active. After getting local consensus, both inactive bureaucrats of Arabic Wiktionary have been de-flagged [2], thus zeroing its bureaucrat. I may randomly check the 122 wikis with single bureaucrats to see how active they are. If active, then I leave them alone.--Jusjih 18:27, 9 October 2011 (UTC)[reply]

Inactivity

Temporary admins can be removed by anyone with the ability if they begin to perform actions they are not approved for.

Permanent administrators can have their flags removed if they go rogue or become abusive. Except in emergencies, this should be made to the SRP noticeboard only after a local hearing has taken place.

No action for six months

An admin or crat shall be determined to be inactive when they have few than 1 admin/crat logged action in the past 6 months, regardless of mainspace edits. They should, of course, be given the chance to respond.

I don't see any reason for it. In some projects admins can work on a monthly basis as there is nothing to do every day. Although it is not too likely that an active admin will have 6 months without need to perform any action, it's highly likely for a crat of a small project (Wikisource, for example, where there are very few bots) and it's very likely that there will be no RFA, no new bot and no user willing to rename himself in 6 months. So this must be judged on demand basis, problems begin when a user doesn't perform the requests and not when there are no requests — NickK 22:25, 12 July 2011 (UTC)[reply]

Vandalism is not a big issue on some projects. I have blocked two times and only protected once in the last 12 months. (The two other sysops have not blocked or protected at all.) Almost all deletes has been made because of the authors request. -- Lavallen 05:14, 13 July 2011 (UTC) (admin sv.wikisource)[reply]

No actions for a year

Anyone with a steward-granted flag that has zero edits or actions for greater than one year shall have such a flag removed.

Steward granted? You mean steward granted per local community's consensus for temp adminship? If so, I agree! But permanent flag also can be steward granted. — [ Tanvir | Talk ] 04:36, 17 September 2011 (UTC)[reply]