Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals.
• Consider developing your proposal on Wikipedia:Village pump (idea lab).
• Proposed software changes that have gained consensus should be filed at Bugzilla.
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

Languages on sidebar

On the left hand side of any Wikipedia page, on the toolbar, there is a section devoted to interwiki links to other language versions of an article. I want to propose a small change to the mediawiki software wording here. At current it is simply named "Languages", which is rather ambiguous and vague name. I think that when somebody less experienced at Wikipedia, usually a reader or newbie, sees that and the links below it, that if they click it they can get the whole of Wikipedia translated into that language. I propose it is changed to something short but similar to "View this page in other languages". This clears up any confusion to what you may consider to be a very minor thing but could be very hard to get their head round for readers. Rcsprinter (talkin' to me?) @ 11:27, 26 October 2012 (UTC)

"In other languages" would probably fit. But your solution does not solve the stated problem. I'm as likely to think I'll see a trasnslation of the EN page if we say "View this page in other languages" ... the operative problem being "this page". The interwiki link allows us to view the treatment of this subject in other languages. "Other language versions" might work. "Articles on other languages" also. But we're swapping brevity for perceived accuracy, which still might not be parsed by the user. --Tagishsimon (talk) 11:53, 26 October 2012 (UTC)

Why not "Other languages"? Tony (talk) 12:14, 26 October 2012 (UTC)

Funny, in my toolbar it shows as "in other languages". Lectonar (talk) —Preceding undated comment added 12:20, 26 October 2012 (UTC)

Are you using any custom code that might be overriding the default? —David Levy 12:59, 26 October 2012 (UTC)

Not that I am aware of; but still, it shows "In other languages", even on this page here. Lectonar (talk) 13:03, 26 October 2012 (UTC)

I guess you have selected "en-GB - British English" as language at Special:Preferences. Then you see MediaWiki:Otherlanguages/en-gb instead of MediaWiki:Otherlanguages. en-gb is not recommended at the English Wikipedia. See Help:Preferences. The page history of MediaWiki:Otherlanguages shows some variation years ago but not since 2007. David Levy used the Simple English Wikipedia as reason for not saying "In other languages".[1] PrimeHunter (talk) 13:38, 26 October 2012 (UTC)

Thank you for that; I guess I must have chosen it when I started may account, some 7 years ago. Never had any problems, though. Cheers. Lectonar (talk) 13:54, 26 October 2012 (UTC)

I just harmonized MediaWiki:Otherlanguages/en-gb and MediaWiki:Otherlanguages/en-ca with MediaWiki:Otherlanguages.

If the British English and Canadian English options are to remain available, we should apply the various customizations (with changes in spelling/wording where appropriate). For the messages in which no English variety issues exist (presumably most), we could use redirects. —David Levy 17:15, 26 October 2012 (UTC)

One of the Wikipedias is written in simple English. —David Levy 12:59, 26 October 2012 (UTC)

Keep "Languages". Apart from linking to this subject in another language, it also links to the whole Wikipedia in that language (with "whole" admittedly being smaller than English). You stay in that language if you follow wikilinks there, use the search box, click the logo, and so on. "Languages" is brief and about as clear or open to misunderstanding as alternatives that are not ridiculously long. PrimeHunter (talk) 12:38, 26 October 2012 (UTC)

Keep "Languages". Agree with PrimeHunter - it is ambiguous, but it's short and it won't take the reader long to find out what is meant once he actually follows the link... --Philosopher ^{Let us reason together.} 19:41, 26 October 2012 (UTC)

We will have a huge language button on top right.

The WMF is developing a huge button that says "English" on the right corner, so readers will find the articles in other languages easily. --NaBUru38 (talk) 20:09, 15 November 2012 (UTC)

Why not have it say "On Other Wikipedias"? Then it encompasses, say, Simple English, while avoiding the implication of translations. ∴ ZX95 ^[discuss] 01:00, 8 December 2012 (UTC)

My preference is languages because that is more explanatory than other wp's. Technically simple is a subset of English. Apteva (talk) 02:53, 8 December 2012 (UTC)

The issue was raised, however, that "Languages" is likely to make some people think that the linked articles are translations of the English one; that was why I suggested "On Other Wikipedias", which is much less ambiguous. ∴ ZX95 ^[discuss] 15:29, 11 December 2012 (UTC)

Note to keep archiving bot away. Rcsprinter (yak) @ 21:43, 14 November 2013 (UTC)

Will this be affected by WikiData or will the wording change we are proposing still be changeable? Rcsprinter (whisper) @ 15:59, 14 February 2013 (UTC)

This is unrelated to Wikidata. I believe this is somewhere in Mediawiki and can be changed if there is consensus to do it.--Ymblanter (talk) 16:08, 14 February 2013 (UTC)

Redirects don't work on MediaWiki interface pages, but you can transclude one into another. --— Gadget850 (Ed) ^talk 16:18, 14 February 2013 (UTC)

The links are to the same topic on other language Wikipedias, not to other languages, or translations of the same article. Unless the sidebar section header mentions that the links are to similar articles on other Wikipedias it will remain ambiguous. • • • Peter (Southwood) ^(talk): 07:38, 30 March 2013 (UTC)

Restrict rangeblocks to CheckUsers

Restricting WP:IPBE to CheckUsers makes sense because only CheckUsers have to proper information to make that judgement call. The same is true for rangeblocks. Since IPBE is often granted to good users caught in rangeblocks, and only CheckUsers can see which good users will be collateral damage, it makes sense to restrict rangeblocks to CUs. Blocking good users causes much more damage to Wikipedia than the vandalism it prevents because of all the good users that leave. In fact, the blocking policy actually says to have CheckUsers check for collateral damage before making a rangeblock of any significant duration, which most are.

Some people would have you believe that Admins are perfect and never make a mistake, and that good users are never blocked. Unfortunately this is not the case. By 2009, we had more than 6 million IP addresses blocked in rangeblocks. The problem was so bad that Newyorkbrad (talk · contribs) had to ask admins to monitor the problem because of all the good users being blocked.

Concern about excessive rangeblocks
A few weeks ago I guestblogged a series of posts on The Volokh Conspiracy. Since then I have received e-mails from several readers of that blog on various issues. One of the most frustrating was from an eminent retired law professor, who indicated that he has attempted to contribute to Wikipedia articles several times, but has been blocked from doing so. He summarized the message that he receives when he tries to log in, and it turns out to be a Scibaby rangeblock. I have written back and explained how I can go ahead and create an account for this editor, but he seems to have moved on and I fear that we have lost the possibility of his contributing permanently.

In the wake of the publicity surrounding the ArbCom decision in the Scientology case, I was asked to appear on a radio show. There was a short call-in segment in which three people called in, and one of them also complained that he too has been caught up in longterm rangeblocks. Again, I offered to explain to him how to get an account opened if he would e-mail me, but I never heard from him, so he may have given up as well.

It is understood that rangeblocks, particularly ones placed by checkusers, are intended to address long-term abuse situations and are sometimes necessary. However, if they are overused, we risk cutting off our nose to spite our face, and there are also times when semiprotection or just dealing with petty nonsense is a better answer than blocking tens of thousands of IPs. I think we should all please make a point to use rangeblocks as narrowly as is reasonably possible. (diff)
— User:Newyorkbrad 15:00, 17 July 2009 (UTC)

By 2011 we had gone up to 7 million IP addresses blocked and by 2012 it was up to 8 million.

Today, we have 14 million (14,009,294 to be exact) IPv4 addresses blocked and 1.1092E30 IPv6 addresses blocked in a total of 1,356 Range blocks

Anybody that tells you that good users are never blocked and that there is no collateral damage in rangeblocks is sadly mistaken. 64.40.54.138 (talk) 08:54, 5 March 2013 (UTC)

There is almost always collateral damage with range blocks, that's a given. But there are many occasions where there is no other choice. Restricting range blocks to only checkusers is foolish and unnecessary. Anon-only range blocks are often necessary to deal with vandals editing from educational institutions with lax IP allocation policies. I have made many, many (short) range blocks of this type, including many before I was granted access to the checkuser tool. There are many similar cases as well. Unless you're going to be hard-rangeblocking, the chechuser tool is not going to tell you anything more than the javascript CIDR contribs gadget available in your preferences if you're logged in (although I will admit it is far easier to read the results in the CU tool). Range blocks already should only be implemented as an absolute last resort, and only for a short period of time without asking a checkuser. Forcing all range blocks to only be implemented by checkusers is excessive. I would at least tacitly support a proposal to ensure that admins consult a CU before making a long-term range block, or a hard range block, but really, people shouldn't be making that sort of block anyways before asking a checkuser to look for excessive collateral damage.

Also, I want to point out that the number of IP addresses blocked has very little correlation on the amount of collateral damage caused. I have seen many IPv4 /22s with more edits than probably 80% of IPv4 /16s. J.delanoy^gabs_adds 15:35, 5 March 2013 (UTC)

• I agree that restricting it would be foolish. There are many admin who know more about rangeblock appropriateness than some CUs, and most admin who aren't familiar with rangeblocks will just ask someone else to look at it. Being a CU doesn't mean someone is necessarily more network savvy. That said, it would be nice if we didn't INDEF block IP addys, or at the least, had an automated way to list rangeblocks (or any IP block) after they have been in effect for one year, for review. Dennis Brown - 2¢ © Join WER 17:21, 5 March 2013 (UTC)
• Example I am sorry to have to correct my well-respected fellow Wikipedians above, but they may not completely understand the situation. This is understandable because they do not look for bad blocks. On the other hand, I do.

In 2006, 65,536 IP addresses were blocked when 67.18.0.0/16 was indeffed. In 2011, 67.18.92.167 (talk · contribs) asked to be unblocked (diff). Three well-respected admins reviewed the unblock request and all of them denied it (diff). I asked the original blocking admin to review the block (diff). The blocking admin agreed to lift the block (diff). This was 2 years ago, and there have been only positive contributions since then as one can see by checking the range contribs for 67.18.0.0/16. This is only one example of literally dozens. I would ask my fellow Wikipedians above to please look in to the situation before calling it foolish. We have an significant editor retention problem at this time and I am simply trying to help. Thanks. 64.40.54.254 (talk) 20:19, 5 March 2013 (UTC)

I'm not saying there isn't room for improvement for how we do rangeblocks, I'm just saying that limiting them to CUs isn't a guarantee of better results. Fewer blocks don't guarantee better results either. Like I said above, I think the software should not allow indef blocks for IPs and we need a mechanism to auto review all blocks over 1 year. We will never "get it right", we can only hope to get as close as we can, while blocking problem editors AND causing the least amount of collateral damage. Collateral damage will always be >0 as long as we allow IPs to edit, forcing us to sometimes do range blocks. Doing them smarter is a good idea, limiting them solely to CUs isn't the best way to do them smarter, however. Dennis Brown - 2¢ © Join WER 22:20, 5 March 2013 (UTC)

I agree with Dennis, the root of the problem is that we don't really have a system in place to review long term IP or Range blocks. They really aren't very visible until an IP editor starts pushing over a particular instance. I started looking at Indef IP blocks a few months ago, and started a list of particularly old indef IP blocks at User:Monty845/Indef. They range from blocks with little explanation, to blocks by advanced permission holders that would require investigation by a combination of checkusers, arbs, OTRS agents, as well users with with Proxy check and WP:LTA expertise to conduct a review. Such a review really would need to be an organized group, prefarably with a mandate from the community to tighten things up to a certain standard. Monty₈₄₅ 23:08, 5 March 2013 (UTC)

• Strong oppose, especially since rangeblocks of around /64 and smaller in size in IPv6 rarely will need CheckUsers to clear. There are many admins I know who know how to make rangeblocks but are not, and often don't want to be, CheckUsers. Any IPv6 rangeblock larger than one user's subnet (typically /64 to /56) and any IPv4 rangeblock can and quite often will cause collateral damage, as subnets of those sizes are to be sure to be used by more than one user. If rangeblocks are overused, which I'll say is somewhat true to a very slight (and hardly problematic) extent, this is not the solution.--Jasper Deng (talk) 23:24, 5 March 2013 (UTC)
• Kommentar. I've been thinking about this problem, and wondering, why do we apply ACB (account creation block) by default for pretty much every softblock? I think it often creates more problems than it solves. If we're blocking a single user who's vandalizing, sure it makes sense, we don't want to let them create an account while still allowing people with existing accounts to edit to prevent inadvertent collateral damage. But if we're blocking, for example, a school or library, we should block the IP to prevent drive-by vandalism but allow account creation for legitimate uses. A more determined vandal might create an account to vandalize, but then we just block it as soon as it starts editing as a vandalism-only account. Pretty simple. Also, I oppose this proposal per above, given the many reasons why non-CU would need to use rangeblocks. -- King of ♥ ♦ ♣ ♠ 00:07, 6 March 2013 (UTC)

• I can't count how many times bored schoolchildren have taken advantage of the fact that account creation is not blocked for their school. I would say on average, if ten accounts are created from a school almost all of those ten accounts are VoAs. The only accounts that are not VoAs are the ones that haven't edited yet. It is extremely rare to find a legitimate person editing from schools (I am not talking about colleges or universities). Elockid ^(Talk) 00:20, 6 March 2013 (UTC)

• Guilty until proven innocent, eh? --Surturz (talk) 01:12, 6 March 2013 (UTC)

Legitimate user who edits from school right here. I agree though that is a problem. My school's IP is currently under a 6 month block (JamesBWatson (talk · contribs) assigned it, second block with the first being one week set by JohnCD (talk · contribs)) so no problems in that direction, at least until April, sometimes though I use the IP on Simple English and Meta because of the load lag the computers get it's faster to do edts as the IP, Look at my WikiVoyage user page, I admit to using the IP there. MIVP - (Can I Help?) (Maybe a bit of tea for thought?) 17:09, 7 March 2013 (UTC)

• Rangeblocks are a significant problem I guess the reason people don't understand how big this problem is—is because I didn't provide enough examples. So here are the rest of the first dozen.

• Exemple 2 indef rangeblock of 152.163.0.0/16 with a total of 65,536 IPs. Indeffed in 2006. Unblocked in 2011. Range contribs for 152.163.0.0/16 show nobody has come back to edit on that range.
• Exemple 3 indef rangeblock of 204.255.212.0/24 with a total of 256 IPs. Indeffed in 2005. Unblocked in 2010. Range contribs for 204.255.212.0/24 show nobody has come back to edit on that range.
• Exemple 4 indef rangeblock of 205.188.0.0/16 with a total of 65,536 IPs. Indeffed in 2006. Unblocked in 2011. Range contribs for 205.188.0.0/16 show 2 years of good contribs with no significant problems.
• Exemple 5 indef rangeblock of 207.200.112.0/21 with a total of 2,048 IPs. Indeffed in 2006. Unblocked in 2011. Range contribs for 207.200.112.0/21 show 2 years of good contribs with no significant problems.
• Exemple 6 indef rangeblock of 208.70.72.0/21 with a total of 2,048 IPs. Indeffed in 2007. Unblocked in 2010. Range contribs for 208.70.72.0/21 shows a single good edit in the last 2 years.
• Exemple 7 indef rangeblock of 216.91.92.16/28 with a total of 16 IPs. Indeffed in 2006. Unblocked in 2010. Range contribs for 216.91.92.16/28 show nobody has come back to edit on that range.
• Exemple 8 indef rangeblock of 217.106.166.0/24 with a total of 256 IPs. Indeffed in 2006. Unblocked in 2010. Range contribs for 217.106.166.0/24 show nobody has come back to edit on that range.
• Exemple 9 indef rangeblock of 64.12.96.0/19 with a total of 8,192 IPs. Indeffed in 2006. Unblocked in 2011. Range contribs for 64.12.96.0/19 show 2 years of good contribs with no significant problems.
• Exemple 10 indef rangeblock of 64.124.215.0/24 with a total of 256 IPs. Indeffed in 2008. Unblocked in 2010. Range contribs for 64.124.215.0/24 show nobody has come back to edit on that range.
• Exemple 11 indef rangeblock of 64.40.32.0/19 with a total of 8,192 IPs. Indeffed in 2007. Unblocked in 2010. Range contribs for 64.40.32.0/19 show 3 years of good contribs including mine.
• Exemple 12 indef rangeblock of 65.98.192.48/29 with a total of 8 IPs. Indeffed in 2007. Unblocked in 2010. Range contribs for 65.98.192.48/29 show nobody has come back to edit on that range.

In every one of these cases, all the unblock requests were denied and it took a third party to intervene to get them unblocked. WP:IPBE is one of the ways to help good users caught in rangeblocks. If IPBE is going to be restricted then rangeblocks also need to be restricted for the simple fact there are hundreds of bad rangeblocks. I can post another dozen if people still don't understand the situation. Just let me know. Thanks. 64.40.54.79 (talk) 05:07, 6 March 2013 (UTC)

The main problem is hard rangeblocks, which I strongly oppose and think should almost never be used. For soft rangeblocks, IPBE is not necessary, and thus can be used more liberally (but still with great caution). In my opinion, if you have a range of 256 IPs of which 200 are open proxies, surely it won't be too hard to get ProcseeBot to block all of them individually rather than slamming a rangeblock on it? -- King of ♥ ♦ ♣ ♠ 07:49, 6 March 2013 (UTC)

ProcseeBot can only check the small subset of proxies which are open HTTP proxies. Range blocks are not generally implemented, or useful, for these types of proxies. -- zzuuzz ^(talk) 18:28, 6 March 2013 (UTC)

• Oppose as it is unlikely to solve the problem. Personally, I don't think I have ever done a range block because, frankly, I don't understand them. But there's no reason an admin who does have the technical knowhow shouldn't be able to perform them. Also, in the specific example given above of an innocent person being caught in a scibaby block, that's been a long time and please forgive me if my memory is wrong, but I'm pretty sure the person doing most of those was himself a checkuser. So I'm not quite sure how preventing non-checkusers from doing range blocks is going to stop people from being caught in a scibaby range block. --B (talk) 21:35, 6 March 2013 (UTC)

"I'm pretty sure the person doing most of those was himself a checkuser" - this is correct. J.delanoy^gabs_adds 22:14, 6 March 2013 (UTC)

• What about some sort of solution that limits large rangeblocks to checkusers, but lets admins carry out the smaller ones ones (an obviously dynamic IP user repeatedly vandalizing a talk page, for example?) --Rschen7754 22:18, 6 March 2013 (UTC)

King of Hearts points raises the point that most range blocks should be soft blocks, in the case of a soft block, it seems like a regular admin should be able to evaluate things without the additional checkuser tools. I could see restricting hardblocks of large ranges to checkusers though. Monty₈₄₅ 22:26, 6 March 2013 (UTC)

• Is there not already something in place that prevents range blocking large ranges? Like 1.1.1.1/0 (I think that's every IP address in existence, right)? I'm hoping/assuming that there's already something restricting the number of IP addresses you can block in one action. --B (talk) 22:47, 6 March 2013 (UTC)

  It is not permissible to block a range larger than /16. -- King of ♥ ♦ ♣ ♠ 22:50, 6 March 2013 (UTC)

  Just for clarification for me, is it merely not permissible (meaning if you do it, you invite the wrath of the community, Jimbo, arbcom, and the cabal) or is it actually prevented by the software? (No, I don't propose to delete the main page and find out.) --B (talk) 00:44, 7 March 2013 (UTC)

  Sorry, I meant technically impossible, as in the software will not permit it. -- King of ♥ ♦ ♣ ♠ 00:46, 7 March 2013 (UTC)

Oppose but worth commenting. Indeffing IPs is a bad idea and I think the practice has more or less been terminated (well, maybe not [2]) voluntarily due to the problems outlined by the IP above. A multi-year rangeblock is better in extreme circumstances or proxy hosting, since it will eventually expire, and won't be re-applied unless the abuse resumes. Rangeblocks are necessary in many run of the mill situations where CU is unnecessary (school blocks, IP hopping , IPv6 anything). I would comment that hard rangeblocks are necessary for proxy-hosting ranges because of throwaway accounts (why hard) and the fact that it's very very hard to detect every proxy (why the range) and there's no need to edit via an open proxy unless someone is trying to evade scrutiny (why nothing of value is lost). Sailsbystars (talk) 01:05, 7 March 2013 (UTC)

• I just thought of an additional reason: They may be a minority right now, but as IPv6 addresses proliferate, many of them will simply assign an entire /64 block to a single individual. /64 IPv6 rangeblocks may become a routine part of an admin's arsenal at WP:AIV, depending on how IPv6 addresses are handed out. -- King of ♥ ♦ ♣ ♠ 02:01, 7 March 2013 (UTC)
• Oppose per King of Hearts. Elockid ^(Talk) 14:30, 7 March 2013 (UTC)
• Oppose and strongly so. Many admins have the know-how needed to perform rangeblocks. At times range-blocks are crucial to stop a problem and have to be applied swiftly, and not always finding a checkuser is possible, tho not being able to find any checkuser online is now a much more uncommon scenario then it used to be once-upon-a-time; it wouldn't fix anything, as checkusers use wide rangeblocks just as much as non-checkusers do; /64 subnets are assigned by many, many ISPs/hosting providers/whatnot by default for IPv6; if all rangeblocks had to pass by checkusers, we'd have to double the checkuser team's size at least. Snowolf ^{How can I help?} 06:06, 8 March 2013 (UTC)
• Strong oppose I work at SPI where at times I apply rangeblocks based ona large number of socking IPs. (All of mine seem to have expired based on the report). I would say that almost all experienced SPI clerks have implemented rangeblocks, short-term or long term at one point or another. We have the technical know-how and are aware of the standards. Admins should certainly not give out too many rangeblocks, but I do not think that this proposal would actually, independently reduce the number of rangeblocks. I've only used two at SPI, generally deferring to checkusers, but the fact I rarely use them is not a compelling reason to remove the ability. NativeForeigner ^Talk 00:24, 14 March 2013 (UTC)

Alternate Proposal

Adding RFC on this proposal to generate wider input. TheOriginalSoni (talk) 22:28, 22 March 2013 (UTC)

I think the OP's main concern is the number of innocent bystanders who get caught in those rangeblocks, unable to ever return again to editing Wikipedia. I suggest that we can do it by one other way -

• We unblock every rangeblock which was placed over a year ago (or some other time period as decided) , except the most nefarious of cases. All these recently unblocked users shall fall under a special category where their edits shall be monitored by other willing editors and admins to patrol such high-risk account edits. If the editors shows consistent reasonable good-faith edits over a period of time, admins can remove their names from this category. Editors showing bad-faith or disruptive edits can be indef-blocked again with a nuking of their contributions without warning.

Forgot to sign- So signing late TheOriginalSoni (talk) 07:10, 20 March 2013 (UTC)

Thanks for the suggestion. I appreciate the help. In the 5 years I've been working the issue, the community has never cared enough about good editors being blocked to do anything. It doesn't appear that this time will be any different, but I'd love to be proven wrong. 64.40.54.205 (talk) 12:20, 13 March 2013 (UTC)

Strong support, and I'd be willing to step up to the plate for the monitoring too. Tazerdadog (talk) 20:45, 19 March 2013 (UTC)

Support OriginalSoni's idea. If it's something that I could do for a long time on WP without putting my ass at risk of a block because of incompetence (which it seems like my deletion career is heading down) then i'm sure as anything up for it. MIVP - (Can I Help?) (Maybe a bit of tea for thought?) 22:15, 22 March 2013 (UTC)

• Support. IP address ranges should never be blocked for such long periods of time, unless they're the most nefarious of cases. Nyttend (talk) 21:44, 24 March 2013 (UTC)
• Support. A probationary period sounds reasonable. I dislike the idea of indefinite, wide-ranging blocks, and this would make it easier for users to contribute. NinjaRobotPirate (talk) 14:54, 28 March 2013 (UTC)
• Strong support. I would not be here, commenting on this proposal, if I had not had the opportunity to contribute anonymously. Such permanent rangeblocks probably deter many potentially prolific users, and I strongly believe that they are not in the best interest of Wikipedia. --Mathnerd 101 (talk | contribs) 14:24, 3 April 2013 (UTC)

Bumping thread to stop bot from archival TheOriginalSoni (talk) 07:19, 10 April 2013 (UTC)

Unbundle autopatrolled from admin rights package

Per this thread on AN, I'd like to propose unbundling the autopatrolled right from the administrator rights package. It's one of the few rights in the admin package, if not the only right, that has little or nothing to do with admin tasks. If a person becomes an admin despite relatively little content contribution experience becomes an admin--I myself could be considered one such admin--their articles will pass through NPP because of the autopatrolled right, without them having to display the same kind of content creation skills that a normal editor with autopatrolled might have had to demonstrate. Moreover, since the barrier for removal of admin rights is much higher than the barrier for removal of autopatrolled, it is very possible for an admin to misuse the autopatrolled right--whether intentionally or otherwise--in a way such that they will not be desysopped, but they would've had their autopatrolled rights removed.

What I propose instead, at least as an interim step, is for autopatrolled to be unbundled from the admin package, but the ability to grant and revoke the right not be removed. There is a precedent for a right like this in the edit filter manager right. This way, any admin who creates many articles will simply be able to grant themselves the right as needed, any who don't need it won't have it, and any that misuse it can have it taken away from them via a community discussion, ArbCom decision, or whatever without a full-fledged desysop. (They would technically have the power to regrant the right to themselves, but it would be a breach of WP:INVOLVED similar to an admin unblocking themselves.) Presumably an admin who has had their autopatrolled right removed would also be prohibited from granting or revoking it to anyone else, but that can be a discussion for another day if need be.

I think that this is only fair. Yes, Wikipedia is not an exercise in perfect, rigorous equality, but I don't see any significant drawbacks of unbundling this right. Again, any admin who needs it can simply grant it to themselves. The knowledge and experience required for a successful RfA is much broader than what is required for a grant of autopatrolled, but it it much shallower in the field of content creation. Most admins can presumably be trusted to write decent articles, yes, but there is much less evidence that they actually can.

Should this be successful, I would be curious to know if anyone has ideas for an alternate system to grant autopatrolled, rather than having the ability to grant it as part of the admin package. However, given that this proposal provides a means to remove the right, I think this is a worthy step on its own.

Thanks, Writ Keeper (t + c) 20:46, 22 March 2013 (UTC)

• Support. As they say at RfA, "why not?" --Demiurge1000 (talk) 21:08, 22 March 2013 (UTC)

Got any 'Barnstars of Good humour' yet? MIVP - (Can I Help?) (Maybe a bit of tea for thought?) 21:56, 22 March 2013 (UTC)

• Support The skill required to write appropriate articles is unrelated to the skill required to be an admin. Admins shouldn't get special dispensations in article creation; too much is bundled already. This right has nothing to do with being an admin. 88.104.27.2 (talk) 21:16, 22 March 2013 (UTC)
• Weak Support If it's not linked to doing admin duties then some may say that they should go about gaining those rights just like anybody else should, however since AFD RfA has became so difficult that not that many Admins are pulling through now they deserve anything they get, nevertheless the removal is more justifiable than the reason to keep. MIVP - (Can I Help?) (Maybe a bit of tea for thought?) 21:56, 22 March 2013 (UTC)

  I think you mean "RFA has become so difficult". --Floquenbeam (talk) 22:36, 22 March 2013 (UTC)

  Yes, Yes I do, my bad ^^' MIVP - (Can I Help?) (Maybe a bit of tea for thought?) 23:53, 22 March 2013 (UTC)

• This makes sense. It's certainly crazy that I have the auto-patrolled flag. It should be granted (or removed) to admins just like it is to non-admins. --Floquenbeam (talk) 22:34, 22 March 2013 (UTC)
• Support This 'right' unlike most others is a tool used by other editors to reduce the work patrolling. Per WP:AUTOPAT: It means that the user can be trusted not to submit inappropriate material, deliberately or otherwise, and that the user submits new material often enough that it is more efficient to mark it all as approved preemptively. It isn't a button we're taking away, but a regranting a human based quality control method. Until we have several dozen new articles as a prerequisite for adminship (unlikely at best), I agree with this proposal. Crazynas ^t 22:41, 22 March 2013 (UTC)
• Questions. WK analogizes the autopatrolled right to the edit filter manager right for several reasons, one of which is that by unbundling the autpatrolled right, it's then removable as well. First question: Has there ever been a case where the edit filter manaager right was removed by community discussion? It's not an academic question. If it's never happened, should we be doing all this for something that will probably never happen or at least happen so rarely so as not to be worth it? Second question: Assuming we implement the proposal, why should it require a community discussion to remove it? Currently, for example, an admin can block another admin for edit-warring. The blocking admin doesn't need a consensus for doing so, although, as with any other block, a review of it may be requested. Why should autopatrolled be different?--Bbb23 (talk) 22:48, 22 March 2013 (UTC)

• For your first question, I don't know of any cases of removal of edit filter manager, but you have to keep in mind that that's a right with much, much less usage and appeal; it's fairly technical and complex, so there aren't nearly as many people using it, and thus not nearly as much badness comes from it. I guess the point for me is that increasing the granularity of the rights packages allows us flexibility, and at least in this stage, there's little-to-no cost. It's a very simple change from a technical standpoint (a one-line change in LocalSettings.php), and there's no added bureaucracy, since granting and revoking the right remains the same.

For your second question, it's totally fine by me if it can be removed by another admin just like any other right; I'm not at all married to the idea of requiring community discussion for it. It's in there as an artifact of my thought process (I was thinking that, if there was a discussion already going on about an admin's articles, this gives that discussion another possible outcome), not as a necessary part of the proposal. Should I add that to the proposal proper, or is it not cool to change the wording once voting has started? Writ Keeper (t + c) 23:26, 22 March 2013 (UTC)

I think you should leave it out as it will muddle things. In addition, it isn't strictly neessary to decide it to implement the proposal. I'd be in favor of adding language to WP:AUTOPAT that gives some guidance as to when the right should be removed. Currently, it only discusses when it should be granted. At the AN discussion, TP offered his opinion on that issue, but it would be nice to discuss it a bit more and reach a consensus.--Bbb23 (talk) 23:58, 22 March 2013 (UTC)

• Support - Everything everyone has said about article creation not being necessary for adminship, and not all admins having article creation experience stands. I would add one further point. If an admin has little understanding of a certain area, they can simply avoid working in that area (I'm not comfortable editing MediaWiki pages, so I don't). Autopatrolled is different because it is automatic: any page I create will be autopatrolled, even if I don't trust myself enough for that to be the case. Thus admins who are aware of their inexperience in this area cannot avoid using a tool that they don't feel comfortable with. ItsZippy ^{(talk • contributions)} 22:59, 22 March 2013 (UTC)
• Support. From each according to his ability, to each according to his need. Kiefer.Wolfowitz 23:05, 22 March 2013 (UTC)
• Support - I likely would have turned it off my own autopatrolled bit if I could have after originally passing RfA. While I don't believe that this will make much of a difference in most cases, this can only help in those few cases it would make a difference in. As Bbb23 suggests, I'd prefer that "removing the autopatrolled bit" be something that an admin can do for cause without much process, a community discussion feels kinda heavyweight for something that comes down, more or less, to "Hey, those BLP stubs you make don't have any sources, I'd prefer they go through some tagging, etc." --j⚛e decker^talk 23:09, 22 March 2013 (UTC)
• Support - the edit filter manager is a separate flag because it's (rightly) assumed that the skills needed to admin and the skills needed to write and maintain edit filters are distinct; it seems reasonable enough to consider the autopatrolled flag in a similar vein. 28bytes (talk) 23:22, 22 March 2013 (UTC)
• Support. The case seems obvious enough, but will it ever happen? I doubt it. Malleus Fatuorum 23:25, 22 March 2013 (UTC)
• Support Generally speaking, autopatrolled is given in recognition of content-creation skill. Not all admins have this skill, and candidates who create few or no articles often do pass Rfa. So I don't think we should assume that a new article doesn't need to be patrolled merely because the creator passed an Rfa. Mark Arsten (talk) 23:54, 22 March 2013 (UTC)
• I can't think of any good reason to oppose it Support. I don't know that it would actually change very much, but I certainly don't object. — Ched :  ?  23:57, 22 March 2013 (UTC)
• Support I think this is a step in the right direction. I suspect that some other prominent WMF wikis do something similar, but I would need to do some research. --Rschen7754 00:01, 23 March 2013 (UTC)
• Support Anything to design those infallible admins everyone secretly wanted.84.106.26.81 (talk) 00:02, 23 March 2013 (UTC)
• Support I knew if I hung around here long enough an unbundling proposal that I could get behind would come along. As others have said, this right has absolutely nothing to do with being an admin, and it doesn't do anything to help admins do their job either, so it seems like a natural for unbundling. Beeblebrox (talk) 00:10, 23 March 2013 (UTC)
• Support This makes a lot of sense.--Amadscientist (talk) 00:14, 23 March 2013 (UTC)
• Um, how would this make a difference in practice, exactly? My understanding is that autopatrolled means that one can be trusted to create content that doesn't violate policies or guidelines, and I'd assume just about everyone who made it through RfA would fulfil that criterion. If an admin ends up having the flag removed via discussion, I don't think they'd have the requisite trust in their competence to do content-related admin work. I mean, if it's a symbolic thing or just sort of "why not", then by all means, but I just don't see it making an actual difference. wctaiwan (talk) 01:31, 23 March 2013 (UTC)

  And why would you assume that? Malleus Fatuorum 01:46, 23 March 2013 (UTC)

  More than one sysop above has stated they would remove this right from themselves if they could. Crazynas ^t 01:49, 23 March 2013 (UTC)

  I didn't read through the discussion carefully enough. I now see that it has some practical implications. Fair enough, then. wctaiwan (talk) 02:03, 23 March 2013 (UTC)

• Support - I'm all for unbundling the tools. Keilana|^{Parlez ici} 01:52, 23 March 2013 (UTC)
• Support. I don't know as it solves any actual problem, but I can't see any reason not to do it, there are arguments and lots of folks (above) in favor, and in principle unbundling of rights is generally indicated, all things being equal and if it doesn't cause any problems or significant extra work. Herostratus (talk) 02:50, 23 March 2013 (UTC)
• Support although, to be fair, if the mop wasn't focusing on content, he probably wouldn't be creating that many articles anyway pbp 04:48, 23 March 2013 (UTC)
• Comment: I'm in favour of this suggestion in principle, but an admin can grant themselves the Autopatrolled user right whether it's included in the package or not. Wouldn't this defeat the purpose? Chamal ^T•C 04:53, 23 March 2013 (UTC)

Firstly, this should be good for admins who are self-aware enough to recognise that their content contributions are not always up to scratch. Good admins should be able to self-evaluate, and this will allow them to do that. Any decent admin would remove their autopatrolled right themselves if there were legitimate questions about their content contributions, so forced removed probably won't happen that often. Secondly, if we do get to the stage where the community needs to remove the autopatrolled right from an admin, for the admin to reinstate their right after it was removed by the community would be in contravention of WP:INVOLVED, WP:CON, and possible WP:WHEEL; that would be cause for further action (though I hope we'd never get to that point). ItsZippy ^{(talk • contributions)} 16:59, 23 March 2013 (UTC)

• comment I notice that actual new page patrollers seem to be being largely ignored in this discussion which is unfortunate since they are the ones that autopatrolled is aimed at. Autopatrolled does not really apply any benefits to the user it is applied to. It simply provides new page patrollers whith a white list of users who are unlikely to be a problem. And the reality is that all active admins do belong on that whitelist. Remember New page patrols standards are pretty low. If it doesn't meet any of the speedy criteria or BLPprod, doesn't read like a copyvio and isn't a fairly straightforward hoax its going to pass (okey some other junk will be proded and AFDed but still the barrier is pretty low). While we have had admins from time to time who's had issues with copyright its not at the level that new page patrol is going to pick up. So please be aware that there is no practical benefit in doing this and any symbolic benefit has to be weighed against the admittedly small extra workload on the part of new page patrollers. It also needs to be weighed against the downside of making autopatrolled a bigger deal.©Geni 07:29, 23 March 2013 (UTC)
• Oppose, as a person who has patrolled hundreds of pages. C'mon, guys, think about it: The primary task of page patrolling is to find newly created articles that qualify for CSD. if you're not capable of creating an article that doesn't qualify for CSD, then you need to turn in all your admin bits, not just this one, because that means you don't understand our most basic policies. You should not be needlessly increasing the NPP workload and backlog just to make a point about being "fair" (in that even-Steven notion of fairness that is popular among five year olds, rather than among adults). WhatamIdoing (talk) 19:35, 23 March 2013 (UTC)

• WhatamIdoing, have you read Wikipedia:New pages patrol? The primary task is not to find newly created articles that qualify for CSD. It is to find (and hopefully fix) obvious problems in new articles. See Wikipedia:New pages patrol#Patroller checklists. Ryan Vesey 20:45, 23 March 2013 (UTC)

  I've not only "read" but also "helped write" that page. When you decide to mark a page as patrolled, the decision you are making is "I don't believe this page qualifies for speedy deletion". If it's not CSDable, then it should get marked as patrolled. (If you tag it for PROD or AFD, the page is automatically marked as patrolled.) The rest of the stuff about tagging various problems is superfluous. We trim it down every now and again, but it WP:CREEPs back in. WhatamIdoing (talk) 23:22, 23 March 2013 (UTC)

• Support This isn't really an unbundling as Autopatrolled is already unbundled, like Rollback all admins have it as part of the admin toolkit but it can, and often is, be issued to non-admins. So to be pedantic I would call it a removal. However I'd support it for the simple reason that getting notability right is a skill that not every RFA candidate has to have demonstrated. It would be perfectly possible for an experienced vandalfighter who has assisted in some GAs to pass RFA without ever creating an article from scratch. Or indeed gained deletion related experience as to where we draw the line between articles that belong and those that don't. I'd not expect such an admin to then submit hoaxes or copyvio, but I wouldn't be upset or surprised to find a new admin whose first article creations then showed them to be overly inclusionist re their favourite subject area. ϢereSpielChequers 19:53, 23 March 2013 (UTC)

• Question The comment here at WP:NPP that this removes "the autopatrolled right from all admins" is far from the way I read this proposal, but it does raise the question of what we do with the existing couple thousand admins. Obviously admins who had autopatrolled before adminship on their own should have it after debundling, but there's still the question of what to do about those who didn't have autopatrolled before adminship. I'm open to a wide range of answers, from "none of them has it until someone looks" to "all of them have it until/if someone looks", but we should probably figure out which it is. --j⚛e decker^talk 20:21, 23 March 2013 (UTC)

• The answer is that any admins who want it/think it would be good for them to have can have it, for this proposal at least. It's the same way that any admin can freely give themselves edit filter manager. The point is that separating it from the default admin package allows us to remove it from admins if it's necessary, and for admins (including possibly myself, and others who have said the same here) who would rather their contributions not pass through NPP without review. (As Ryan says above, NPP is not only for CSD patrolling.) Since any admin who should have autopatrolled will still be able to have it, the impact on the workload of NPP should be minimal. As I say, I'd be interested in an alternate system for granting autopatrolled, which could have an appreciable impact on NPP, but that's out-of-scope for this proposal. Writ Keeper (t + c) 21:26, 23 March 2013 (UTC)

See Wikipedia:Requests for permissions/Autopatrolled unless that was the system you meant we needed an alternative to. Ryan Vesey 21:47, 23 March 2013 (UTC)

It's not exactly that; I meant that we should take a look at the standards for granting/removing it and the like. Again, that's another conversation for another day. Writ Keeper (t + c) 21:57, 23 March 2013 (UTC)

As an aside, if and when this proposal gets implemented, we should advertise it in some way, so that any admin who feels they should have it knows to grant it to themselves; alternately, we could go through and grant the autopatrolled right to all current admins with an adminbot, and then any admin who doesn't want it can remove it from themselves. Writ Keeper (t + c) 21:28, 23 March 2013 (UTC)

Indeed. If an admin bot were called for, I could certainly put one together. --j⚛e decker^talk 21:54, 23 March 2013 (UTC)

• Support I can't really expand on any of the above comments. Assuming this isn't incredibly difficult to do, I'd support it if even one administrator didn't want it. Ryan Vesey 21:47, 23 March 2013 (UTC)
• Oppose NPP here. The point of of patrolling new pages is checking articles for obvious problems. Notice the emphasis on the obvious? I think admins can be trusted to write articles with no obvious problems (attack pages, gibberish, etc.) If they can't, they probably shouldn't be admins. Plus, us patrols have enough to work with already. Our backlog has been at a month for nearly 18 days now. Revolution1221 (talk) 22:02, 23 March 2013 (UTC)

• That's a nice idea in theory, but in practice, it would never happen, since removing an admin bit requires Arbcom intervention. And again, note that this should have little to no actual impact on NPP, at least initially, and especially if we re-add autopatrolled to all admins via an adminbot and let any that don't want it remove it themselves. Writ Keeper (t + c) 22:10, 23 March 2013 (UTC)

I wouldn't want to burden new page patrol, but admins are not supposed to have any special authority, real or implied, when it comes to actual content and we do have a lot of admins who would not otherwise qualify for this userright, in fact I think I am probably one of them. Frankly I like the idea that any page I might create will be double checked, I mostly do admin work these days as opposed to content work and they are two very different skill sets. Like anything else, if you don't use it you tend to get a little rusty and make mistakes you might not have made when you were using those skills more regularly. Beeblebrox (talk) 22:15, 23 March 2013 (UTC)

Do you believe that you have "special authority" when editing a page under WP:Pending changes? Admins don't need to have a second editor manually check their changes to PC-protected pages. This is really no different. Having this right on all the admins means that no second editor needs to manually check the new pages created by admins. That's all it does. It does not prevent someone from seeing that you've created a page (it's still listed in the same queue, just not highlighted in bright yellow) and it does not prevent someone from sending it for deletion. WhatamIdoing (talk) 23:22, 23 March 2013 (UTC)

