Project:Requests for permissions

Information

view

Use this page for requests for:

• autopatrollers, uploaders or IP block exemptions (which can be assigned by administrators)
• Promotion to sysop, translation admin, bureaucrat or anything not above (which can be assigned by bureaucrats)

Note that Requests for comment and other miscellaneous requests should not go here, but instead to the Project:Village Pump or Administrators' noticeboard if you want to avoid using Structured Discussions.

Any new flagging to +sysop should have an associated subpage here, except for well-established developers, where a developer is someone who has had changes accepted to the MediaWiki core or a MediaWiki extension where the total number of changed lines in the relevant whitespace-insensitive diffs exceeds 100.

The autopatroller group can be assigned by administrators, too, but generally that is given when an admin notices that patrolling someone's edits does not add any value, and not based on requests by the user themselves.

One thing to keep in mind is that unlike most Wikimedia sites, this site is controlled by the MediaWiki developers, not the other users in this community. Being a developer (someone with merge access who uses it to maintain code that runs on Wikimedia sites) automatically entitles you to at least administrator status, and a long-time developer won't find it hard to become a bureaucrat. If you are not a developer, you do have to give some good reason to get any privileges; you should not expect to ever be made a bureaucrat. Something like a third of administrators and a quarter of bureaucrats are non-developers, however, so it's not like you shouldn't bother asking.

That said, there aren't really any formal policies on what's required: you just have to convince a bureaucrat. Use common sense – if you are trustworthy and your services are in need, there's no reason not to promote you to administrator at least, but don't ask for administrator without giving a concrete reason (unless you are a developer). Being personally known to a developer or having administrator or higher status on a major Wikimedia project are two ways to be deemed trustworthy. This is a wiki that has opted in to allowing global sysops to work here, and such users are free to use their rights on this wiki and do not need to separately request administrator. The same applies to global rollbackers, who are already autopatrolled on this wiki. Other users in specialised global groups (such as global interface editors) are also free to use their rights on this wiki by default.

Requests for permissions

Archives: Autochecked user • Editor • Administrator • Bureaucrat • Other user rights

• Please create a subpage under Project:Requests/User rights/ with your user name as the page title and then transclude it to the bottom of this section.

Requests for renames

Information on how renames work is available on Wikipedia., Archives: 2012 (Previous years).

Example request:

=== Oldname → Newname ===
I'd like to change my username to "Newname" because that's the
username I use on other projects. Thanks! - ~~~~

Herr Kriss → Krzysiu

I'm globally changing my nicks, SUL Krzysiu is mine (proof). It's already done in several places. Thanks in advance! Herr Kriss (talk) 06:38, 31 August 2012 (UTC)

Krzysiu already exists and is attached to your global account... --Krenair ^{(talk • contribs)} 09:37, 31 August 2012 (UTC)

It's attached because when I have some wikis with Herr Kriss SUL and some with Krzysiu SUL and I have to switch it all the time, so sometimes I'm entering project with Krzysiu SUL and it creates account automatically. I'd want to have my edits moved from Herr Kriss to Krzysiu. Herr Kriss (talk) 00:22, 1 September 2012 (UTC)

 Done --Krenair ^{(talk • contribs)} 00:30, 1 September 2012 (UTC)

Other requests and requests for comments

Archives: Other requests and Requests for Comments

Removal of inactive sysops?

So I asked someone to take a look at an admin permissions request yesterday, and I found that we actually have way too many admins already - 99 of us. I just ran a quick script to check each admin's last contribution timestamps and 41 of them haven't done anything this year. Anyway, shouldn't these accounts have their flags removed, or is that a really bad idea? --Krenair ^{(talk • contribs)} 14:35, 3 April 2012 (UTC)

• Support: Desysopping occurs for inactive admins on enwiki, so I don't see why it shouldn't occur here too.--Jasper Deng (talk) 17:05, 3 April 2012 (UTC)
  • We aren't enwiki, Just because they sneeze doesn't mean we have to. Peachey88 (talk) 08:06, 4 April 2012 (UTC)
    • Well, then again, we have far fewer bureaucrats. Our time is for documentation/development, after all.--Jasper Deng (talk) 17:29, 4 April 2012 (UTC)
