Project:Requests

Requests for permissions

 * Archives: Administrator &bull; Bureaucrat &bull; Editor &bull; 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! - ~

(SUL)→ Deepak
I am SUL owner of Deepak .I want to complete SUL this wiki also .I want to usurp User Deepak in this wiki 117.204.94.106 11:21, 24 March 2012 (UTC)
 * Hello can you confirm that you are owner of the SUL? Because it seems that User:Deepak is already merged with SUL on this wiki? Some proof that you are owner of the account, on another wiki. Thanks Petrb (talk) 14:25, 4 April 2012 (UTC)

None (SUL) → Tweex
Hello, I'd like to usurp local account to complete my SUL. Local user has been inactive since 2006 and has 0 edits. Thanks! (My confirmation on czech wiki)- 193.8.86.22 09:46, 11 June 2012 (UTC)
 * ✅ -- Skiz zerz  06:04, 12 June 2012 (UTC)

Other requests and requests for comments

 * Archives: Other requests and Requests for Comments

Problem with unified login
I normally edit on English Wikipedia as wikipedia:en:User:Bazonka. I have been trying to set up a unified login account for Bazonka, but I'm unable to do this fully because my Bazonka account here at Mediawiki is inaccessible. I don't know what the password is, and there is no email address associated with it, so the Password Reset functionality doesn't help. I had the same problem with my account at Commons. A bureaucrat helpfully renamed my unusable Bazonka account so that a new Bazonka account could be created (see here). Can the same be done to my account at Mediawiki please? If you need proof that I am the real Bazonka, then you should be able to email me via my English Wikipedia account. Thanks, Bazonka 91.125.92.179 11:01, 16 March 2012 (UTC)
 * Hi. The account was likely registered in past by someone else and now it was renamed in order to let you unify it. You can login to mediawiki.org using your central account now. Petrb (talk) 13:49, 16 March 2012 (UTC)
 * Thanks very much. Bazonka (talk) 14:20, 16 March 2012 (UTC)
 * Actually that's not possible, Petrb. The account was created automatically according to the logs, and therefore must be unified. Me and other users have had the same problem. See 29234. -- Krenair (talk &bull; contribs) 20:00, 21 March 2012 (UTC)
 * Hi, I don't think it's impossible since it solved the issue? I already renamed previous holder of this name, and as you can see in reply, it worked Petrb (talk) 09:59, 23 March 2012 (UTC)
 * What I meant was that if an account was created automatically it cannot possibly have been done by anyone but whoever was logged in with the global account. I didn't mean that fixing it was impossible. -- Krenair (talk &bull; contribs) 17:30, 25 March 2012 (UTC)
 * But this account was not created automatically, you opened wrong logs. The account was renamed, so if you want to see the reason for creation of original account, you need to open logs of renamed account. Petrb (talk) 05:40, 26 March 2012 (UTC)
 * The logs you linked actually show the process of login unification done after fix of this issue Petrb (talk) 10:01, 23 March 2012 (UTC)

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 &bull; 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)
 * [[Image:Cancelled process mini.svg|200x20px|link=|alt=]] Proposal withdrawn I see that there isn't much point to this then. -- Krenair (talk &bull; 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)

Again, we all &mdash; developers, stewards, admins and the regular users alike &mdash; 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)
 * 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.
 * 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 &bull; 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 &bull; 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 &bull; 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 &bull; 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 &bull; 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 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 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 &bull; meta) 07:03, 6 May 2012 (UTC)
 * Sounds fine. —Emufarmers(T 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 &bull; 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 &bull; 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. -- Skiz zerz  14:59, 15 June 2012 (UTC)