I don't buy the premise of your comparison at all, they are quite different. The purpose of PC is to prevent vandalism, which an admin is in fact expected to have a solid understanding of. Also, the reviewer right is deliberatley very easy to get, about the same as rollback. Autopatrolled has much higher requirements. Beeblebrox (talk) 17:59, 24 March 2013 (UTC)

The primary purpose of NPP is to find articles that qualify for speedy deletion, which admins also ought to have a solid understanding of. WhatamIdoing (talk) 02:04, 29 March 2013 (UTC)

• Support as an admin - this isn't directly related to admin tasks, so admins shouldn't have it automatically. I have no opposition to admins granting it to themselves on a 0RR basis - if an other admin revokes it, they don't take it back themselves. עוד מישהו Od Mishehu 22:24, 23 March 2013 (UTC)
• Comment^{1st para}/Oppose^{2nd para}: The ground is not prepared to cultivate this idea at this moment. In a recent RFA, where I was nominator, the candidate had 100,000+ edits but not too many project space edits and NO bot/automated edit. There it was told, he does not need the admin tools since he has not worked too much there (not a bad point though). But, all the user rights we have are administration/management related. There is nothing for content creators other than this autopatrolled. In future, I hope to see user rights are being divided into two groups a) management related b) content creation related (to explain the second, "Content dispute", where a non-admin editor who is regularly doing studies and research to create/expand articles might be helpful, but, we have no such right). Unbundling only one right (i.e. autpatrolled, because it is not directly related to adminisration) does not make proper sense. Prepare the ground first and unbundle content creation related rights as a whole.
  From another point of view, I'll not like to see someone's user rights in the TParis's or similar page: User:Example "Sysop, autopatrolled"! Autopatrolled should be bundled with with admin's rights. But, there might be an option that they can remove that right/other rights (like Filemover, I think there are admins who don't need that tool) if needed. But, removing it by default does not sound fair (per WhatIamdoing)! --Tito Dutta (contact) 00:03, 24 March 2013 (UTC) oppose strike-through, signed --Tito Dutta (contact) 18:13, 24 March 2013 (UTC)

• Tito, your second to last sentence ("But, there might be an option that they can remove that right") is the point; this proposal is what will enable that to happen. The point is not to disallow admins from having autopatrolled until they apply for it. The point is that it is currently impossible--literally, there-is-no-physical-way-to-do-it impossible--to be an admin without also having the autopatrolled right. By removing the autopatrolled right from the admin package, we stop forcing admins to also have the autoconfirmed autopatrolled right. As the proposal says, any admin can freely give themselves the right; we can and will go through and manually (well, through a bot, but still) add the "autopatrolled" right to all admins, so that their rights will have effectively not changed. The only things that will have changed are that a) admins who don't want the right--there are several, including myself--gain the ability to turn it off without having to surrender all their admin rights and b) the right can be removed from admins who shouldn't have it without having to completely desysop them (which is not an implausible scenario). It's Zippy makes an excellent point above: the reason autopatrolled should be singled out is that it is a right which an admin cannot avoid using. All the other rights in the kit are very specific; avoiding the use of the right is simple, just don't use it. With autopatrolled, however, currently the only way to keep from using it as an admin is by either never creating any articles ever again, or by resigning all of the admin tools. This proposal gives us more flexibility than that. Writ Keeper (t + c)