• Neutral Oppose I don't think it's either bad or good idea, there is a little benefit. There is never "too many" sysops. For security reason it might be useful to do that, but any sysop who would return could just request their flag to be restored (that's what is being done on other wikis). If that was actually possible it would not help the security since the hacker could just hack to old account and refresh the flag. I think it would be better to implement a feature which would remove the flag automatically and users could reset it using email activation code Petrb (talk) 07:35, 4 April 2012 (UTC)

I opposed because in fact I see no benefit in that. If there is any, let me know. Petrb (talk) 11:13, 4 April 2012 (UTC)

I see one: it's like "work or you will lose the flag" which could make the sysops work harder forcefully, threatening them with removal of rights. This is certainly something we don't want to have here :-) Petrb (talk) 11:16, 4 April 2012 (UTC)

• Oppose: seems like a pointless measure to me, Our "not too many sysops" isn't really based on numbers, more the people around, since we aren't a big site it doesn't matter if spam stays around more than 5mins nor do we have much private stuff squirrled away via revdev, Our "too many" figure comes from the fact that we have Global sysops and SWMT as well as our localies (such as myself) dealing with the rubbish that needs to be deleted and we don't really need to overload it to a point where we conflict when we try to do anything (since there is so little as is) nor do we really want to be seen as a "flag factory" type situation where we just give it to anyone to deal with spam, which is why we are fine with giving it out if they can show a need/want for it, Nor does removing it (As pointed out via Petr) give any non-theatrical based security benefits. Peachey88 (talk) 08:06, 4 April 2012 (UTC)
• Oppose: Per Peachey88's comment above.--Jasper Deng (talk) 17:34, 4 April 2012 (UTC)

Proposal withdrawn I see that there isn't much point to this then. --Krenair ^{(talk • contribs)} 17:36, 4 April 2012 (UTC)

Local CheckUser policy

In his user rights request above, Saper wishes to become a local CheckUser. However, the policy on Meta requires that we have at least two local CheckUsers. Furthermore, I wonder whether we'll either have enough local CheckUsers to check the spam we receive (~3 5 RC patrollers is what I'm thinking of) or whether we should count stewards as local CheckUsers (they handle our CU requests right now) so they can continue doing checks here. So:

1. Who else should be local CheckUsers?
2. If less than 3 5 users who are daily RC patrollers wish to become local CheckUsers, should we allow stewards to count as local CheckUsers?--Jasper Deng (talk) 19:07, 3 May 2012 (UTC)