_{forcing admins to also have the autoconfirmed right... Crazynas ^t 04:23, 24 March 2013 (UTC)}

Not sure if this is what you were pointing out, but yes, I did mean "autopatrolled", not "autoconfirmed" there, thanks! Writ Keeper (t + c) 04:33, 24 March 2013 (UTC)

Indeed. Crazynas ^t 05:03, 24 March 2013 (UTC)

• Support - I agree that admin user rights are overly broad. If the privilege were removed tomorrow there probably wouldn't be anything more than a marginal uptick in workload at NPP since admins are doing very little article creation. Marcus Qwertyus (talk) 05:07, 24 March 2013 (UTC)
• Conditional support Makes sense, but support only if any admin gets the right automatically granted, who have hold it before being promoted. Armbrust ^{The Homunculus} 11:37, 24 March 2013 (UTC)
• Support as an admin for 8 years, I support this. While it would be awesome to assume that all admins are capable of perfect judgement and would never make a bad article, that just isn't true. Andrew Lenahan - Starblind 15:19, 24 March 2013 (UTC)
• Support. Quite reasonable to allow admins not to assume the right unless they feel comfortable taking it on. Choess (talk) 17:36, 24 March 2013 (UTC)
• Oppose Just what problem is this supposed to solve? From time to time i check patrolled articles on NPP to see if there is any abad patrolling, and also to see if there are any problems with those having the right, and I do not remember seeing any problems with administrators. I suppose there must be some, or what would this proposal have been initiated. DGG ( talk ) 20:12, 24 March 2013 (UTC)
• Oppose. Given that most NPPs say there are no problem to be solved by this, then this looks like a useless move; or it may be an attempt (not necessarily by the starter) to unbundle whatever "something" out of the admin rights to establish a precedent, in which case it would be worse. - Nabla (talk) 20:34, 24 March 2013 (UTC)

So you don't believe administrators should have the right to not use one of their tools? (as pointed out numerous times above, this is the only right in the administrator package which is a passive 'status' as it were, not an active button you can choose not to use.) I was also unaware that consensus was binding.Crazynas ^t 21:10, 25 March 2013 (UTC)

As you clearly say, it is not a "tool" it is a "flag", a sign that this one is a unlikely problematic article creator, by definition a admin (supposedly someone how knows and abides by policy) is one such user. - Nabla (talk) 17:45, 28 March 2013 (UTC)

• Oppose. Not because I'm an admin who wants to keep his rights, but because of the opposition from the newpagepatroller people. New users are more likely than admins to be creating problematic pages, and if the patrollers don't have time to keep up with just the new users and non-new people without autopatrolled, they definitely don't have the time to keep up with the new users, the non-new people without autopatrolled, and lots of the non-new people who would lose autopatrolled because of this proposal. I'm an admin, but I wouldn't mind losing the right if necessary. Nyttend (talk) 21:35, 24 March 2013 (UTC)

• There wouldn't be a lot of people losing autopatrolled because of this proposal. Admins who didn't want the right could get rid of it on their own account. Admins who shouldn't have the right can have it taken away by community consensus. The vast majority of administrators will have and keep the right. Ryan Vesey 01:15, 25 March 2013 (UTC)

• Support for many of the reasons already given above. I would also like to see more proposal along these lines.Volunteer Marek 21:38, 24 March 2013 (UTC)
• Support - There are doubtlessly administrators who are proven vandal fighters who may or may not understand the fine points of notability or copyright law. It makes sense separating advanced editing rights from advanced site maintenance rights. Grandfather in all current admins. Carrite (talk) 01:07, 25 March 2013 (UTC)
• Support Not specifically related to administrator work, and, for what its worth, the right should be optional anyway. If they would like the right and their understanding of policy can be proven, then an administrator as any other editor may have the autopatrolled right. TBrandley 01:15, 25 March 2013 (UTC)
• Support this proposal, seems sensible, logical, and rational. — Cirt (talk) 03:26, 25 March 2013 (UTC)
• Oppose nobody has presented any evidence that this proposal is desirable or necessary, and it seems to be proposed for political reasons rather than as a result of a genuine need on the ground. It's been a while since I did any new page patrolling, but the barrier to getting an article patrolled is very low - a check to see if the article should be speedily deleted and possibly common cleanup tags or formatting problems. On the other hand this proposal will increase the workload of NP patrollers, which is already very high. Hut 8.5 10:52, 25 March 2013 (UTC)
  • When BLPprod came in we removed AutoPatrolled status from several editors, and I seem to remember we had issues with one admin, others may remember other incidents. As for the burden on newpage patrollers, I would anticipate that the number of new articles created by admins who didn't have this right before their RFA would be quite low. ϢereSpielChequers 11:07, 25 March 2013 (UTC)
    • We once had problems with one admin? That's it? Wow! It is a serious problem we must address it right away! Also, you say this about to change almost nothing. Why change then? - Nabla (talk) 20:59, 25 March 2013 (UTC)
    • Do you have any links? One vaguely remembered incident from several years ago (which from your description seems to have resulted from a change in community expectations) isn't a very compelling case. Regarding pages created by administrators, while many administrators probably don't create pages very frequently (including me), the standard for getting the autopatrolled right is low (you need to demonstrate an understanding of BLP, verifiability, notability, and copyright) and I imagine administrators will meet it. This will be particularly true of recently appointed administrators given the steadily rising standards at RfA. Hut 8.5 21:09, 25 March 2013 (UTC)

      Not as low as you think. You need to have created a minimum of 50 articles, something that very few administrators have done. The point of unbundling in this case is one of natural justice; a non-admin who creates a non-compliant article will have the autopatrolled user right removed, but the only way an administrator guilty of the same offence could have the right removed would be a desysop. Malleus Fatuorum 21:16, 25 March 2013 (UTC)

      The 50 article rule is only a "suggested standard". You have to demonstrate you "are familiar with Wikipedia's policies and guidelines, especially those on biographies of living persons, copyrights, verifiability and notability" (Wikipedia:Autopatrolled). With the possible exception of notability, a basic understanding of those named policies ought to be a prerequisite for adminship. Proposing changes for political reasons - including perceived "justice" - isn't a very good practice. We ought to change things based on evidence that they are actually causing a problem. Hut 8.5 22:31, 25 March 2013 (UTC)

      The constant cry at RfA is that you must have demonstrated your understanding of all the super important stuff that admins do by, you know, actually doing it. Why is autopatrolled different? You demonstrate a understandng of deletion policy by taking part in AfDs, for instance, and your speedy deletion nominations are examined in infinite detail. Similarly, your understanding of article creation guidelines ought to be demonstrated by actually creating articles. But content creation isn't considered to be important for an RfA candidate, so why allocate a user right they have exhibited no understanding of? Malleus Fatuorum 22:52, 25 March 2013 (UTC)

      There's content creation and there's content creation. Administrators certainly ought to have some understanding of our core content policies, if only because they tend to crop up everywhere. On the other hand because they tend to crop up everywhere most experienced editors will already have that understanding. The trend at RfA is for the much higher requirement of GAs and FAs, which is excessive (in my opinion, anyway - lots of people disagree [3]). The requirement for getting autopatrolled is similar to the lower of these two. After all most NP patrol deals with very new editors who know almost nothing about our standards. Hut 8.5 11:13, 26 March 2013 (UTC)

      " After all most NP patrol deals with very new editors who know almost nothing about our standards." That's not true. Take a look at the number of articles J3Mrs (talk · contribs) has created for instance, or Parrot of Doom (talk · contribs). Many prolific content creators don't have the autopatrolled user right. Malleus Fatuorum 11:52, 26 March 2013 (UTC)

      I'm sure there are many prolific content creators who don't have the autopatrolled right. That doesn't mean that most NP patrol work isn't concerned with new editors. Hut 8.5 12:24, 26 March 2013 (UTC)

      Just saying it doesn't make it so. Looking at the top 20 or so articles most recently created I see quite a few written by editors with thousands of edits who've been here for years, some with as many as 76,000 edits. Malleus Fatuorum 12:57, 26 March 2013 (UTC)

      Looking at the 20 most recently created unpatrolled pages I can only see one created by someone with over 500 edits (they had 1890). On the other hand I see 6 pages created by people with under 10 edits. Looking at a raw list of new pages isn't going to give a very good indication of the problem here because it includes pages created by people with the autopatrolled right. Hut 8.5 17:28, 26 March 2013 (UTC)