It's not possible for Saper to become a local checkuser here as there should be at least a second one and indeed, the stewards aren't able to do checks then here anymore (which is something I wouldn't support of course)... It's not possible to make an exception to the global rule either. Regards, Trijnstel (talk) 19:40, 3 May 2012 (UTC)

Even if there will be another candidate please allow us to check spammers on this project, it's crucial to stop the xrumers' army! --Vituzzu (talk) 19:43, 3 May 2012 (UTC)

I agree with the comments above. This wiki is one of the most attacked by cross-wiki spammers, and by spammers in general. -- Quentinv57 19:48, 3 May 2012 (UTC)

I don't see that Saper cannot be, just cannot be as a single candidate when no others exist. Plus from my reading of the policy, stewards can still undertake checks though with more limited circumstances, and in conjunction with complying with a local policy. I would support the community having that access for the reasons mentioned above. — billinghurst sDrewth 03:08, 4 May 2012 (UTC)

I would prefer that we had local checusers and stewards wouldn't be allowed to use checkuser but could request and get the local checkuser if they needed. That means, they would still have same access but there would be evidence of who is performing CU on this wiki. (If some steward wants to help they could just request CU and get it). That is my idea and it doesn't break any policy Petrb (talk) 09:40, 4 May 2012 (UTC)

Local CheckUser(s) would be nice to have. But I don't understand this rambling about policies, stewards and whatnot. Project:Administrators states that "Stewards and global sysops should feel free to deal with vandalism and similarly routine and uncontroversial things, if necessary. If that requires administrator tools, the community seems to agree that there should be no problem with this if the task is not complex." I'd hardly call performing a CheckUser query a complex task.
Again, we all — developers, stewards, admins and the regular users alike — want the same thing, which is a vandal and spambot-free MediaWiki.org. Only that should be relevant. If there is a policy or policies that are conflicting with this goal, then the policies should be amended or otherwise changed. --Jack Phoenix _(Contact) 10:55, 4 May 2012 (UTC)

I understand it that there is a global policy which can't be overriden, which prevents Saper from getting the bit, and if he had it, it would prevent stewards from using CU. Maybe I am wrong, if not, we should either change global policy or do something what doesn't conflict it. Petrb (talk) 12:12, 4 May 2012 (UTC)

So I read it and it doesn't say that stewards can't use CU if there is any present. So I guess we better make 2 CU here and let stewards continue using it as they need. Petrb (talk) 12:23, 4 May 2012 (UTC)

The policy says "If local CheckUsers exist in a project, checks should generally be handled by those. In emergencies, or for multi-project CheckUser checks as in the case of cross-wiki vandalism, Stewards may perform local checks." I believe I can speak for the majority of stewards in saying that if a project has local checkusers, we will not perform checks as needed by that project. We also will not make an exception for mw.org to have local checkusers and still rely on stewards to perform local checks. The community is free to adopt local checkusers, but we won't create an exception to our global practice. MBisanz ^talk 18:12, 4 May 2012 (UTC)

I've checked on projects with local CUs when required, but I agree it's an exception. But the meta policy is a global policy and can't be modifyied nor totally nor in part for any local policy. If local CUs are appointed, Stewards will only be able to check in two limited situations and I think this will really hurt mw.org and the projects in general as much of our antispam work starts and is being done here. Bureaucratizing this will do no good IMHO. Thanks. --Marco Aurelio (talk • meta) 18:59, 4 May 2012 (UTC)

Technically, we could also say that all stewards can request permanent local CU access if needed, thus keeping in line with policy and avoiding the problems.--Jasper Deng (talk) 19:46, 4 May 2012 (UTC)

I am sorry Matthew, but you I can't rely on your statement, I will check this with other stewards too and eventually start a rfc on meta regarding this. I see no point in disallowing stewards in performing CU once wiki has some CU. Neither I see any logic in disallowing them from becoming local CU. So if some steward wants to be able to CU on this wiki they can, either as stewards or they can request to be a local CU if community support them. If this is not true I will start rfc to change this policy it would simply not make any sense. Petrb (talk) 19:58, 4 May 2012 (UTC)

Yeah, I'd like to see what part of the CU policy prohibits stewards from being local CUs. OK, I saw it, but I find that ridiculous.--Jasper Deng (talk) 21:59, 4 May 2012 (UTC)

I did a simple db query and found that this user "Billinghurst" is CU on some local wikis as well as steward, so I guess this policy doesn't disallow it, rather doesn't recommend it Petrb (talk) 06:08, 5 May 2012 (UTC)

Nothing in the CU policy forbids you to be a steward and a checkuser at other projects at the same time. I'm for example a checkuser at meta as well a steward; because I was elected by the community there. In the case of Billinghurst, he's elected at enWS and Meta too. What the policy forbids is to -without being local CU, using your steward "hat"- making checks on your homewiki as well checking on projects with -active- local checkusers for non-emergencies/cross-wiki issues. I also think that the policy ought to be changed as it sometimes seriously hinders our work in vandal-prevention; but I bet I'd be a bit tad difficult. Thanks. --Marco Aurelio (talk • meta) 14:58, 5 May 2012 (UTC)

Well, at least that means we can simply elect several stewards active on checking this wiki to be local CheckUsers, which would be technically gaming the system/wikilawyering the policy, but it would work.--Jasper Deng (talk) 15:56, 5 May 2012 (UTC)

Local policy is more friendly, stewards can do whatever they want as long as it's neccessary for their work. If you want to be a checkuser you can give the bit yourself anytime no matter if there are some local or not. Those checkuser policies we have on meta are no way excuse to prohibit this wiki from having local CU, neither it give you space "to threaten" us telling that you stop working as CU once we have some. So now it's clear that this is not a matter of any policies but rather some personal statement given by some stewards. Petrb (talk) 16:40, 5 May 2012 (UTC)

Your claim that we're threatening You is insulting. In no way we're threatening you, nor I am. Again, we are subject to Meta policy; which does not prevent mediawiki.org to have local checkusers but do prevent stewards to perform local checks once this wiki have local checkusers except in those two situations. Meta CU/Privacy policy can't be modifyied by local policies and the WMF has stated that clearly in the past, IIRC. We're simply exposing the problem. I'd most than glad to see it resolved. Thanks. --Marco Aurelio (talk • meta) 19:30, 5 May 2012 (UTC)

Also, keep in mind this is a wiki full of developers, we don't follow policies as much as we do follow common sense. This means if you were able to be CU in past because you are steward no one would prevent you from becoming a local CU if you wanted to be one in a future. So these theories about inability to work as CU on this wiki if we had some local CU is kind of screwed. You either want to perform CU checks here, and that means you can request the bit anytime and get it, or you just don't want to do that and you don't have to. If any policy on meta put any level of unneeded bureaucracy into this, change it or remove it. It were surely not developers who have set such a complicated and pointless rule. Petrb (talk) 16:48, 5 May 2012 (UTC)

We've been always open to help; and we want to continue doing that. It's not that we don't want to help, it's that we've had problems in the past with feuding, wikilawyering and general BS. The Meta CheckUser policy is kind of stupid in some things as you said. I completly agree with you. I'd like to continue helping this wiki and other wikis as editor/steward if I'm allowed to. Thanks. --Marco Aurelio (talk • meta) 19:30, 5 May 2012 (UTC)

Given that, I'm going to start drafting Project:CheckUser.--Jasper Deng (talk) 19:05, 5 May 2012 (UTC)

The drafted version even complicates the situation. Firstly you can't promote anybody to CU without at least the approval of 25-30 editors. The drafted version prohibits stewards for performing checks without passing an RfCU, even in emergencies/cross-wiki cases. --Marco Aurelio (talk • meta) 19:30, 5 May 2012 (UTC)

Made a correction for the first part about !votes, though I really hope we can make an exception to the policy on this wiki. For the second part, all stewards who have done checks here should request local CheckUser access immediately after adopting this policy.--Jasper Deng (talk) 19:39, 5 May 2012 (UTC)

I've made some more changes. Actually, if we have 20 editors voting in support of any steward as a local CheckUser, technically we're still in line with the Meta policy because basically we're automatically electing all stewards.--Jasper Deng (talk) 19:43, 5 May 2012 (UTC)

No, you are mistaken. 25-30 users and 80% supports are requirements that cannot be waived. Snowolf ^{How can I help?} 20:03, 5 May 2012 (UTC)

Mis-remembered.--Jasper Deng (talk) 20:55, 5 May 2012 (UTC)

We're not threatening you; we want to help. I ran into this same problem before I was a steward at en.wiki. En.wiki wanted to let crats desysop people in request and permit the stewards to continue to handle desysop requests. The stewards were quite clear that if the crats were given the technical power to desysop people, they would not desysop people outside of extreme emergencies. It seemed unfair to me at the time and wasn't even grounded in something like the Checkuser policy, but I see now that it is a good way to avoid mixing the stewards in intra-wiki disputes. If mediawiki wants to, it can adopt a policy for local checkusers and then get 25-30+ people to vote in favor of giving checkuser to several stewards besides some trusted local members. But, that assumes that many people would vote. Otherwise, mediawiki can have two local checkusers and not rely on the stewards. We're trying to accommodate your needs through the first idea, but the second idea is the default that all other wikis operate under and can't be changed. MBisanz ^talk 20:36, 5 May 2012 (UTC)

I know, this community is much punier, less interactive, and more disconnected from the rest of Wikimedia than other wikis. A 2-week !voting period is pretty long; however, after the initial promotions we should need little other promotions afterwards. However, I need 25 "pre-approvals" so that stewards can just assign themselves CheckUser. After all, several stewards are active locally here, and we can give them CheckUser. Perhaps we should just approve CheckUser-ship in a large batch of like 10+ users to minimize the comments needed.--Jasper Deng (talk) 20:55, 5 May 2012 (UTC)

It sounds like the only CU actions that stewards have been performing here have been for cross-wiki abuse, which are specifically allowed in the global policy, so I'm not sure what this hand-wringing is about. —Emufarmers^(T|C) 04:36, 6 May 2012 (UTC)

Actually, like 40% of the checks I see are unique for this wiki.--Jasper Deng (talk) 05:39, 6 May 2012 (UTC)

Where do you get that figure from? —Emufarmers^(T|C) 07:21, 6 May 2012 (UTC)

It's all spambots that get blocked/locked crosswiki, even if they have no edits elsewhere. Which makes the whole local CU pointless, as either you have the stewards going to the local CU to get the IPs or the other way around, or, if stewards can perform the checks, local CU will never perform a single check ever :S Snowolf ^{How can I help?} 10:18, 6 May 2012 (UTC)

A thought

Hi. If Saper or the devs working for the CheckUser extension do need access to the tool for technical reasons and bug testing; why don't you request to the WMF a global group with the required permissions attached? (just in case Saper does not qualify for sysadmin or staff global groups which already have those permissions). Stewards can create and modify global groups in seconds, add and remove the required permissions and so on. This will solve the following problems: (a) Saper will have access to the CU tool at all projects (nb: the group can be attached to a wikiset, so the access can be limited to a given set of wikis too) which will better for him than just having CU access in just one project; and (b) This wiki will be w/o checkusers and we -the stewards- could continue making checks for stoping vandalism and cross-wiki abuse without worrying that we might be violating the Meta-CU policy. However as I said the request for creation needs to come from the WMF given the sensitive permissions that it'll have. I think it's a solution that satisfies both parts. What do you think? Please comment. Regards. --Marco Aurelio (talk • meta) 07:03, 6 May 2012 (UTC)

Sounds fine. —Emufarmers^(T|C) 07:21, 6 May 2012 (UTC)

Don't mix production with testing platform. Developers don't need global access to checkuser in order to perform tests. Petrb (talk) 07:28, 6 May 2012 (UTC)

I do not believe that that was the reason Saper requested CU. Also, I indeed fail to see why devs would need global CU for testing purposes, if tests have to be conducted for whatever reason on the live cluster, testwiki or its sisters are perfectly capable of testing that I assume, and if access is needed elsewhere, it can be granted ad-hoc, imo. Snowolf ^{How can I help?} 10:22, 6 May 2012 (UTC)

The global group can be limited to a wikiset thus not being really global. Please read again :) --Marco Aurelio (talk • meta) 15:22, 6 May 2012 (UTC)