• Support. People who are given the mop who have already created more than 50 articles should also be granted autoreviewer status, and admins who want are serious about content creation will get right soon enough. Andrew³²⁷ 15:31, 25 March 2013 (UTC)
• Support - Really don't see too many flaws in this idea, can't add much more than most of the supports here. It doesn't detract from anyone's abilities to work, after all. Lukeno94 (tell Luke off here) 16:44, 25 March 2013 (UTC)
• Support, not required for admin work. Lectonar (talk) 16:50, 25 March 2013 (UTC)
• Support As a general rule, I'm not sure why rights that exist as their own flags should be swept up into the admin flag. Courcelles 17:50, 25 March 2013 (UTC)

  Because there's a cultural inertia at work. To take another example, why should admins be allowed to give themselves the edit filter user right, rather than be asked to request it in the way that non-administrators are required to do? There are several levels of answer to that question, but they all boil down to "admins good, non-admins bad". Malleus Fatuorum 23:03, 25 March 2013 (UTC)

• Oppose Absurd considering the size of the NPP backlog. Once we get it down to a reasonable length (less than 10 days), we could consider this. ⇌ Jake Wartenberg 23:09, 25 March 2013 (UTC)

  What effect will this proposal have on the NPP backlog? Nobody is proposing taking the autopatrolled user right away from all administrators, simply unbundling it so that it can be removed if desired or necessary, just as it can with regular editors. Malleus Fatuorum 23:12, 25 March 2013 (UTC)

  Based on the wording above and the discussion that follows that is exactly what is being proposed. To take it away from all admins and then give it back to those who should have it. -DJSasso (talk) 12:53, 26 March 2013 (UTC)

  I suggest you try reading all the words in the proposal, assuming you've actually read any of it, which frankly seems unlikely. Malleus Fatuorum 04:04, 27 March 2013 (UTC)

  The proposal is to remove the autopatrolled right from the administrator user access group. Unless someone writes an adminbot to give all current admins the separate autopatrolled right this will result in all administrators losing the autopatrolled right, at least initially. Administrators will retain the ability to grant autopatrolled to themselves, but unless and until an admin does that then any pages they create will have to be reviewed by NP patrol. It's a good question how many admins will grant the right to themselves, since most won't even realise it's gone. Hut 8.5 11:50, 27 March 2013 (UTC)

  Then I suggest you brush up on your reading level and on how the wiki software works. As Hut 8.5 mentions unbundling it will require it being removed from all admins as a function of how the software works. So unless an admin gives it back to themselves or someone else gives it to them such as an admin bot. All admins will lose the right as part of this proposal. -DJSasso (talk) 11:56, 27 March 2013 (UTC)

• Weak to moderate support. In the end, I think this is just a token move. I doubt it will make much difference in practice: I can't properly imagine a situation where this bit won't be handed out to a newly chosen admin. But it's not a bad token, and the workload it generates will be negligible. On the question 'what problem does this solve', I think the answer is that it will make admin less of a big deal (it's too much of a big deal at the moment), it will lower the perception that Admins are godly creatures that can only do correct things that some may have. Those are not very strong points IMO, but points nonetheless. The NPP backlog is One Of Those horrible horrible backlogs. A responsible admin doing a lot off article creation will probably have already requested that bit, or should request it ASAP (actually, with or without admin bit, if you create a lot of articles, request it ASAP.). We pass about 4 admins a month. We can deal with handing out 4 extra autopatrolled bits a month, if every admin were to request one. Martijn Hoekstra (talk) 23:20, 25 March 2013 (UTC)
• Support A very reasonable proposal and I doubt that it will create that much more work for NPPers. AutomaticStrikeout (T • C • AAPT) 02:30, 26 March 2013 (UTC)
• Oppose This is a solution in search of a problem. And besides, autopatrolled criteria are already too strict. I've made 20-30 articles; I know better than to make something that can be CSDd. Content creation might not be in the admin job description, but it's a basic of Wikipedia which potential admins should show competency in. If you can't trust an editor to make good articles, you shouldn't trust him or her to be an admin in the first place. --BDD (talk) 20:05, 26 March 2013 (UTC)
• Oppose - Would cause an unnecessary increase in the number of articles that need to be patrolled. And, the vast majority of those articles should not need much help. So, this is essentially an exercise in increasing the inefficiency of NPP. Per WP:AUTOPATROL, having the autopatrolled user right "...means that the user can be trusted not to submit inappropriate material, deliberately or otherwise..." I'm reasonably sure we can trust admins to not submit inappropriate material as much as we can trust any non-admin that already has the autopatrolled right, although I suppose you could accuse me of being biased in that regard. ‑Scottywong| prattle _ 21:17, 26 March 2013 (UTC)

  That would only be true if the proposal were to remove the autopatrolled user right from administrators, but it isn't. Malleus Fatuorum 21:32, 26 March 2013 (UTC)

  That's not really made clear in the proposal. It is never clearly stated that the proposal is only to unbundle the right, not to strip every admin of the right and force them to apply for it if they want it. The proposal contains statements like, "any admin who needs it can simply grant it to themselves" which implies that we would need to grant it to ourselves if this proposal were to succeed. Furthermore, my gut reaction is that if an admin does something so abusive that we agree that he should no longer have the autopatrolled right, then I would probably be in favor of desysopping that admin. If an editor isn't capable of creating an article that doesn't violate core policies, then they probably shouldn't be admins. Note that I'm not saying that an admin who creates an article with spelling/grammar errors, poor wording choice, bad formatting, etc., should be desysopped, because none of those minor issues are requirements for getting the autopatrolled bit. But, if an admin makes a habit of creating articles with copyvios, or libelous unsourced BLP's, then they should probably not be an admin. Therefore, the unbundling is unnecessary. ‑Scottywong| chatter _ 22:11, 26 March 2013 (UTC)

  Really? The title of this proposal is "Unbundle autopatrolled from admin rights package", not "Remove autopatrolled from admins". The edit filter user right is already unbundled, for instance. Would you equally propose that administrators unable to write regular expressions ought to be desysoped, rather than have that user right removed? And please don't give me any guff about "trust"; the overwhelming majority of administrators were promoted before that user right existed. Malleus Fatuorum 22:16, 26 March 2013 (UTC)

  That's not a valid comparison. The edit filter right doesn't come with adminship, whereas autopatrolled does (and you're claiming that you're not trying to change that). There are tons of user rights that you don't automatically get as an admin, here's a partial list: bigdelete, checkuser, hiderevision, importupload, abusefilter-modify, oversight, renameuser. There is a reason why these user rights don't come with adminship, mostly because they each require specialized knowledge (like regex) and/or an advanced level of trust (which may or may not include identifying yourself to WMF). The autopatrolled user right requires neither specialized knowledge or an advanced level of trust. It requires a simple level of familiarity with Wikipedia core content policies, which every admin should have. If you don't know that copyvios are bad, then you shouldn't have passed RfA in the first place. If you knowingly commit a copyvio as an admin, you shouldn't be an admin anymore. That's all there is to it. ‑Scottywong| squeal _ 22:37, 26 March 2013 (UTC)

  I thought you retired, anyway. You must hear that a lot. Glad to see you're back, doing useful things like badgering opposers of this thinly veiled attempt at a political statement useless proposal. ‑Scottywong| prattle _ 22:57, 26 March 2013 (UTC)

  I doubt you thought at all. I bet you hear that a lot. Malleus Fatuorum 23:48, 26 March 2013 (UTC)

  Scottywong: What is you're opinion on the administrators above who wish to remove (give up) the right themselves? cf. ItsZippy, joe decker and Beeblebrox, regards, Crazynas ^t 00:35, 27 March 2013 (UTC)

  Probably unsurprisingly, I can be added to that list. Writ Keeper (t + c) 01:02, 27 March 2013 (UTC)

  Me too. Lectonar (talk) 11:42, 27 March 2013 (UTC)

  Perhaps it's a result of a misunderstanding of what actually happens at NPP in reality. Typically, each article is briefly checked to ensure it doesn't qualify for speedy deletion. Cleanup tags may or may not be added to the article if it has glaring problems (i.e. no references, no categories, not neutral, reads like an essay, etc.). If it's a stub, a stub tag might get added to it. The most ambitious patrollers might actually spend a few minutes fixing some major problems (adding footnotes, categories, etc.). However, it is extremely unlikely that a patroller is going to spend a half hour examining your article and making detailed fixes to minor problems. That's just not a realistic expectation. There are far too many articles coming through the fire hose for a patroller to spend more than a minute or two on any one article. So, considering that reality, if an admin truly believes that he/she is incapable of reliably creating an article that doesn't qualify for speedy deletion, or creating an article that doesn't have major problems with it... then perhaps that admin should simply not create new articles at all, and perhaps they should question why they are an admin or why they are here in the first place. Look, I'm no great writer, nor am i a prolific content creator, but I'm confident that I can create an article that doesn't suffer from major problems. Any admin should be able to get over this very low bar, and therefore should not be concerned with their autopatrolled status. ‑Scottywong| spout _ 03:34, 27 March 2013 (UTC)

  More likely it's ignorance of what actually happens at NPP in reality, or what should happen. Malleus Fatuorum 03:55, 27 March 2013 (UTC)

  What should happen at NPP and what does happen are different things, without a doubt. That is a consequence of the practical realities of how NPP works, the number of editors that actively patrol new articles, and the rate of article creation. ‑Scottywong| comment _ 04:36, 27 March 2013 (UTC)

  I agree with Scottywong here: The reality is that NPPers normally spend one minute or less on patrolling a page. Click here to see whether anyone is active; if someone is patrolling pages right now, then you'll be able to see what the average length of time between pages is. WhatamIdoing (talk) 02:14, 29 March 2013 (UTC)

• Oppose - Any user who can't be relied upon to create valid pages is a user who should not be trusted with speedy-deletion determinations -- that is, a user who shouldn't be an administrator. Furthermore, since administrators now have the capability of granting or revoking the "autopatrolled" user right, unbundling this from the admin tools package would also logically mean that admins also should not be able to grant this user right, meaning that there would need to be a whole new bureaucracy created to grant/revoke "autopatrolled". --Orlady (talk) 21:53, 26 March 2013 (UTC)
• Oppose - If an admin creates problematic new articles, then the first thing to do is to warn them. If that doesn't work, and their problem just keeps getting worse, I see no reason not to desysop: 1) They technically have abused the admin right, specifically the autopatrolled portion of it; 2) Someone who repeatedly makes the same lapse in judgment really does not deserve to be an admin. Admins have been desysopped in the past for things like copyright violations, so removing the tools for content-related issues is not unheard of. -- King of ♥ ♦ ♣ ♠ 22:04, 26 March 2013 (UTC)
  • All of this is irrelevent for the issue at hand - whether the "autopatrolled" ability should be part of the admin package. Should any article I (an admin) create automatically be marked as patrolled? I, personally, think not. That's the issue here. עוד מישהו Od Mishehu 11:49, 2 April 2013 (UTC)
• Support - If an admin creates problematic new articles then we should be able to remove this right without having to go through the whole desyop process. AIRcorn (talk) 23:53, 26 March 2013 (UTC)

  Quite simple really. I'm rather surprised to see so many admins Hell bent on the idea that rather than have their autopatrolled user right removed they'd prefer to be desysoped. Malleus Fatuorum 03:59, 27 March 2013 (UTC)

  The issue is that if admins cannot be trusted to create articles without issues, then they also cannot be trusted with the delete tool. -- King of ♥ ♦ ♣ ♠ 04:19, 27 March 2013 (UTC)

  That's an entirely separate issue. Would you equally say that administrators unable to write regular expressions cannot be trusted with the delete tool? Have you forgotten that content creation is considered to be irrelevant at RfA? Or do you just not care about making Wikipedia a more rational environment as opposed to a petty feudal oligarchy? Malleus Fatuorum 04:28, 27 March 2013 (UTC)

  Content creation is not "irrelevant" at RfA. It may not be as relevant as you personally want it to be, but it is far from irrelevant. ‑Scottywong| gab _ 04:50, 27 March 2013 (UTC)

  Perhaps you missed Wikipedia:Requests for adminship/Jimp. Candidates are indeed promoted based on the skill and cluefulness that they've demonstrated in areas other than content creation. Having created zero articles doesn't mean they're a bad admin; we all have different strengths and weaknesses, and requiring a desysop rather than turning off the autoreviewed flag for admins who haven't demonstrated article creation skills seems to me to be throwing out the baby with the bathwater. 28bytes (talk) 05:03, 27 March 2013 (UTC)

  Huh? ‑Scottywong| chat _ 05:09, 27 March 2013 (UTC)

  I don't think article splits and disambiguation pages (while useful) are what are traditionally considered "content creation." Should someone who has never added a source to an article be exempt from having new page patrol check their article creations? Sometimes, sure. But deciding that on a case-by-case basis seems more reasonable to me than the status quo of "only if they're an admin." 28bytes (talk) 05:26, 27 March 2013 (UTC)

  Are there any examples of articles created by an admin that slipped through the cracks and persisted for an extended period with major, policy-violating problems? Perhaps if someone can demonstrate that this is a problem that happens with some regularity, it might indicate why there is a need for this proposal. ‑Scottywong| yak _ 09:59, 27 March 2013 (UTC)

  Yes there are, and even at least one arbitrator. I don't want to point the finger at anyone for past mistakes, but many will know who I'm referring to. Malleus Fatuorum 15:38, 27 March 2013 (UTC)

  You don't want to point out other people's mistakes? When did that start? Anyway, were these isolated, one-time mistakes or were there demonstrated patterns of were any of the admins/arbitrators sanctioned or desysopped for these mistakes? I'm not aware of the event(s) you're talking about because I generally don't follow arbcom cases very closely, but it would be helpful to see a specific case, so that we could judge for ourselves if it was actually an edge case where it would be appropriate to remove autopatrolled rights but not desysop. ‑Scottywong| confabulate _ 15:57, 27 March 2013 (UTC)

  I suggest that you consider very carefully whether your usual attack dog style is appropriate before making any further personal remarks. But as you seem to be ignorant of the potential problem here you could do worse than investigate the background to the case of Grace Sherwood. Malleus Fatuorum 16:06, 27 March 2013 (UTC)

  That article was created by an IP, so it wouldn't have mattered whether or not the admin had autopatrolled rights. It would have been patrolled (if NPP existed back when that article was created). Any other examples? (Given that this proposal would only protect us from admins who specifically create new articles that are problematic, it would be more helpful to see examples of admins actually creating new articles that are problematic, rather than examples of admins making problematic edits to existing articles, since this proposal doesn't address that problem.) ‑Scottywong| comment _ 17:00, 27 March 2013 (UTC)

  That example isn't relevant at all. The article was created five years before the offending admin touched it, so new page patrol didn't have a chance to spot any problems. The admin concerned had written over 100 articles as well as a number of FAs and DYKs, so they would certainly have qualified for autopatrolled through the normal process. Even if none of that was true a quick look by a new page patroller couldn't possibly have caught problems that were missed by FAC. The ability to remove autopatrol without desysopping wouldn't have helped either since the admin resigned shortly after the problems came to light. Hut 8.5 17:26, 27 March 2013 (UTC)

  And, that article was never patrolled, since NPP and Special:NewPages didn't exist in 2005. I believe what Malleus is trying to show us is that there is at least one example of an admin adding content to an article that violates copyrights. The example situation given, however, would not be fixed by this proposal, and furthermore, I doubt that such events have happened with sufficient frequency to actually show up on the radar as a legitimate problem that needs to be solved with this unbundling. Frankly, I see this as yet another attempt by Malleus to posit that content creators are better than and/or more valuable to the project than administrators, perhaps motivated by a deep-seated resentment of his own failed attempts. If anything is pushing Wikipedia closer to being a "petty feudal oligarchy", it is this type of attitude. I believe that Writ Keeper started this proposal in good faith, but the original AN discussion certainly shows the motivations for suggesting that this idea be proposed by someone, and Writ Keeper simply took the bait. ‑Scottywong| chatter _ 17:37, 27 March 2013 (UTC)

  Your persistent personal attacks demonstrate very clearly that your opposition to this proposal is based solely on your dislike of me. All I can say is the feeling is most definitely mutual. Malleus Fatuorum 17:45, 27 March 2013 (UTC)