Which wikis would it include? I don't know where that falls on the global CheckUser policy, though, since it does not account for something like this.--Jasper Deng (talk) 16:44, 6 May 2012 (UTC)

This wikiset would be useful only for test wiki and test2 wiki Petrb (talk) 17:50, 6 May 2012 (UTC)

'mediawikiwiki' can be also added to the Wiki-Set if required. --Marco Aurelio (talk • meta) 21:59, 6 May 2012 (UTC)

Enable the "block" and "rangeblock" functions of Extension:AbuseFilter

Since sysops still must whack the incredibly obvious spammers triggering Special:AbuseFilter/14 (with no false positives), I'd like for the 'block' function to be enabled (usable by sysops modifying the abuse filter) so we could just ignore that spammer completely. If there are any false positives all that's needed is for the user to contest it on the talk page.--Jasper Deng (talk) 03:56, 15 June 2012 (UTC)

+1 from me as well. For filters that are made to stop spam, it seems nonsensical that they are unable to fully achieve that goal by forcing sysops to then go and "clean up" afterwards. Once this gets enough support, it'd likely be worth poking someone with cluster access on IRC or bugzilla. --Skizzerz 14:59, 15 June 2012 (UTC)

I support this change. --Krenair ^{(talk • contribs)} 21:02, 17 June 2012 (UTC)