• Oppose - Anyone who becomes an admin should be capable of judging submitted material, otherwise they shouldn't be granted the admin tools at all. To be trusted with posessing the admin tools in my opinion also includes the ability to judge article content. -- Toshio Yamaguchi 11:14, 27 March 2013 (UTC)
• Comment I'd like to address some spoken and unspoken questions about my motivations for proposing this. Someone above suggested that this is a political statement, which presumably means they think I'm trying desperately to kiss Malleus's ass for some reason. Not sure why I would want to do that, but it doesn't matter, because it ain't true. What happened was that while I was reading the AN thread, I thought to myself, "Hmm, this sounds like a really good idea, and I can't really see any significant downsides to it if properly implemented; someone should act on this." When Malleus said he wouldn't propose it himself, I thought "Damn, I really would've liked to see that go through." Then I realized the obvious that I could actually get off my lazy butt and propose it myself, so I did.

My real motivation is that it has bothered me for some time at how little sense the admin package makes, if you look at it in terms of the rights it contains compared to the taasks usually thought of as admin tasks. Autopatrolled is one of those rights, and it's the easiest one to unbundle from the admin rights package, since there's already a framework for providing it outside of the admin package. Someone above mentioned that this could be setting a precedent: actually, I personally hope so, but not perhaps in the way one might think. I'd like to see other rights not closely associated with admin tasks be removed from the admin package, as well. The two others I've thought about are editinterface and edituserjscss. Now, both of those are different from autopatrolled in that there's no mechanism for providing them outside the admin framework, so a proposal for them would have significant bureaucratic overhead. Also, they're both pretty destructive rights; so is editfiltermanager, though, so I would think they could follow the same model.

Now, I didn't emphasize this line of thought in my proposal (though I touched on it briefly), because I didn't think it would have very much appeal to other people. It's the kind of thing where people might say, "yeah, that kind of makes sense, but there's no urgent problem so no". I know the old maxim "if it ain't broke don't fix it", but in this case, I personally don't think mere inertia and resistance to change for its own sake is a good reason to oppose, when we can confidently predict that there will, in fact, be little to no negative impact, on the NPP backlog or anything else (cf. the discussion above around Joe Decker's !vote, where we discuss making an adminbot to go around and manually add autopatrolled to all current admins and let them opt out of it if they like.) Writ Keeper (t + c) 13:27, 27 March 2013 (UTC)

• • The proposal will undoubtedly have some negative impact. If we don't make an adminbot then the number of pages needing patrolling by new page patrol will go up, at least until some editors run around giving autopatrolled flags to admins who create large numbers of new pages, or remind those admins to give themselves the flag. If we do write an adminbot then someone will have to write it, host it, review its output to make sure it's working properly, approve it (which per policy would require a separate community discussion), and it would generate about 1500 useless log entries. The benefits of the proposal, on the other hand, are purely hypothetical at the moment. Hut 8.5 13:59, 27 March 2013 (UTC)
    • Well, considering that we need devs to make this change for us, we'd have time for all that. Is that really a drawback if someone's willing to do it? Writ Keeper (t + c) 14:13, 27 March 2013 (UTC)
    • Better still, when you make the change leave autopatrolled flipped on for all admins who were Autopatrollers before they became admins. I doubt that the rest of us actually create many new articles. ϢereSpielChequers 14:32, 27 March 2013 (UTC)
      • What's the adminbot for? According to Malleus (in response to my vote above), this proposal is only to unbundle the user right so that it can be removed if necessary/desired, not to remove it from every admin account by default. ‑Scottywong| confabulate _ 14:34, 27 March 2013 (UTC)
        • As a purely technical consequence of unbundling the right from the admin package, it would be removed from all admins, since there aren't any admins who currently hold the admin package and autopatrolled separately. So, we use the adminbot to go and readd the autopatrolled right separately, since as Malleus correctly says, this proposal is not aimed at removing it from every admin account by default. (If it's not clear, the adminbot is a one-time thing, not something that would be run continuously.) Writ Keeper (t + c) 15:25, 27 March 2013 (UTC)
• Oppose with understanding of supporting viewpoint. Though I commend the proposer for such a well though-out and rationalized proposal, keeping the autopatrolled permission reduces the workload of anti-vandal editors such as myself; I come across far too many ClueBot NG flagged administrator edits, and I've never had a single one that I wanted to revert (and it has nothing to do with them being administrators - they simply tend to make good edits due to the fact that they have to establish a history of positive edits in order to become an administrator). The benefits of removing this permission do not supersede what we stand to lose in time resources. On the rare instances where administrators are "abusing" (even inadvertently) the right, I posit that, odds are, they will, eventually, be caught and that there are few enough administrators that, when this occurs, it will be dealt with appropriately and not become and epidemic. Jackson Peebles (talk) 17:01, 27 March 2013 (UTC)

• The autopatrolled permission has literally nothing to do with anti-vandal efforts. Ryan Vesey 17:13, 27 March 2013 (UTC)

• Support Far too much OWNing of the current package without thinking of other possibilities. Intothatdarkness 18:08, 27 March 2013 (UTC)
• Support - heh, I didn't realize previously that "doesn't qualify for autopatrolled" could be technically legitimate grounds for oppose vote in RfA. Also per Kiefer.--Staberinde (talk) 18:11, 27 March 2013 (UTC)
• Support - per most support !votes. Mlpearc (powwow) 18:31, 27 March 2013 (UTC)
• Oppose. Another solution in search of a problem. Ruslik_Zero 19:25, 27 March 2013 (UTC)
• Oppose – Will create extra work with no practical benefit. Graham87 13:26, 28 March 2013 (UTC)
• Weak oppose There's no admin task that I'm aware of for which autopatrolled is required, or even helpful, and it's totally correct to say that a good admin does not necessarily make a good content producer. However, it's taken as read that any admin has a fairly comprehensive knowledge of the minimum requirements of article creation, and one would expect them to adhere to those requirements in their article work (besides which, content creation stills carries considerable weight at RFA, see: just about every single RFA ever filed). As such, whilst there's no self-evident reason for them to have it, I can't see any particularly convincing reason for not giving admins the AP right as part of the package, though I'm happy to reconsider if someone can point to an admin with a disasterous record of post-mop article creations (*quickly checks own contrib history; no, looks ok...*). Yunshui 雲‍水 13:38, 28 March 2013 (UTC)
• Oppose on two grounds:
  1. If a person is not trusted enough to have the auto patrolled bit then they should not be an admin in the first instance;
  2. Because, "Any administrator can grant this right at their discretion..." Therefore an admin can simply grant it to themselves.
  The latter point is the most significant as it makes the proposal moot. --<spayn style="color:black;">RA (talk) 13:56, 28 March 2013 (UTC)
  • It's also technically possible for an admin to unblock themselves if they've been blocked; that doesn't mean they're allowed to do it, or that such an action would be tolerated. Writ Keeper (t + c) 14:18, 28 March 2013 (UTC)
    • Yes, I'd say that if we allow admins to give themselves the right only on a 0RR basis, then your second issue is no longer correct. עוד מישהו Od Mishehu 12:20, 29 March 2013 (UTC)
• Oppose. I am an admin, but I don't see having autopatrolled as a benefit to myself, since I don't notice it. Rather, the fact that some people have autopatrolled is a benefit to new pages patrollers. If the impetus for this proposal were coming from new pages patrollers who were saying, "Hey, too many people have autopatrolled. Some admins are creating new articles that are crappy, and they ought to lose the autopatrolled right," then I could understand the proposal. But I don't see that as being the situation here; most of the new pages patrollers participating here don't seem too enthusiastic about this proposal. --Metropolitan90 (talk) 04:09, 30 March 2013 (UTC)
• Support. I am an admin who had this right before passing RfA. I sympathize with the New Page Patrollers; reducing their workload a bit was one of the reasons I wanted the right (especially since some of the articles I write are on very recondite topics that can't have been much fun to check). My support assumes the creation of an adminbot either to restore the right to all current admins or to restore it to those of us who already had it, as discussed above. However, I believe this is indeed an "in case we need it" change; it would be far better not to have to try to desysop someone in order to get their potentially problematic articles checked (both because it's a tremendous hassle to get someone desysopped, and because we then lose the benefit of their administrative actions afterwards), but there is no implication that it would be frequently needed. Also, unless something radical has happened there since I stopped looking to see whether I dared apply, the bar for autopatrolled is way, way higher than many commenters here seem to realize. When I was unexpectedly given the right, I had noticed the number of articles required was rising faster than I could write them. I saw someone declined who had 80 or 100, I forget which ... so I gave up. Realistically, adminship appeals to a lot more people who spend most of their time doing different things, like making non-admin closures at AfD, dispute resolution, and vandal fighting ... even NPP. So long as autopatrolled is going to require a higher standard than basic knowledge of the notability and reliable sources guidelines and the ability not to commit copyvio (and I think it should, but not as high as it does/did), it's a higher standard than should or can reasonably be required at RfA except as an individual !voter preference. And indeed, while I've seen some requiring GAs, an FA, or maybe a few DYKs, I don't recall anyone ever mentioning autopatrolled as a requirement. I support this as a sensible unbundling, although I hope no need to pull it from an admin ever arises. (And I do expect that bot, to save the NPP folks from having again to read the output of admins like me.) Yngvadottir (talk) 16:34, 30 March 2013 (UTC)

  By the way, I've written a script that will re-add the autopatrolled flag. I don't think it counts as a bot, since I'd be doing it on my own account under supervision, but should this pass, I'll probably run it by BRFA anyway, just to be sure. Writ Keeper (t + c) 15:42, 2 April 2013 (UTC)

• Support After seeing a couple of epic cases, I truly believe that some admins simply need their creations patrolled. — ΛΧΣ²¹ 13:49, 2 April 2013 (UTC)

• Oppose per User:Ruslik0: from the way the proposal is presented, I cannot see any pressing need for this change – i.e. any actual cases in which Sysops have misused their Autopatrolled right. It Is Me Here ^{t / c} 14:45, 2 April 2013 (UTC)

  I agree that there's no pressing need for this, but is a pressing need really the only reason we can use to make a change? Isn't just being a good idea/the right thing to do enough? (Assuming for the sake of argument that you think it is either of those things, of course.) Writ Keeper (t + c) 14:48, 2 April 2013 (UTC)