Support--Frigotoni ...i'm here; 16:46, 19 June 2012 (UTC)

Neutral for now. While I can understand why you wish to use this feature, I have to say that you should be extremely careful with it. Trijnstel (talk) 15:55, 26 June 2012 (UTC)

Uh, too late, it's being implemented right now.Jasper Deng (talk) 16:44, 26 June 2012 (UTC)

 Done I'm not sure when the change was deployed or by who, but it has been. I've set filter 14 to auto-block. --Krenair ^{(talk • contribs)} 14:01, 30 June 2012 (UTC)

Proposal to allow bureaucrats revoke sysop

I think it would be useful, because giving a permission which is hard to revoke is always problem. You take a high responsibility while giving someone a permission that can have some negative potential and you aren't even able to stop that person, in case of misuse. What do you think? I guess we are big enough to deal with these matters, without asking stewards. Petrb (talk) 20:35, 17 June 2012 (UTC)

• I support this change, but you should see meta:Talk:Limits to configuration changes#Disconnection_from_stewards_overseeing, bugzilla:33879 and bugzilla:35258. --Krenair ^{(talk • contribs)} 21:02, 17 June 2012 (UTC)
• Support. In fact, users in the sysadmin global group in CentralAuth can already change all userrights. Given that many of them are bureaucrats or otherwise have high permissions on this wiki, this would be a non-issue.--Jasper Deng (talk) 23:36, 17 June 2012 (UTC)
• Oppose: We are a small(ish) wiki, I see no need or point for this change, There is generally enough people around that can deal with the "mess" till it can be dealt with by someone with the appropriate user rights. Peachey88 (talk) 23:52, 17 June 2012 (UTC)

I could give you example of a bureaucrat action where wrong person was given sysop, the bureaucrat couldn't fix it and had to contact stewards to change it. Question is what is a benefit from restricting this ability? I agree that bureaucrats should be careful when giving the permissions, but I don't see any benefit in restricting possibility to revert their own actions (either in case of mistake, or request by sysop who wants their permissions revoked, or misuse, which I doubt would happen though) Petrb (talk) 08:56, 18 June 2012 (UTC)

• Neutral: with the high proliferation of sysops on this wiki, having the ability for the wiki to police itself is a boon. This wiki has not been and likely never will be very policy-oriented, and forcing your way through red tape to get a steward to desysop seems antithesis to the laissez-faire way the rest of the wiki operates. That said, I don't feel that bcrats actually need the ability to desysop. From what I've seen, myself and other bcrats carefully judge who we hand +sysop to in order to avoid future issues, and I can't think of a single case where a sysop went rogue here on mediawiki.org. The only other use I can think of is to desysop inactive people, which was proposed and withdrawn above. --Skizzerz 23:54, 17 June 2012 (UTC)
• I disagree with the idea that rights on a wiki should only be given to those who need them. It seems so pointless to deny small extra rights to perfectly trustworthy and capable users just because we can't see a use case for them in advance. I definitely wouldn't consider it valid grounds to oppose such a change. --Krenair ^{(talk • contribs)} 00:01, 18 June 2012 (UTC)

• "Small extra rights", I don't see how Delete, Block to name a couple are small rights to be given away. And if we don't see a use case for the person getting them in advanced, I don't see one for them using them after getting them…. Peachey88 (talk) 00:11, 18 June 2012 (UTC)

• You don't seem to quite understand. I'm not claiming admin rights are small extra rights. Bureaucrats having the right to remove those admin rights are though. --Krenair ^{(talk • contribs)} 00:26, 18 June 2012 (UTC)