• Oppose per Jake, Scotty, etc. - a solution in search of a problem. As has been said numerous times here, if we are going to trust someone to speedily delete pages with (let's be honest) almost no oversight, that person should have a solid, foundational understanding of what articles should and shouldn't be. Anyone who should be an admin should know whether or not they should create a given page, so the issue is one of bad admins not good admins who create bad pages. If a sysop creates bad pages s/he should stop being a sysop because s/he clearly doesn't understand policy. The autopatrolled right is usually given out at around 50 pages created, but that can be done on discretion if the user is clearly clueful. Sysops should be the ultimate in cluefulness. ~ Amory (u • t • c) 02:31, 3 April 2013 (UTC)
• Support On some projects, where virtually all administrative tasks are related to the core mission, this bundling makes sense. However, as the largest project, we require significant manpower in various matters only tangentially related to building an encyclopedia. Clearly this dichotomy has been the cause of substantial conflict over time, but in my opinion it boils down to this: We will always have technical or "gnomeish" or what-have-you things that need to be dealt with, and some of these will require administrative access; and we will always, of course, have an encyclopedia to build. I think that if we allow admins to remove autopatrolled from their accounts at their own discretion, we'll take a small but important step toward peaceful coexistence between our content creators and our non-content-creators (/me waves to camera). We'll have a little less "hasn't written an FA" votes at RFA, and maybe, eventually, less of a BIGDEAL complex surrounding admins, which I think is one of the greatest contributors to our somewhat toxiv editing environment. — PinkAmpers&^{(Je vous invite à me parler)} 07:47, 4 April 2013 (UTC)

I believe admins already have the option to remove their own AP status, leastways Writ's tests seems to show that they do. Yunshui 雲‍水 08:22, 4 April 2013 (UTC)

The issue isn't whether they can remove their own, but whether it can be removed from them. Malleus Fatuorum 18:20, 6 April 2013 (UTC)

Yes, but with AP still bundled to adminship, adding or removing it to a sysop account currently has no effect (unless I seriously misunderstand the nature of user rights... in which case you're to blame, Yunshui, seeing as you gave me half of mine). Just like if you were to remove my completely redundant "autochecked" right, my edits would still be marked as reviewed through my autoconfirmed status. My reference to self-removal was because I imagine this will be the most prevalent type of removal. — PinkAmpers&^{(Je vous invite à me parler)} 22:21, 7 April 2013 (UTC)

• Oppose per Orlady. If an administrator cannot be trusted not to create unsuitable articles, then they cannot be trusted to be administrator. KTC (talk) 19:34, 5 April 2013 (UTC)
• Support - I support almost any opportunity to unbundle tools form the admin toolset that will make things more efficient in this place. Long overdue. Kumioko (talk) 20:27, 5 April 2013 (UTC)
• Support - autopatrolled has got nothing to do with admin, and there are many of us who have created very few articles. -- Boing! said Zebedee (talk) 17:46, 6 April 2013 (UTC)
• Kommentar Preference would be for all articles (no matter who created them) get such a cursory once over from another User. Alanscottwalker (talk) 18:07, 6 April 2013 (UTC)

  Why create yet more busy work? Wikipedia has way too much of that already. Why is it that only administrators are trusted, even though many of them clearly ought not to be? Malleus Fatuorum 18:16, 6 April 2013 (UTC)

  Reading does not seem like busy work. Articles are meant to be read by readers, so it's good having other eyes take a look at it, and say, 'ok.' Alanscottwalker (talk) 18:45, 6 April 2013 (UTC)

  Have you ever patrolled new pages and seen how many of them are never read by patrollers? Malleus Fatuorum 19:14, 6 April 2013 (UTC)

  Yes. And assuming you are referring to unpatrolled backlog, and not what other patrollers do or not do, yes. Alanscottwalker (talk) 21:49, 6 April 2013 (UTC)

  We don't have enough patrollers to look at every new article. Hence we have the Autopatrolled right for those who create lots of articles. If we abolished the Autopatroller right and said that all new articles should be checked, then a lot more bad ones would slip through unchecked even than happens today. We would probably have even more incorrect deletion tags than we do now as the Autopatrolled flag does keep a lot of our patrollers away from the regulars. ϢereSpielChequers 19:39, 6 April 2013 (UTC)

  We don't have enough, allot of things. 'We would probably . . .' is a tad unconvincing. But fine, the autopatrolled right does not keep patrollers away and it does not prevent bad articles from slipping through. Not much of an endorsement for it, though. Alanscottwalker (talk) 19:48, 6 April 2013 (UTC)

  New page patrol is a flawed system and has been a problem area for us for years. But having prolific article creators whitelisted is one of the most sensible bits of it. Whitelisting at Newpage patrol works in a similar way to Huggle, patrollers are diverted away from the articles that are unlikely to merit deletion and towards the ones that are more likely to be problematic. We know that we don't have enough patrollers to check all new articles so even with the current system some complete rubbish will get through. But without the Autopatroller system more bad pages will get through and we will probably get more tagging errors. This particular debate is about removing Autopatroller from a number of people who don't really qualify for it. the vast majority of articles that are currently Autopatrolled would continue that way. If you really want to ditch the whole Autopatroller system then file a separate RFC for that, but unless you make a very good case for having extra attack pages and hoax articles in Mainspace I would predict snow.... ϢereSpielChequers 20:10, 6 April 2013 (UTC)

  I did not propose ditch the whole thing. But it does not follow that because there are more fine articles in the que, more bad articles would get through, the bad articles would be judged by comparison with more fine articles. Alanscottwalker (talk) 20:15, 6 April 2013 (UTC)

  Unless you find extra patrollers to patrol more articles at Special Newpages, then yes it does follow that if you put all the ones that are currently Autopatrolled back in the queue the number of bad articles that get through unchecked will increase. Remember we usually don't have enough parollers to check all the unpatrolled ones, so logically if you create extra work for them there will be more bad articles getting through unobserved. ϢereSpielChequers 20:39, 6 April 2013 (UTC)

  Well, it would be relatively simple to reshuffle the que re new users, who have never been patrolled, users who have been patrolled less the x times, and users that have been patrolled more than x-times, if it is that large of an additional burden. How many more a month? Alanscottwalker (talk) 20:48, 6 April 2013 (UTC)

  I don't know how many extra articles a month, but unlike new articles by newish editors it isn't predictable as some long established editors will go on sprees and add articles for every village in an area. More importantly as we don't have the volunteers to patrol all unpatrolled articles if we want to patrol thousands more articles then we would have to accept that a load more vandalism and spam would get through. Sorting things by number of articles created rather than by recency would be a problem as some editors take longer than others to get to the point where their articles don't need checking. There is also the problem that we prioritise deleting attack pages, and though most attack pages will be from people who have never contributed an article that has stuck, there are exceptions. So a system that put the complete newbies first would sometimes see a delay before attack pages went, and of course it would be a less effective spam filter. Using the Autopatroller flag rather than a simple metric re number of articles created allows for the fact that some editors grasp what sort of new articles we want quite quickly, and others take much longer. ϢereSpielChequers 23:22, 6 April 2013 (UTC)

  If you don't know, how is it thousands? If someone creates attack pages or spam pages, they should be at the front of the que, if they still have article creation rights at all. Such as now one can sort for blocked users. If someone creates 25-50 perfectly fine articles, they will go rogue, on the 51st?

• Oppose The proposal is practically useless and therefore should be rejected as practically useless. Alanscottwalker (talk) 00:21, 7 April 2013 (UTC)

  I know that there are thousands of new articles created every day, that there are thousands of editors with the Autopatrolled right and that between them these editors create many thousands of new articles per year. As I explained the number of new articles created by Autopatrolled editors per day is a highly variable as some will produce whole batches of similar articles. As the number of articles by Autopatrolled editors will vary, and the number of people active at newpage patrol also fluctuates so the number of articles that under your proposal would go into mainspace without any patroller looking at them would vary day by day. On some days, days where they currently reduce the backlog, the patrollers might even be able to check everything that comes in. But with what we know about the New page patrol system it is reasonable to assume that if we follow your suggestion and scrap Autopatroller entirely, then unless you find a way to recruit lots more patrollers there will be many thousands more completely unchecked articles slipping through to mainspace.. ϢereSpielChequers 17:15, 7 April 2013 (UTC)

  Just as I noted, you have convinced that the proposal to remove autopatrol rights is practically useless or harmful in its effect. Alanscottwalker (talk) 17:24, 7 April 2013 (UTC)

• Neutral. I don't think we should be giving people admin tools (particularly delete) if they cannot be trusted to create pages within policy. There again, I don't see any need for bundling the tool with the admin package. If this does pass then it would be courteous to notify all admins that the right has been removed, so that those of us who do create articles can apply for it. Espresso Addict (talk) 15:59, 9 April 2013 (UTC)

  If it passes, I'll be going through and regranting the permission to all current admins myself; I've already worked out a script for it. I can probably put in a talk page notification, too. Writ Keeper ⚇♔ 16:08, 9 April 2013 (UTC)

• Oppose per others before me. Can't see what this would achieve - there is something seriously wrong if someone given the power to speedy delete articles, decide the result of PRODs/AFDs, and other such privileges can't be trusted to create appropriate articles. This has the potential to increase backlogs and waste editor's time with very few real upsides. CT Cooper · talk 13:23, 12 April 2013 (UTC)

• Oppose per BDD, Scottywong, et al; although I'd consider it if the bit about removing it from admins is dropped. IOW, it remains something admins get unless community consensus is to remove it - not unless one admin removes it; as Malleus puts it "Unbundle autopatrolled from admin rights package", not "Remove autopatrolled from admins". Unfortunately, as now proposed, it is the latter as well as the former. This will cause more problems than the theoretical rare problem it might conceivably solve. One puppy's opinion. KillerChihuahua 17:34, 12 April 2013 (UTC)

• Oppose They who cannot be trusted not to create articles which require speedy deletion should not be trusted as admins. I doubt that there are any persistent gibberish or attack page creators among the admin corps; if there are, notify arbcom pronto. DavidLeighEllis (talk) 03:17, 15 April 2013 (UTC)
• Kommentar: There's a common theme that the only purpose of autopatrolled is to avoid CSD tagging (and by extension, the only point of New Page Patrolling is CSD tagging). A) That's not really true; there are lots of other tags in the NPP interface than CSD tags. But whatever. B) If the only purpose of autopatrolled is to avoid CSD tagging, then why is the bar for granting the autopatrolled to non-admins so high? WP:AUTOPATROLLED says: " A suggested standard is the prior creation of 50 valid articles, not including redirects or disambiguation pages." (emphasis original) Is 50 articles really necessary to prove that one won't create a CSDable page? If NPP really is just CSD tagging, then we definitely need to revise the expectations for autopatrolled downward. Writ Keeper ⚇♔ 15:19, 15 April 2013 (UTC)

  Admins have a natural propensity to try and keep all user rights to themselves and to deny them to non-administrators, so of course it has to be difficult for a non-admin to gain any user right. Simple really. Malleus Fatuorum 16:08, 15 April 2013 (UTC)

  The standard used to be higher. It was lowered without the sky falling, and it could probably be lowered again. However, there's a certain amount of overhead involved in reviewing and granting the right, so that has to be balanced against the NPPers' time saving. If you're only likely to create one new article a month, and if it takes only ten minutes to review your contributions to see whether you qualify, then we've actually lost time overall: six minutes (or less) saved for NPPers this year versus ten minutes to decide whether to save those six minutes. Additionally, the fact that NPPers can add more tags doesn't mean that spamming tags into new articles is either a good idea (some NPPers' frequent creation of edit conflicts over trivial tags is one of the most common complaints from frustrated new users) or a necessary component. WhatamIdoing (talk) 16:17, 15 April 2013 (UTC)

  I didn't mean that things like the notability tags are necessary, just that it is a thing aside from CSD that NPP does; CSD is not NPP's only function. Certainly I personally don't use the non-deletion tags much through NPP. Strictly speaking, though, I do put things up for PROD and AfD not infrequently, so that's an example of non-CSD NPP activity.

  I see where you're coming from with the overhead argument, but I don't really buy it. It seems to me that the point of autopatrolled, as has been mentioned several times by people on both sides here, is trust, not pure efficiency. I think that, if we trust someone to make good articles, and they ask for the flag, we should give it to them regardless of their rate of article creation. I know the whole theory that rights aren't hats to be collected, but this right in particular is one that represents the community's trust in a user, since it's not as who should say a tool to be used. (Not to mention that the right never expires, so in your example, it's not six minutes saved, but as many minutes as articles the user will ever create throughout their entire Wikipedia career; also, I myself generally spend more than one minute on patrolling a page.)

  All that said, in light of this, I'm going to boldly revise the number down from 50 to 5. If 5 articles is enough for a user to pass the content-creation side of RfA (and I passed my RfA with exactly two articles to my name, so...), then it should be enough for a user to get autopatrolled. BRD as necessary, of course; since it's worded as a suggestion, not a hard and fast rule, I don't feel that it's necessary to go through another RfC beforehand to bring the suggestion in line with what appears to be people's expectations, but I am, of course, open to being reverted and discussing if people disagree. Writ Keeper ⚇♔ 16:37, 15 April 2013 (UTC)

• Oppose Being an administrator doesn't confer some kind of capability to develop decent articles. Point given. However, being capable of developing a halfway decent speedy-deletion avoidable, non WP:BLP infringing, third party sourced, neutral article should be a prerequisite to an RFA. I can only think of one RFA where content contributions were completely ignored because the user needed to tools to do template maintenance. I'm also not going to support a proposal that was suggested during a user's anti-administrator axe grinding whether or not another user started the proposal in good faith.--v/r - TP 19:00, 15 April 2013 (UTC)

  That seems to be a rather typical view among administrators: "I don't like you and I therefore intend to oppose you every chance I get, no matter what you say." Shame really. Malleus Fatuorum 19:06, 15 April 2013 (UTC)

  Yes, I do believe that was exactly the attitude you had on the AN thread that led us here.--v/r - TP 19:27, 15 April 2013 (UTC)

• I think you need to wake up kiddo. When Writ Keeper asked me about this proposal I advised against it, as I was absolutely certain that clowns such as yourself would oppose it for whatever reason first came into their heads. Had I thought otherwise I would have proposed it myself. Malleus Fatuorum 19:32, 15 April 2013 (UTC)

• @that last sentence: really, TParis? Really? You know, all these insinuations that I'm merely a puppet dancing on Malleus's strings--wittingly or otherwise--kinda piss me off, and I find it very difficult to read things like that any other way, even if that's somehow not what you meant. I am not a number, I am a free man; I don't run on clockwork. Writ Keeper ⚇♔ 19:08, 15 April 2013 (UTC)

  (edit conflict) I didn't even hint at that idea and I don't know where you got it (having not read all the previous comments I assume someone else said it) but I very clearly said you did it in good faith (not even a subsequent edit suggesting I changed the wording after the fact). The point I'm making is that the idea came up by someone else who was critical of the idea for criteria for removing the tool from non-sysops that I had put forward in the original AN thread. The idea that you, or even that your a Malleus puppet which has never occurred to me (nor have I seen it elsewhere, so it's not such a wide-spread opinion as you seem to think), is not even part of the equation. I'd think you'd know I had a higher opinion of you than that. And although I dislike the guy, I have a higher opinion of Malleus than to think he needs puppets to do whatever it is he wants.--v/r - TP 19:27, 15 April 2013 (UTC)

  Then why did you bring it up? What possible other purpose could that statement serve? At its absolute most generous, assuming you didn't intend anything about my motivations, that sentence says to me: "Well, I'm not going to give your proposal full consideration, because it happens to be shared by someone I don't approve of." I don't think that's cool. I think that's a terrible attitude. So terrible that I doubt it's the opinion you actually hold. But I can't see any better way to interpret it. I saw that you said "in good faith", and I did appreciate that, but all that little disclaimer says to me is "he was unwittingly duped, rather than being a willing accomplice", and--surprise--I still take offense at that suggestion.

  Never turn away an idea solely because of its source. Ever. That is an ugly, ugly road to go down, one that leads to utter stagnation and decay. If you disagree with the proposal on its own merits, then that's completely fine. God knows you won't be alone there, and nor should you be; reasoned opposition is the fundamental building block of dispute resolution, and by extension, civilization. But let your opposition stand on its own merits in turn; don't bring ugly partisan politics into it.

  As an aside, I don't share Malleus's disdain for either people associated with the military or for administrators; in either case, I would then be hating myself. But it would be a lie to say that I don't see how he got there, or that either is unfounded. Writ Keeper ⚇♔ 19:56, 15 April 2013 (UTC)

  I have no idea if or why Malleus does or would have disdain for the military and it doesn't matter. I don't put it on my userpage as some kind of status symbol, I put it there because it's who I am. He's welcome to dislike me just as I enjoy the freedom to dislike him. Anyway, I'm not turning the idea away because of it's source, my first several sentences spelled out the reason. But the source isn't completely abstract from the idea either. You should read my last sentence as "Despite that I think Writ is a smart and competent guy who I have respect for and he genuinely likes the idea on it's merits, I feel like the original idea only came up from another user because of a distaste for administrators rather than actual concern." But if that still doesn't satisfy you, then I'll offer to buy you a drink if we ever meet at a Wikimania or something.--v/r - TP 20:02, 15 April 2013 (UTC)

  Okay. I might take you up on that drink offer, but thanks for explaining. Writ Keeper ⚇♔ 20:13, 15 April 2013 (UTC)

  Be assured that the dislike is mutual Staff Sergeant. Malleus Fatuorum 19:43, 15 April 2013 (UTC)

  Good? I don't know how to respond to that.--v/r - TP 19:47, 15 April 2013 (UTC)

  TParis is an annointed member of the body, so any fault must clearly lie with you, not him. Malleus Fatuorum 19:18, 15 April 2013 (UTC)

  Of course, I tool the anti-Malleus sysop oath upon condition of death.--v/r - TP 19:27, 15 April 2013 (UTC)

  How do you "tool" an oath? Is that an American thing? Malleus Fatuorum 19:39, 15 April 2013 (UTC)

  The same way you has a thought. I just didn't think the edit conflicts were worth the minor change.--v/r - TP 19:47, 15 April 2013 (UTC)

  @TParis: and please look above, even some (dare I say: uninvolved) admins support the proposal. I will of course defend your right to say what you want, but I can understand Writ Keeper here. Lectonar (talk) 19:23, 15 April 2013 (UTC)

  I'm not required to share their views.--v/r - TP 19:27, 15 April 2013 (UTC)

  (ECx2)I agree with Malleus and Lectonar, And for the record, neither Malleus nor Writ keeper are alone in their feelings that there is a growing rift between admins and editors here in Wikipedia. My own own problems with many of the admins and their attitudes and actions are often lamented facts of Wiki lore and we are only three voices. There are a lot more who prefer to stay quite and not comment because they fear being blocked or banned. Whether this RFC has merit is beside the point. Many admins, most even, will fight tooth and nail to ensure that the power they have doesn't get limited by others. The whole we can't trust you so you can't have the tools is utter nonsense and only proves that we need to debundle the toolset completely. Its even more insulting when admins are allowed to do and act however they want once they get the tools without any fear of the tools being removed. Virtually the only way for an admin to be demoted is for a Major arbcom case or if they just stop editing. Many admins don't even create articles and many of those that do aren't very good at it. This is a very valid RFC and if it means that some admins actions need to be reviewed then the community needs to review if they should be an admin. Maybe this will help facilitate getting rid of some of the dead weight and shabby admins. Kumioko (talk) 19:25, 15 April 2013 (UTC)

• (edit conflict)*3 Oppose Very confused about what benefit this is supposed to bring to the community. If it's the fact that a editor hasn't shown consistently good choices in creating content/articles, they're not going to pass RfAdmin plain and simple. It's been my understanding that we want Admins to be well rounded editors that have worked in multiple different portions of the encyclopedia regardless of their desire to work in a specific area. Autopatrolled is already attainable through RfPerm for regular editors who frequently create articles that know what they are doing and consistently follow the best practices (Rules/Guidelines/MoS/etc.) so I'm slightly confused as to what benefit we get out of unbundling a permission that makes sense to still be bundled (and would expect that the user would already have prior to RfAdmin). Hasteur (talk) 19:27, 15 April 2013 (UTC)

  That's clearly untrue, as content creation is widely disregarded as a criterion at RfA. Malleus Fatuorum 20:00, 15 April 2013 (UTC)

  I don't believe that the community chooses admins who have a long history of creating inappropriate content, e.g., CSD-able articles. Content creation is not disregarded: we reject candidates who create policy-violating content. Content creation is only disregarded when the content is neutral, good, or nonexistent. WhatamIdoing (talk) 20:12, 15 April 2013 (UTC)

  Certainly true and I really don't think anyone debates that. However there have been a number of exceptions over the years wouldn't you agree? All this allows is that the right be separated to allow that it can be removed if necessary. It certainly much easier to remove that, than to get a sysops tools taken away. Kumioko (talk) 23:56, 15 April 2013 (UTC)

• Support. I agree with Orlady and others that admins should know how to write a decent article, but there is nothing inherent in the bit (or most of the bit's parts) or the nomination process that guarantees that they can. Also, I think it's no big deal, and unbundling makes the status of sysop a bit more unassailable: appearances matter. Drmies (talk) 19:49, 15 April 2013 (UTC)

Idea?

Instead of unbundling the right, what if there were an option sysops could check/uncheck when starting a page that would leave that page unpatrolled, somewhat akin the redirect when pagemoving option? That would leave it up to the individual admin, which may seem counter-intuitive, but I think serves everyone's concerns:

• Admins who would have or should have had autopatrolled outright will not add to the NPP backlog (true of this, the proposal, or no change).
• Good admins with good intent but not-so-strong creation history can have articles patrolled by someone else if they ever create something.
• Admins misusing/abusing the right, which is the concern the initial proposal sought to fix, will be able to be held far more accountable; it should be a lot easier to prove poor understanding of policies or even malintent.

What say you all? ~ Amory (u • t • c) 22:36, 6 April 2013 (UTC)

It certainly doesn't address my concern. Malleus Fatuorum 22:45, 6 April 2013 (UTC)

Admins are already able to create alt accounts and use those when we create articles. But that doesn't really address the issue of admins getting this right via RFA despite RFA rarely if ever paying attention to whether the editor is ready for the Autopatroller flag. ϢereSpielChequers 23:04, 6 April 2013 (UTC)

A much simpler way of accomplishing this is for any admin who wishes extra eyes to post a note asking for someone else to look it over. They'll likely get much more out of that request than out of the NPPers. Look at the rate that NPPers process articles. Someone's listed at the moment as having done 28 articles in the last 11 minutes. They're looking for CSD candidates (the main job of NPP). They are not giving a lot of attention to article development. This is reality, and this is what we want from the NPPers. If you want a major review rather than a quick "is this CSDable?", then you want WP:Peer review. WhatamIdoing (talk) 00:19, 7 April 2013 (UTC)

+1. Another thing to note is that while there are some articles that never get patrolled (as the option expires after 30 days), in reality if a page isn't CSD'd within 6 hours at most (on a slow day), it almost definitely doesn't meet an applicable criterion. I'll confess that sometimes I'll find a decently written article that makes a half-ass claim to notability but is CSD-ineligible, and simply leave it for someone else (often an AWB user) to tag and clean up. — PinkAmpers&^{(Je vous invite à me parler)} 22:29, 7 April 2013 (UTC)

The wrong question

Surely the question we should be asking is whether anyone who can't create an article that meets basic requirements should be trusted with adminship? I would have thought that the answer to that should be obvious, but many of the people in the oppose camp above are the same ones who jump on anyone at requests for adminship who opposes on the basis that the candidate has little content writing experience, so it seems that it's not so obvious to everyone, and there are certainly a few admins promoted in the last year or two who don't have such experience. Decent content creation ability should be a sine qua non of adminship. Phil Bridger (talk) 19:55, 15 April 2013 (UTC)

But it's not, hence the proposal. I'd have thought that many more administrators would have voted in favour frankly, because the only other way they could could have their autopatrolled user right revoked would be a desysop. Their choice of course. Malleus Fatuorum 20:04, 15 April 2013 (UTC)

As I alluded in a comment above, I don't think it's so much whether admins should or shouldn't have basic article creation ability. Rather, it's more a question of: "how much content creation ability does the "autopatrolled" right actually require?" Many people seem to be saying that it requires no more than a very basic level, and yet the suggested bar for non-admins to receive the right, at the time I made this proposal, was 50 articles created. I think that requirement suggests a significantly more advanced level of experience/skill with article creation, and that disparity is much of the problem. (The rest of the problem, and the major bit as far as I'm concerned, is the dissonance of including a right so unrelated to admin work in the admin package, but I can appreciate that that doesn't bother everyone as much as it bothers me.) Now, as I also say above, I've since changed that (suggested) requirement to 5 articles created, to bring it more into line with the minimum amount of content creation that people seem to expect from an admin (though some, like myself, passed RfA with even less than that; I had 2 DYKs as the sum total of my content creation at the time of my RfA). So that relieves a part of the need for this proposal, if it sticks (it didn't). Writ Keeper ⚇♔ 20:08, 15 April 2013 (UTC)