• Oppose. Per Peachey88. Sorry, but this proposal doesn't win me over. I'd prefer to let stewards do this kinda task. --Frigotoni ...i'm here; 09:54, 18 June 2012 (UTC)
• Neutral as per User:Skizzerz. Personally needed sysop help only once or twice; this change makes sense especially if local sysop rights could be granted by bureaucrats without a formal RfA process. Did we ever had any case of revoking sysop access here? Or are we solving a non-issue?  « Saper // talk »  13:33, 20 June 2012 (UTC)

Some people might be given sysop right temporarily, this isn't much possible right now because it's not possible to revoke them. There were some cases where we needed to revoke sysop, it was due to mistake when incorrect person was filled in the form. I think it makes a lot of sense to make it possible for crats to fix their own mistakes. Petrb (talk) 13:43, 20 June 2012 (UTC)

• Oppose Generally opposed to fixing things that aren't broken. Not to mention a significant portion of our admins are shell users or in the staff group and (in theory) are all powerful... Bawolff (talk) 16:58, 20 June 2012 (UTC)
• Oppose Per Peachey88. Trijnstel (talk) 15:59, 26 June 2012 (UTC)
• Oppose and strongly per Bawolff. Nemo 19:47, 2 July 2012 (UTC)

Autopatrol-related rights changes

Hi. Petrb suggested that I should mention here that I've added a change to operations/mediawiki-config in Gerrit which would allow admins on MediaWiki.org to grant the currently unused Autochecked group. It also grants autopatrol to all groups who already have autoreview. You can find the change in gerrit:11748. If anyone actually has any objections please make a comment. Thanks. --Krenair ^{(talk • contribs)} 20:54, 17 June 2012 (UTC)

• Definitely support I wanted this a while ago, but I was told we need a consensus for that. Petrb (talk) 20:56, 17 June 2012 (UTC)

• Who told you that? MediaWiki.org is controlled by the MediaWiki developers, not community consensus like the other WMF wikis. --Krenair ^{(talk • contribs)} 20:58, 17 June 2012 (UTC)

• Another developer told me that Petrb (talk) 21:00, 17 June 2012 (UTC)
• While yes, we are controlled by developers, All configure changes should still be discussed in some form, Minor stuff is ok in the IRC channel whilst bigger stuff should be done on wiki to gather some form of consensus. Peachey88 (talk) 23:54, 17 June 2012 (UTC)

• Support; developers are not supposed to be bound by consensus.Jasper Deng (talk) 23:33, 17 June 2012 (UTC)

• What ever has given you that idea?. Peachey88 (talk) 23:54, 17 June 2012 (UTC)

• Probably the header on Project:Requests: "unlike most Wikimedia sites, this site is controlled by the MediaWiki developers, not its own community". --Krenair ^{(talk • contribs)} 23:56, 17 June 2012 (UTC)

Consensus between developers should be IMHO required, but I see no reason why we should consider any comments from non-developers Petrb (talk) 08:47, 18 June 2012 (UTC)

Example: community of developers decide to make a change, someone else (for example a steward) come to this page and oppose the change. In this case we could probably ignore that oppose as long as no one from devs agree with that or consider it a reason to oppose Petrb (talk) 08:50, 18 June 2012 (UTC)

• Putting my support down here as well. --Skizzerz 23:52, 17 June 2012 (UTC)

• +1 from me too.--Frigotoni ...i'm here; 10:02, 18 June 2012 (UTC)

---

Merged by Hashar (gerrit:11748). Krinkle (talk) 20:43, 21 June 2012 (UTC)

Except it looks like it didn't fully work. The correct groups gained autopatrol but admins can't add the autochecked group. --Krenair ^{(talk • contribs)} 21:00, 21 June 2012 (UTC)

Okay, I think I know why. See gerrit:12533. --Krenair ^{(talk • contribs)} 21:13, 21 June 2012 (UTC)

 Done change merged by Reedy. --Krenair ^{(talk • contribs)} 20:57, 25 June 2012 (UTC)