I don't think five articles gives the reviewing admin enough material to work on to be sure that the editor understands relevant policies (particularly towards BLPs). Five impeccably sourced GA-quality articles including bios of controversial living people, sure, but usually we're talking stubs & starts on non-controversial topics. I agree 50 is overkill though -- I've just tried editing the guidelines down to 30; we shall see how long that sticks. Espresso Addict (talk) 21:23, 16 April 2013 (UTC)

I don't feel like reverting you too, so did you read my comment on WK's talkpage? I think there's enough disagreement here that it would be reasonable to start an RfC on the correct threshold for autopatrolled once this is done with, but I think it's safe to say that we're at the D part of BRD. ~ Amory (u • t • c) 21:55, 16 April 2013 (UTC)

Sorry, didn't see that discussion (I did check the guideline's talk page). Some form of centralised discussion would indeed seem appropriate, given the different opinions being offered as to the appropriate threshold. Espresso Addict (talk) 22:55, 16 April 2013 (UTC)

One reason for not wholeheartedly supporting this proposal is that I fear it will result in even less agreement among RfA participants that admins should have a reasonable history of content creation. Espresso Addict (talk) 21:09, 16 April 2013 (UTC)

Proposal: mass deletion of all articles at WP:AfC

Moved to Wikipedia talk:CSD § Proposal: mass deletion of all articles at WP:AfC

 - 64.40.54.241 (talk) 03:13, 9 April 2013 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Proposal: All declined articles at Articles for creation that are over 1 year old—some 90,000 articles—should be mass deleted without further review. 64.40.54.111 (talk) 02:31, 7 April 2013 (UTC) added "declined" per comment below. 64.40.54.202 (talk) 23:35, 7 April 2013 (UTC)

• Oppose. No reason to do so. Diego (talk) 07:51, 7 April 2013 (UTC)
• Aye, what would be the benefit of doing that? If it's just to try to make things tidier, I can say with some amount of certainty the old submissions pile will likely be a mess either way, so the extra effort required and the added complications of the subsequently non-visible content wouldn't really be warranted. -— Isarra ༆ 09:56, 7 April 2013 (UTC)
• Oppose. Why? How are they hurting Wikipedia, you, anybody, or anything else? Kiltpin (talk) 10:35, 7 April 2013 (UTC)
• Oppose. The consensus at Wikipedia talk:CSD#G13: Abandoned Articles for creation submissions is that only the declined submissions should be deleted. -- John of Reading (talk) 10:42, 7 April 2013 (UTC)

  Any submission not declined should be in article space... ~ Amory (u • t • c) 22:42, 7 April 2013 (UTC)

  Not necessarily. The page might never have been submitted. People only review submitted proposals. --Stefan2 (talk) 22:53, 7 April 2013 (UTC)

• Kommentar. Is this a serious proposal? 64.40.54.111 has been on Wikipedia for less than 24 hours. Kiltpin (talk) 12:46, 7 April 2013 (UTC)
  • Not defending the proposal here, and at the risk of sounding condescending... it's an IP address. Contributors' IPs can change frequently, either due to their Internet Service Providers or simply because they've changed locations. An IP with "one edit" could actually be an experienced Wikipedian with thousands of edits who, for whatever reason, prefers to work anonymously. — PinkAmpers&^{(Je vous invite à me parler)} 21:51, 7 April 2013 (UTC)
• Comment: Even the deletion of all declined submissions is a bad idea. It would possibly have been fine if every reviewer had done a competent job, but that isn't always the case. --Hegvald (talk) 13:06, 7 April 2013 (UTC)
• Conditional support for deletion of old AfC topics about only popular culture and other non-academic subjects. Please read the proposal text itself, it speaks of only AfC submissions over one year old. Wer900 • talk 16:28, 7 April 2013 (UTC)
  • Who, exactly, will define what is and is not an "academic subject"?--Fyre2387 ^{(talk • contribs)} 22:54, 7 April 2013 (UTC)
• Oppose-Frankly, I just don't see the payoff. How would such action improve Wikipedia?--Fyre2387 ^{(talk • contribs)} 22:54, 7 April 2013 (UTC)
• How does this proposal differ at all from what is already implemented as CSD G13? Is it that this is to delete articles regardless of current work? Why? Marcus Qwertyus (talk) 00:02, 8 April 2013 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Shouldn't discussions at this village pump be officially closed before being archived?

When I look into the archives of VPR I find many discussions that were archived despite not being officially closed. In some cases it is hard to tell from the archived discussion whether a proposed change was implemented or not. Wouldn't it be better to require that all discussion be closed by an editor before being archived? Even if a change is not being discussed or outright rejected due to WP:SNOW reasons, it could still be officially closed and noted as SNOW close in the closing comment. I can't really see any drawbacks regarding this proposal, so I am bringing it here for assessment by the community. -- Toshio Yamaguchi 08:41, 9 April 2013 (UTC)

If a tree falls in the forest, and no one hears it, does it need to be closed before it is archived? No, seriously. Some discussions merely peter out, or attract little attention at all. If a discussion doesn't attract enough attention to generate the need to close it, there isn't a compelling reason to keep such discussions from being archived. Some discussions don't need to be acted on at all, they can just be left to die on the vine. Formal closure is really only needed in cases where the discussion is extensive enough to establish consensus to act. If we required discussions to be closed before they were archived, we run into the very real problem of leaving pointless discussions around for months or years. Let those just vanish. --Jayron32 22:43, 9 April 2013 (UTC)

The main drawback is that people who could be doing something important would be wasting their time on formally closing discussions. Discussions are formally closed only if necessary. If nobody cares, or if everyone already knows what the agreement is, then it's not necessary. WhatamIdoing (talk) 03:17, 10 April 2013 (UTC)

Well, I guess there are really more important issues than whether a discussion had been officially closed before being archived or not. So lets close this and focus on more important issues. Who wants to waste some of their time and do it? -- Toshio Yamaguchi 21:24, 10 April 2013 (UTC)

Replacing Links to Amazon

(Disclosure: I work for OCLC)

For research was recently reviewing Template:Cite book#URL and noticed this sentence: Do not link to any commercial booksellers such as Amazon.com. However there are quite a few links to Amazon. Using Pywikipedia bot, I wrote a small script that determined that on April 9 2013 Wikipedia has 44,816 total links to Amazon, of which 19,075 are in mainspace. I'm curious as to what the community thinks should be done. One thing that could be done in my opinion, is to write a bot that would rewrite these links to a non-commerical website. It's possible to write a bot - I wrote User:VIAFbot - that would load the Amazon link, search for an ISBN, and then search that ISBN in WorldCat and return replace the Amazon link with a WorldCat link. WorldCat is a non-profit website links tell the user the closest library that has that book, and can link to free full text versions potentially.

Example: Benoit Mandelbrot has link http://www.amazon.com/The-Fractalist-Memoir-Scientific-Maverick/dp/0307377350/ref=sr_1_1?ie=UTF8&qid=1351968124&sr=8-1&keywords=fractalist. Follow that link and see that it has ISBN number 978-0307377357. On the Wikipedia page, replace the Amazon link with http://www.worldcat.org/isbn/978-0307377357.

I'm wondering what people thinking about this idea? Maximilianklein (talk) 22:32, 9 April 2013 (UTC)

I'm not averse to changing Amazon links to WorldCat links, but I am averse to doing this as an automated process. Humans should be able to make human judgement and notice odd exceptions which were unforeseen (I can't think of a valid reason, right now, on the spot, why a mainspace article would need an Amazon link, but that doesn't mean that such situations do not exist at all); bots cannot do this. So, if you wanted to be bold and start weeding out the bad Amazon links and WP:BOLDly replacing them with good WorldCat links, I would never object to doing that necessary work. I'd be leary of assuming that a bot could do this, however, as I trust human judgement in finding edge cases than I do for bots to do the same. --Jayron32 22:40, 9 April 2013 (UTC)

The Amazon Standard Identifier, ASIN, is one of the 18 different document identifiers presently supported by Module:Citation/CS1 for use in citation templates. This has struck me as a little weird, as I think it is the only one associated with a specific commercial company while the other 17 ID systems are industry-wide / non-profit / governmental. As best I can tell, ASIN is used in roughly 1000 citations, so it wouldn't be that big a deal to remove it if people wanted to. Though I wouldn't do it myself without some sort of a consensus. Dragons flight (talk) 23:03, 9 April 2013 (UTC)

As I recall from my attempt to update {{cite video game}}, ASIN is the only identifier for many Japanese game releases. It is also the only identifier for a lot of Kindle books. --  Gadget850 (Ed) ^talk 02:26, 10 April 2013 (UTC)

If it's possible to get both an OCLC number and an ISBN (which won't happen with video games), then I'd be happy to have a bot mindlessly remove the Amazon link. Many of these are added by inexperienced people who just don't know any better. If there is some exceptional circumstance that requires not just those two numbers, but also an ASIN, then a test run of 100 pages/day for a week or so ought to be sufficient to identify it. The only possibility that occurs to me is someone citing content or reviews on the page about a book, rather than the book (e.g., "According to the Amazon page for this book, it has 235 pages and is seven inches tall"). WhatamIdoing (talk) 03:21, 10 April 2013 (UTC)

I think we have one or more articles about authors who have reviewed their own or their rivals books. They may validly have Amazon links. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:36, 10 April 2013 (UTC)

I like this idea This is a very good idea, but I would prefer it to be a user initiated tool rather than a bot. The tool could find a page needing updating, load the edit window with the suggested changes and show a preview to the user. The user could review the change and press the save button. I don't know how difficult it would be to make a tool like that, but I would use it if it were available. 64.40.54.121 (talk) 03:58, 10 April 2013 (UTC)

While I support this in principle, I'd like to see some stats on where these links are. Are they in bare references? Citation templates? External links sections? In running prose? We may need to deal with each type in different ways. We should also exclude the articles Amazon and any associated companies and topics. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:33, 10 April 2013 (UTC)

Oppose If we're just talking about uses in {{cite book}}, I see no need for either link, at least for those books that actually have ISBNs. We already have Special:BookSources to avoid the problems of having one default site to look up books by ISBN. But I know that I for one have cited books that lack both an ISBN and an OCLC number; sometimes the ASIN is the best option. Ntsimp (talk) 14:41, 11 April 2013 (UTC)

Response It seems like there are more nauances then I imagined about what is entirely replaceable. It sounds like a Gadget might be a good fit for making this a semi-automated human-driven task. Would that work? Maximilianklein (talk) 17:27, 12 April 2013 (UTC)

Yes, I believe a WP:Gadget would be very helpful. Thanks. 64.40.54.100 (talk) 09:23, 13 April 2013 (UTC)

suggestion box

Can you add a feature to wikipedia as in newspapers, when you scroll down it gives you a suggestion as a side-box related to what you read? I believe it will be really beneficial.

Hello! The section "See also" and the navigational boxes are meant for that. You can also see the categories of an article. Have fun! --NaBUru38 (talk) 15:54, 11 April 2013 (UTC)

Auto reflist when previewing whilst section editing

Is it possible to automatically display the equivalent results of a {{reflist}} if you are previewing your edits whilst section editing? It is annoying to not see it at all until you hit save, and then realise that you stuffed up the cite template parameters. I know that complicated ref groups and other details might not show properly, but could an auto reflist on preview be implemented as an opt-in? The-Pope (talk) 04:16, 12 April 2013 (UTC)

Good idea. • • • Peter (Southwood) ^(talk): 07:16, 12 April 2013 (UTC)

Template:Bug - Edit preview doesn't let you preview cite.php footnotes --  Gadget850 (Ed) ^talk 10:35, 12 April 2013 (UTC)

Thanks for pointing me to the history, I should have done a better past proposals check. It seemed to get good support back in December 2011 when it was last discussed. To answer the query from that discussion, I would be happy to do a straight {{reflist}} equivalent for the current section only, either automatically or via a check box, as this would solve the problem for most cases of adding new refs. I think if you are adding duplicate refs from other sections via named refs, then you probably should be editing the whole page, not just a section, or the ref was already visible, so it doesn't need checking during preview. The-Pope (talk) 02:00, 13 April 2013 (UTC)

Merging WP:Proposed mergers and WP:ATD-R into Wikipedia:Articles for deletion

I believe it is counter-productive to have three different venues for these discussions. If you believe an article should be deleted, you have to go to WP:AFD. If you believe an article should be merged into another, you have to open a discussion in the destination's talk page and list it at WP:PM. If you believe an article should be replaced with a redirect, the official recommendation is to just do it boldly and then discuss it on the talk page when someone refutes it. Here are my problems with the current system:

1. WP:ATD-R results in the deletion of an article. Although the history still exists and the article's title is still being used as a redirect, the entirety of its content has been removed. A lot of these bold edits end up having to be discussed, because frankly, it's a drastic move. For example, that's why I proposed the deletion of Wikipedia:Articles for deletion/Tons of Funk at AFD, even though after its deletion, it was redirected to another article. Had I done this boldly, the people who voted keep in that AFD would have forced the discussion to happen at the talk page anyway. Thus, my official stance is that all ATD-R does is delay the inevitable discussion from happening.
2. The people who participate at talk page discussions are the ones who either (1) watch the article in question, (2) watch WP:PM, or (3) stumble upon the discussion by happenstance. By contrast, WP:AFD is extremely popular. Users who don't usually edit comic book articles might end up participating in comic book AFDs due to its appearance at AFD's main page. A lot of these merge and redirect discussions just go overlooked, but if these processes were merged into AFD, we would be encouraging the most participation possible. I've participated in many deletion discussions about articles that I would never have crossed by had it not been for AFD. A lot of these discussions ended in "Redirect" and "Merge".
3. When coming across a problematic redirect, our first question is to wonder what we should do with it. Should it be deleted? Renamed? Turned into its own article? Sometimes it just isn't as clear-cut as we would like it to be. Thankfully, that's why we have WP:Redirects for discussion where anyone can propose to discuss a problematic redirect without choosing a "keep, delete, rename" allegiance beforehand. However, our current policies force us to choose a side before opening a discussion when it comes to articles. If you think it should be deleted, go to AFD! If you think it should be merged, use this specific tag! If you want it redirected, just do it, wait for someone to revert and then talk about it on the talk page! But if you want to value the community's input before making a decision, your only hope is to open a section at the talk page and hope that enough people respond. And once that section reaches a consensus, you'll most likely end up doing one of those Deletion or Merge processes afterwards. Frankly, this is just counter-productive. It would be best if we could just open an AFD page where anyone can voice their concerns without outright crying Delete!

Making AFD more like RFD would be a good thing. And that's why I think all these processes should be merged and renamed "Articles for discussion". I know this isn't the first time someone has proposed this, but I think it's time we reopen the conversation. Feedback ^☎ 23:16, 12 April 2013 (UTC)

Have you read the FAQ?

I don't like this page's name. I want to rename it to Articles for discussion or something else.

Please see Wikipedia:Perennial proposals#Rename_AFD. Note that all of the "for discussion" pages handle not only deletion, but also proposed mergers, proposed moves, and other similar processes. AFD is "for deletion" because the volume of discussion has made it necessary to sub-divide the work by the type of change.

I know it's been discussed before. I've read at least 3 different threads where the idea has been proposed. But like I said, I think its time we reopen the conversation. It's just counter-productive for us to keep these tasks separate, and I'm hoping we can form a consensus to overhaul it. Feedback ^☎ 01:47, 13 April 2013 (UTC)

How exactly does your proposal solve the problem (high volume) that necessitated the subdivision in the first place? WhatamIdoing (talk) 01:01, 13 April 2013 (UTC)

I don't see how the proposal to merge the discussions will result in a higher backlog. It will be the same exact "volume" that we have right now. The difference is that instead of having these conversations scattered around Wikipedia, we'd have them all in one place. Frankly, if you think AFD's current backlog is large, imagine all the merge and redirect discussions going on talk pages right now that just aren't being viewed due to the relative unpopularity of said pages. That's the real backlog, and we would be doing a great service by merging them all into AFD. Plus, the less time people use discussing on talk pages means that even more users will participate at AFD. There are only positives here. I don't see the negatives. Feedback ^☎ 01:47, 13 April 2013 (UTC)

I dispute the statement that WP:ATD-R results in the deletion of an article. The important difference between redirection and deletion is that the former can be performed and reverted by any editor, whereas deletion can only be performed or reverted by an admin, so is a much more drastic move than redirection, and as such is an exception to the normal wiki "anyone can edit" process, so requires much more detailed policy around it. Requiring redirection to go through the same process as deletion would simply result in more unnecessary bureaucracy around it, rather than treating it in the same way as any other normal editing process that anyone can revert. Phil Bridger (talk) 18:38, 13 April 2013 (UTC)

That distinction, although important, is irrelevant to the common reader. Whoever read Cornwood Industries yesterday and decides to look it up again today would be dumbfounded when they find that it redirects to Jandek. To the reader, the page is gone. If they want to know why it's gone, they could see that the discussion took place at Wikipedia:Articles for deletion/Corwood Industries and a consensus was achieved to redirect the page. This isn't an extra layer of bureaucracy. This is the proper way to handle the removal of content from the encyclopedia. Sure, someone could still access the page history, but for all intensive purposes, the article that used to be there has been removed from the encyclopedia. That's how it would seem to the common reader and that's who we should have in mind when forming these policies. Feedback ^☎ 04:34, 14 April 2013 (UTC)

• As per WP:Administrators' noticeboard/Requests for closure#Wikipedia namespace in the section, Wikipedia:Village pump (proposals)#Wikipedia "Merge" like WP:RM or WP:AFD, there is a related recent discussion that is awaiting closure.  Unscintillating (talk) 16:07, 14 April 2013 (UTC)

I want to bring you an example. On April 12, I proposed to merge Colossal Connection into The Heenan Family. It's been almost 3 days and no one has yet to comment on the proposal. But after nominating the article for deletion last night, it took just FOUR hours for someone to respond. This is just proof of what I'm trying to get at here. AFD is just more effective than all the other processed because it is extremely popular. We need to take advantage of that so that our merge discussions don't suffer. Feedback ^☎ 20:15, 14 April 2013 (UTC)

Two questions:

1. Why didn't you just boldly merge the pages in the first place?
2. Why do you think that a routine merge proposal ought to get a response in less than three days? WhatamIdoing (talk) 16:20, 15 April 2013 (UTC)

I won't argue that your suggestion isn't sound, but from experience, it just isn't practical. People would revert it and decide to discuss it. Case in point, someone took a non-notable The Funkadactyls article the other day and turned it into a redirect. A rookie editor disagreed, started an edit war, then began a discussion at Talk:The Funkadactyls and the discussion then ended up going to AFD anyway. This is what we're dealing with on Wikipedia. And this is just an example of the many problems this proposal would fix. Feedback ^☎ 20:37, 15 April 2013 (UTC)

That's not been my experience, but perhaps I've done more of it than you.

Also, if you wanted outside feedback, rather than comments from the people already at those articles, why didn't you follow the directions at Wikipedia:Proposed mergers#Requests for assistance and feedback? WhatamIdoing (talk) 04:53, 16 April 2013 (UTC)

Not in your experience? Well, good for you then. I already linked you to an example where making such a decision boldly forced everyone to jump through hoops to get something done. This happens and it happens a lot. Whether it's happened "in your experience" is irrelevant. And as for PM/Requests, I could have also gone to RFC, or FSR. But there are just more hoops! You are suggesting that I go through the trouble of asking people to participate when AFD automatically gets enough followers to begin with. The aformentioned merge discussion continues to have 0 replies while the AFD has 4. It's evident that the practical thing to do is to have these discussions at AFD instead. Feedback ^☎ 15:45, 16 April 2013 (UTC)

I'm asking you to go through the same number of hoops. Remember that step when you listed the AFD at the AFD page? I'm asking you instead to list the proposed merge at the proposed merge page instead. AFD doesn't "automatically get enough followers" for people to notice an unlisted AFD, just like proposed merges don't automatically get enough followers for people to notice an unlisted PM. WhatamIdoing (talk) 21:00, 16 April 2013 (UTC)

• Strong support: It is often difficult to get reasonable discussion from neutral observers for any of these discussions. Ryan Vesey 16:27, 15 April 2013 (UTC)

"You have new messages" alert for not registered visitors to expire after 30 days

Clarification -- this proposal is solely to hide the "You have new messages bar" from anonymous editors after 30 days.

Many readers are receving annoying alerts linking to messages about being blocked or asking to stop trolling, so that would improve the experience. The discussion page doesn't need to be changed. Should be aplied for all language vesions of Wikipedia.--88.6.170.79 (talk) 00:11, 13 April 2013 (UTC)

That's a great idea. It should probably expire after only a day or two because we have no way of knowing if the IP belongs to a public machine. Rklawton (talk) 00:17, 13 April 2013 (UTC)

I like this suggestion as well; I'd go with the thirty days, though, if only to make sure that the mythical '29-days-later-troll-who-poor-baby-didn't-see-the-warnings' doesn't come a-knockin'. —Theopolisme (talk) 01:10, 13 April 2013 (UTC)

Would like to add the only contributions 88.6.170.79 has made recently involve only personal attacks;

• "You are a fucking bitch! "
• "fuck you bitch!"

Additionaly, the spamming warned about, returned recently from the same range as 88.6.170.79.--Hu12 (talk) 12:43, 13 April 2013 (UTC)

The IP's edits aside, I like the suggestion. Should help to prevent confusing situations like this. Chamal ^T•C 14:02, 13 April 2013 (UTC)

• I'm mostly supportive of this, but I think it would be better if we only did it for dynamic IPs. I understand that many static IPs are in public locations, but I also think it is more obvious to someone who sees the message while in a library to assume someone else made the edit. Ryan Vesey 15:22, 13 April 2013 (UTC)

• But how are we supposed to distinguished static from dynamic addresses? And, even if we can do that, there is a large grey area between static and dynamic. The IP address that I use from home is not guaranteed by my ISP to be static, but for many years stayed the same even if I disconnected my router and reconnected it. A few years ago, when my ISP was acquired by another, this behaviour changed, but as I usually leave my router connected for months at a time is still more-or-less static. Phil Bridger (talk) 19:18, 13 April 2013 (UTC)

• Hmm, you can check by doing a geolocate on an IP, but I actually checked and the IP above is static so only doing it for dynamic IPs wouldn't have solved the problem. Ryan Vesey 19:27, 13 April 2013 (UTC)

• I would oppose any such expiration measures on messages. Our obligation is to ensure our records of discussions are correct and factual.. not to make them go away. Particularly in cases like this where the message in fact worked as designed and identified a returning spammer who has been exploiting Wikipedia since 2006 and has a long history of patterned disruptive behavior.--Hu12 (talk) 12:50, 14 April 2013 (UTC)

• How is a message seen by only one IP address a record of discussion? —Theopolisme (talk) 13:03, 14 April 2013 (UTC)

• So, the proposal is to only remove the message bar? If so, then i'm not opposed.--Hu12 (talk) 14:59, 14 April 2013 (UTC)

• Yep. Clarified above. —Theopolisme (talk) 15:22, 14 April 2013 (UTC)

• I support this as a very positive idea. A number of times over the years I've been here I've seen anonymous newcomers confused and even upset by messages that were clearly not meant for them, and it can have a bad effect on our efforts to attract new editors. I don't think the dynamic/static distinction is worth bothering about - if the person a message is aimed at has not read it after 30 days, they're pretty much never going to. As a general point, I think anything that helps ease things for anonymous newcomers is good - I've seen far too much prejudice against IP editors (going as far as what I would call bullying, even from some admins). -- Boing! said Zebedee (talk) 13:13, 14 April 2013 (UTC)

Support. Stale messages serve only to cause confusion.—Kww(talk) 15:21, 14 April 2013 (UTC)

• Strong support: I did not know that IP addresses can change over time, and I really got into panic when I saw this message for the first time (it was not done by me but blamed on me!). Thus, I fear to warn IPs even for blatant vandalism unless I spot it very quickly (expecting that the same IP would get the message) or the IP has done similar edits over time (enough to prove that it won't change that quickly).···Vanischenu^「m/_Talk」 21:33, 14 April 2013 (UTC)
• support great idea ·Add§hore· ^{Talk To Me!} 22:18, 14 April 2013 (UTC)
• Support Mostly per Boing! said Zebedee. Crazynas ^t 00:40, 15 April 2013 (UTC)
• I was under the impression that the "new messages" bar only lasted for seven days, after which time it would just disappear if not clicked. Maybe I am just living in the past, or perhaps I made this up entirely? — This, that and the other (talk) 11:53, 15 April 2013 (UTC)
• Support - I almost suggested the same. Marcus Qwertyus (talk) 11:56, 15 April 2013 (UTC)
• Support Wouldn't it be sensible to choose an even shorter period, say 14 days? Or even one or two days, as mentioned above? Lectonar (talk) 12:00, 15 April 2013 (UTC)
  • Depends, if an IP is blocked for, e.g. 30 days, the message should be visible for that time in my understanding... mabdul 12:29, 15 April 2013 (UTC)
    • Apart from the block message which should be there, if he tries to edit, he will see this litte pinkish box telling about the block, so I still would opt for a shorter period. Lectonar (talk) 12:32, 15 April 2013 (UTC)
• Support. I also like the 30 day period, since it makes it harder for a later-returning vandal (or, worse yet, a well-meaning intermittent editor making careless mistakes, who has not been blocked) to remain unaware that a notice had been provided. I would note, also, that an expiration of the notice after thirty days is an improvement over the current situation, wherein such notices expire after forever. bd2412 T 12:37, 15 April 2013 (UTC)
• Support - sounds great!. —→Davey2010→Talk to me!→ 14:46, 15 April 2013 (UTC)
• Great idea. ~ Amory (u • t • c) 16:49, 15 April 2013 (UTC)
• Support -- it would prevent scaring away innocent readers. --NaBUru38 (talk) 19:31, 16 April 2013 (UTC)

Proposed mergers

First off, I'm not sure what's going on with the protocol for this but at the moment it's unclear and seemingly under discussion. Whilst it's up in the air, I'm making some proposals here.

• Girls (Sugababes song) --> Here Come the Girls (song); the sampling of Here Come the Girls is extravagant enough that the only new content is three verses. I have no idea why they're separate articles.
• Sunmachine (song) --> The Sun Machine; effectively the same song, only Sunmachine samples vocals while The Sun Machine's are sung by someone else.--Launchballer 18:16, 13 April 2013 (UTC)

Girls

Sunmachine

• As of now you should still go through the steps in "http://en.wikipedia.org/wiki/Wikipedia:Merging#Proposing_a_merger", if you want to make such a proposal. Alanscottwalker (talk) 19:44, 13 April 2013 (UTC)

Add a population database by country to wikidata

Hi, noticed yesterday that World Gazetteer, a highly valuable population resource website by country has announced its closure in July. I feel it would be very important to try to salvage the data and process it into wikidata before the website is shutdown and we can continue to build it and eventually try to provide population data for most settlements in the world which is there for every wikipedia to use at their fingertips. Please comment at my proposal here if you see potential in this.♦ Dr. ☠ Blofeld 10:06, 14 April 2013 (UTC)

Regarding Wikipedia Home Page

Dear Sir/Ma’am

We know about Wikipedia is hosted by the Wikimedia Foundation, a non-profit organization that also hosts a range of other projects (likes Wikibooks, Wikinews, Wikiquote, Wikidata etc.)

Now-a-days or everyday even every time technology has been changing. So, we have to change according to their path. I want to say about the home page, there should be some changes like

All tools should come under "Wikitools" In Wikitools:- Main page (Wikihome), Help, Editing (Wikiupdate), Toolbox (f_upload, pages, link, info). Similarly,

Wikilanguages: - contains all the languages. (Wikiglobe)

Wikinew: - contains innovation, research, features, May I help you (Help Portal). Note: - Wikinew is different from Wikinews.

I do not want to say that you have to accept these things but there should be change.

Parivartan sansar ka Niyam hai! (source :- Gita Saar (Bhagavad Gita)).

Thanking You

Regards Rupesh Kumar Gupta INDIA — Preceding unsigned comment added by Rupes2012 (talk • contribs) 07:38, 15 April 2013 (UTC)

Search results vs language

Currently: Whenever one searches in Wikipedia, only results in the current language are shown.

Proposed change: when searching, the hits in other languages are also shown. So, when searching in on de.wikipedia.org, the search results for German-language sites are shown on top, followed by high-ranking articles in other languages. This helps people that understand/read multiple languages, as they do not need to first specify the language in which the search term is entered: if the search term is specific to a language other than the current one, the wanted results still show up.

That's a lot of extra CPU time. Why not allow the user to select search results languages in their preferences page and just return those? Rklawton (talk) 15:03, 16 April 2013 (UTC)

Rescue the toolserver

Hopefully some WMF staff will read this. Some egoism on WMFs part wouldn't hurt here. -- Toshio Yamaguchi 16:58, 16 April 2013 (UTC)

I have no idea if it's doable or not (or, if not, why not) since that's way out of my area, but I have alerted some of the operations engineering team to the suggestion. --Maggie Dennis (WMF) (talk) 17:46, 16 April 2013 (UTC)

That thread is from six months ago. --MZMcBride (talk) 21:04, 16 April 2013 (UTC)

Mmh, well I admit I didn't notice that. Does that mean those servers have already been given somewhere else? If not, then I think using them to keep the toolserver alive would definitely benefit a number of projects/WikiProjects/editor groups. -- Toshio Yamaguchi 21:38, 16 April 2013 (UTC)

Ways to prevent new users from submitting pages with no references at the Afc

Dear technical folks:

We Afc reviewers waste a lot of time declining articles that have no references at all. Several of us have been discussing ways to discourage users from submitting such articles. I made up a proposal for an intermediate step in the submission process in which users would be warned and asked to confirm that their articles had sources. I posted it at User:Anne Delong/AfcBox and requested input from other reviewers at User talk:Anne Delong/AfcBox so that we could agree on a proposal to bring to those who implement these types of things.

Another editor, Techncal 13 has made a counter proposal that a bot be created to actively check the pages for references and abort the submission process if there aren't any. His ideas are also on the talk page above.

I would appreciate a technical assessment from someone who is familiar with the technical ins and outs of Wikipedia about the practicality of both ideas. Each proposal seems to have its own strengths and weaknesses. Or, perhaps neither is practical and we should continue manually declining the articles (sigh). —Anne Delong (talk) 20:52, 16 April 2013 (UTC)

I think the least confusing thing for the editors submitting them would be if they were allowed to submit them normally, but a bot would automatically decline articles that don't have references. It could then leave them a message telling them the reason for the decline and giving them advice on how to add references. Ryan Vesey 20:54, 16 April 2013 (UTC)

Do you mind if I copy your reply to the talk page above so that it is in context?—Anne Delong (talk) 21:03, 16 April 2013 (UTC)

How will the bot know if there are references? The presence or absence of <ref> tags is not definitive, and a lot of new users don't use them/can't figure them out. Cell-free fetal DNA is a new article with 63 inline citations, but zero ref tags. WhatamIdoing (talk) 21:07, 16 April 2013 (UTC)

I'm sorry, I messed up my message. Could you please check out the proposal first at User:Anne Delong/AfcBox and then add to the discussion at User talk:Anne Delong/AfcBox, because some of these ideas are already being discussed there? Thanks. —Anne Delong (talk) 21:16, 16 April 2013 (UTC)

Adding contribution pages to watchlists

I'm a relatively new user, so I'm not sure what kind of response this will get. I would appreciate comment on this proposal, and will not be offended if it is turned down, even if it happens within minutes.

My proposal is to allow users to add Special:Contributions subpages to their watchlists. This would allow users to track the edits of known vandals and disruptive editors so that their edits could be reverted more quickly and effectively. For example, if User A knew that User B had a track record of vandalism and/or trolling, User A could simply add User B's contribution list to their watchlist in order to better revert the user's edits and warn them of their disruptive behavior.

Certain restrictions could be applied to this feature to prevent trolls and vandals from abusing it. For example, users with less than a certain number of edits - for example, 15,000 - could be automatically disallowed from using it in order to prevent wikihounding. Even more restrictively, the feature could be granted to administrators alone.

I appreciate you for taking the time to read this, and would value any input that you'd like to contribute. Thank you! --Mathnerd 101 _{(What I have done)} ^{(What have I done?)} 23:31, 16 April 2013 (UTC)

I like the idea. One way to follow a users contributions is to use Atom. Christian75 (talk) 23:49, 16 April 2013 (UTC)

Thanks! I'll go to the help desk for further info. --Mathnerd 101 _{(What I have done)} ^{(What have I done?)} 00:26, 17 April 2013 (UTC)