Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Rd232 (talk | contribs) at 08:19, 9 May 2013 (→‎Developer's Noticeboard: r). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


« 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

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)[reply]

"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)[reply]
Why not "Other languages"? Tony (talk) 12:14, 26 October 2012 (UTC)[reply]
Funny, in my toolbar it shows as "in other languages". Lectonar (talk) —Preceding undated comment added 12:20, 26 October 2012 (UTC)[reply]
Are you using any custom code that might be overriding the default? —David Levy 12:59, 26 October 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
One of the Wikipedias is written in simple English. —David Levy 12:59, 26 October 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]

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

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)[reply]
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)[reply]

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

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)[reply]

Mass removal of old indefinite rangblocks under controlled conditions

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

The original discussion for this thread can be found at the VP archives. the original proposal was to restrict all rangeblocks to only checkusers because of the many potentially productive users who get caught in them.

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) [reply]

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)[reply]
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)[reply]

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)[reply]

  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

Bumping thread to stop bot from archival TheOriginalSoni (talk) 07:19, 10 April 2013 (UTC) Unarchiving thread for further discussion TheOriginalSoni (talk) 08:42, 17 April 2013 (UTC)[reply]

  • I am not sure I fully understand the details of this proposal, which seems to conflate accounts with IP addresses and ranges, at the same time appearing to recommend renewed indef IP blocks. I would not be in favour of mass-unblocking all the many thousands of open proxies we have range-blocked, which also happen to regularly appear with 'fake' unblock requests, and/or which demonstrably still belong to hosting companies (most of the older range blocks fall into this category and are still nefarious). I would prefer a liberal examination of individual ranges, from a central list say. We can mark which have been reviewed, and unblocked, and it will be easier to track future edits from any unblocked range. -- zzuuzz (talk) 09:59, 17 April 2013 (UTC)[reply]
I think I did mix up IP blocks and rangeblocks. My intention was mainly rangeblocks; but I do support a review of the old IP blocks. TheOriginalSoni (talk) 10:10, 17 April 2013 (UTC)[reply]
  • Support. No IP block should last more than 5 years, rangeblock or not. You simply can't expect it to stay the same in that time. We should start with blocks issued 5 or more years ago, unblocking everything that passes a proxy check. For those that remain open proxies, they should still be reduced to something like 5 years from today's date. -- King of ♥ ♦ ♣ ♠ 10:03, 17 April 2013 (UTC)[reply]
  • Strong support - I think that all IP blocks (range or othewrwise) should be no longer than 2 years except in the case of open proxies (and these should be checked more often than that). This includes CheckUser blocks (to be monitored by CheckUsers) as well as anything else. עוד מישהו Od Mishehu 11:15, 17 April 2013 (UTC)[reply]
  • Support - Most vandals that attack WP from IP addresses quickly lose interest in WP and move onto other things. After a year or so, it should be safe to un-block. Leaving block in place may be prohibiting valuable edits from good-faith IP editors. Of course, exceptions can be made for especially problematic situations. --Noleander (talk) 11:54, 17 April 2013 (UTC)[reply]
  • Mixed feelings I've dealt with range blocks in the past and the problem is that a heck of a lot of spamming/vandalism comes from specific parts of the world, mostly China (and India as well, but to a lesser extent). For instance, on one of my wikis, I was blocking individual IP's who were spamming from China=based IP addresses at the rate of over three per day, for a good portion of a year until I finally got sick of it and blocked all of China (at which point they started using open proxies instead until I finally blocked those too). I worry that opening up those range blocks might cause some chaos as editors who work on antivandalism try to block individual spamming IP addresses while the spammer is merrily hopping around from IP to IP. I remember years ago I had one editor here from India-based IP's merrily chatting away on different talk pages as he reset his IP literally every minute. Those range blocks were put in place for a reason. Assigning "everyone" to watch for trouble from those IP's may mean that "nobody" is watching for trouble from those IP's. Most antivandalism editors don't know how to start a sock puppet investigation. I agree that old blocks should be lifted, but I think a sudden mass lifting of all old range blocks might cause a fair amount of trouble, and exactly how long is "old" is up for debate as well. Banaticus (talk) 17:55, 19 April 2013 (UTC)[reply]
We can get over that issue by making all those editors' edits work something like "Pending Changes" where their edits will be made public only when another editor approves it. All such IP's user pages could have a permanent banner notifying them of the same, and we could have a special category to be monitored for those changes. If any IP in this list shows disruptive behaviour, the rangeblock for that IP is re-added. Additionally, those banners could have one link for vandal-fighters to report them for reban. TheOriginalSoni (talk) 16:09, 20 April 2013 (UTC)[reply]
Pending Changes is unlikely to work for this use case. You can't apply it to all edits by a certain IP or user, and thus to work it would have to be used on a lot of pages, which it's not currently according to the guidelines about where it's appropriate to apply it. Steven Walling • talk 17:35, 30 April 2013 (UTC)[reply]
I do not have a lot of experience in such proposals, and so if anyone thinks that this proposal should be one of those in the watchlist notices, please get it added. Thank you, TheOriginalSoni (talk) 16:09, 20 April 2013 (UTC)[reply]
I've pinged VPT for discussion on how it should be implemented. TheOriginalSoni (talk) 10:04, 7 May 2013 (UTC)[reply]

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)[reply]

Got any 'Barnstars of Good humour' yet? MIVP - (Can I Help?) (Maybe a bit of tea for thought?) 21:56, 22 March 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    I think you mean "RFA has become so difficult". --Floquenbeam (talk) 22:36, 22 March 2013 (UTC)[reply]
    Yes, Yes I do, my bad ^^' MIVP - (Can I Help?) (Maybe a bit of tea for thought?) 23:53, 22 March 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
  • Support. From each according to his ability, to each according to his need. Kiefer.Wolfowitz 23:05, 22 March 2013 (UTC)[reply]
  • 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 deckertalk 23:09, 22 March 2013 (UTC)[reply]
  • 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)[reply]
  • Support. The case seems obvious enough, but will it ever happen? I doubt it. Malleus Fatuorum 23:25, 22 March 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support Anything to design those infallible admins everyone secretly wanted.84.106.26.81 (talk) 00:02, 23 March 2013 (UTC)[reply]
  • 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)[reply]
  • Support This makes a lot of sense.--Amadscientist (talk) 00:14, 23 March 2013 (UTC)[reply]
  • 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)[reply]
    And why would you assume that? Malleus Fatuorum 01:46, 23 March 2013 (UTC)[reply]
    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)[reply]
    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)[reply]
  • Support - I'm all for unbundling the tools. Keilana|Parlez ici 01:52, 23 March 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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 deckertalk 20:21, 23 March 2013 (UTC)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
Indeed. If an admin bot were called for, I could certainly put one together. --j⚛e deckertalk 21:54, 23 March 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • Comment1st para/Oppose2nd 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)[reply]
  • 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)[reply]
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)[reply]
Indeed. Crazynas t 05:03, 24 March 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support this proposal, seems sensible, logical, and rational. — Cirt (talk) 03:26, 25 March 2013 (UTC)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
      • 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)[reply]
        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)[reply]
        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)[reply]
        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)[reply]
        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 [2]). 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)[reply]
        " 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)[reply]
        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)[reply]
        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)[reply]
        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)[reply]
  • 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. Andrew327 15:31, 25 March 2013 (UTC)[reply]
  • 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)[reply]
  • Support, not required for admin work. Lectonar (talk) 16:50, 25 March 2013 (UTC)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    I doubt you thought at all. I bet you hear that a lot. Malleus Fatuorum 23:48, 26 March 2013 (UTC)[reply]
    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)[reply]
    Probably unsurprisingly, I can be added to that list. Writ Keeper (t + c) 01:02, 27 March 2013 (UTC)[reply]
    Me too. Lectonar (talk) 11:42, 27 March 2013 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    Huh? ‑Scottywong| chat _ 05:09, 27 March 2013 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
      • 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)[reply]
        • 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)[reply]
          • 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)[reply]
  • 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)[reply]
  • Support Far too much OWNing of the current package without thinking of other possibilities. Intothatdarkness 18:08, 27 March 2013 (UTC)[reply]
  • 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)[reply]
  • Support - per most support !votes. Mlpearc (powwow) 18:31, 27 March 2013 (UTC)[reply]
  • Oppose. Another solution in search of a problem. Ruslik_Zero 19:25, 27 March 2013 (UTC)[reply]
  • Oppose – Will create extra work with no practical benefit. Graham87 13:26, 28 March 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
  • Support After seeing a couple of epic cases, I truly believe that some admins simply need their creations patrolled. — ΛΧΣ21 13:49, 2 April 2013 (UTC)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Comment 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Comment: 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • @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)[reply]
    (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)[reply]
    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)[reply]
    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)[reply]
    Okay. I might take you up on that drink offer, but thanks for explaining. Writ Keeper ⚇♔ 20:13, 15 April 2013 (UTC)[reply]
    Be assured that the dislike is mutual Staff Sergeant. Malleus Fatuorum 19:43, 15 April 2013 (UTC)[reply]
    Good? I don't know how to respond to that.--v/r - TP 19:47, 15 April 2013 (UTC)[reply]
    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)[reply]
    Of course, I tool the anti-Malleus sysop oath upon condition of death.--v/r - TP 19:27, 15 April 2013 (UTC)[reply]
    How do you "tool" an oath? Is that an American thing? Malleus Fatuorum 19:39, 15 April 2013 (UTC)[reply]
    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)[reply]
    @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)[reply]
    I'm not required to share their views.--v/r - TP 19:27, 15 April 2013 (UTC)[reply]
    (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)[reply]
  • (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)[reply]
    That's clearly untrue, as content creation is widely disregarded as a criterion at RfA. Malleus Fatuorum 20:00, 15 April 2013 (UTC)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • Support. While all admins theoretically should be able to create articles that the NPP folks don't need to worry about, it's not actually a requirement of the RfA process. --SarekOfVulcan (talk) 22:05, 20 April 2013 (UTC)[reply]
  • Comment as one who has written loads of stuff off wiki, and who has proof read loads of other people's stuff, I'm always be happy to have something of mine checked. I'm not against the separation of the autopatrolled right from the admin package (count me in with the voluntary abjurers) but when I get round to filling out my latest article (a rare thing, that for me, and I'm not afraid to say so), and whichever way this goes, I will ask someone I trust to go through it before launching it. It's much easier to find the bloops in someone else's work than in your own. You know what you meant to say, and you tend to read what you meant rather than what you wrote. Peridon (talk) 18:43, 23 April 2013 (UTC)[reply]
  • Support. Unlike Delete and Block, this does not seem logically, inherently integral to adminship. Sure, it should correlate, but patrolling is an ordinary editor's action. --SmokeyJoe (talk) 13:48, 25 April 2013 (UTC)[reply]
  • Oppose I don't see anything that would be solved by this. And per the NPP I can see there actually being issues caused by it. Thus the balance of pros vs cons points me towards an oppose. Admins should already have a firm grasp of what is speedy deleteable since they have the ability to delete speedies. -DJSasso (talk) 14:40, 25 April 2013 (UTC)[reply]
  • Support. Grumble. I don't know what the requirement for auto-patrolled should be, so I would neither issue the flag nor wish to take advantage of it. There are times when I would remove some obvious errors from a new article, but not make an effort to remove all of them, so I wouldn't want the flag. — Arthur Rubin (talk) 23:27, 1 May 2013 (UTC)[reply]
    Autopatrolled has exactly one effect, and it only applies to the creator, not to subsequent editors. So the example you give is completely irrelevant. The one effect is this: Should the article you created (NB: not "edited") be highlighted as something that desperately needs to be checked for probable speedy deletion as a hoax, serious BLP violation, etc, or not? It's actually easier to understand if you look at Special:NewPages: if you create a new page, should it be highlighted in yellow for urgent review, or is it good enough just to have it listed as one of the many new pages? If you never create a new page, then it doesn't matter whether you have the right or not. All the right does is tick the box that makes yours listed as a new page not requiring urgent review. The people who do those reviews would like to believe that admins don't create hoaxes and attack pages. I hope that you are able to confidently say that they needn't concern themselves overly much with any pages you created, and that they could instead focus on non-admins. WhatamIdoing (talk) 05:34, 3 May 2013 (UTC)[reply]
  • Strong Oppose: User:WhatamIdoing made a huge point here and almost everyone seems to have ignored it. I read the policy on marking new pages as patrolled and realised that new pages that are not speedily deletable indeed should be marked as "patrolled". As long as an article has appropriate tags for them, other issues (unless they're really serious) do not matter when it comes to marking new articles as "patrolled". Now I'm more than sure that an admin can not be expected to create pages with issues without appropriately tagging the pages for them. It's as simple as that. I don't know why some admins are supporting this; they don't seem to understand what patrolling is actually used for. I mean, can't you admins tag pages you create if they have issues? That's the only reason new pages are marked as "patrolled". smtchahal(talk) 15:52, 8 May 2013 (UTC)[reply]

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)[reply]

It certainly doesn't address my concern. Malleus Fatuorum 22:45, 6 April 2013 (UTC)[reply]
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)[reply]
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)[reply]
+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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I simultaneously oppose this proposal and do not believe that significant content creation is required for RfA. To me, the key point is that an admin ought to know how to create a decent article and be able to evaluate the quality of articles; whether they actually create a lot of articles is not important. If you can't write a proper article, then I won't trust you to pass judgment on others' articles. It's the ability that counts, not the number. -- King of ♥ ♦ ♣ ♠ 10:09, 17 April 2013 (UTC)[reply]
As I said somewhere in a long conversation above, administrators ought to have a basic understanding of our content policies. That's a long way away from our standards at RfA. If you haven't written a GA and don't spend most of your time writing content, someone's probably going to oppose your RfA for lack of content creation experience. Even if you have written a GA you still might get opposed for lack of content creation experience. These standards are, in my view, wildly excessive and completely disconnected from the kind of work that the vast majority of administrators do. On the other hand, the barrier for getting an article past NP patrol is very low. So long as it doesn't qualify for speedy deletion, cites some decent-looking sources, and doesn't have any obvious formatting problems an article will be waved through. This is much, much closer to the "basic understanding of our content policies" criterion than the standards used at RfA. Hut 8.5 18:06, 17 April 2013 (UTC)[reply]

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) [reply]

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.
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

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) [reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • Long overdue. This is just bureaucracy getting in the way. I've seen perfectly good AfD discussions closed simply because the nominator is not proposing deletion. Any discussion that decides whether an article will cease to exist independently should occur at a central location. Though a remark: If an article would be a suitable candidate for WP:PROD but the nominator wishes to merge and/or redirect it, then they can just do so BOLDly, and if they get reverted, take it to AfD. This mimics the usual PROD process. -- King of ♥ ♦ ♣ ♠ 10:16, 17 April 2013 (UTC)[reply]
  • Support - That happened to me atleast twice. I concur with King of Hearts and wholeheartedly Support centralisation. TheOriginalSoni (talk) 10:20, 17 April 2013 (UTC)[reply]
  • At some point in time the general mindset has developed that AfD is only for deletion, and no decision other than delete/keep/no consensus can be made, going so far that even when there is a clear consensus for merge or redirect (as acknowledged by the closing admin), the article will still be kept because it's an AfD. That is unfathomably stupid on so many levels. This proposal would eliminate that stupidity, so strong support. --Conti|✉ 10:44, 18 April 2013 (UTC)[reply]
  • Support centralization per King of Hearts' rationale. He sums up my opinion perfectly. Imzadi 1979 → 10:48, 18 April 2013 (UTC)[reply]
  • Support people treat AFD like this already, including myself, since the proposed merge process is largely ineffective. --Rschen7754 10:57, 18 April 2013 (UTC)[reply]
  • Strong support. Ironholds (talk) 12:37, 18 April 2013 (UTC)[reply]
  • Comment: I have no strong objections to the general idea, but I think the specific title "Articles for discussion" is potentially vague / confusing for less-experienced users; it might mislead some into thinking that all significant changes to articles need to be discussed there rather than being boldly applied. --SoledadKabocha (talk) 19:58, 18 April 2013 (UTC)[reply]
  • Support. I agree with a number of points here. The merger process has been, in my experience, ineffective at generating discussion. There also is some unnecessary bureaucracy at AfD: I've seen AfDs closed for proposing mergers or redirects (although I have admittedly advocated for these closings at times in the past). Additionally, I've seen AfDs with a consensus to merge closed as keep, with the closing admin stating that merges must be discussed on the talk page instead, despite existing consensus. I believe this proposal would address these issues rather well, but I must concur with SoledadKabocha that a better name than 'Articles for discussion' could be chosen. (Thus my grand return to Wikipedia begins…) CtP (t • c) 21:38, 18 April 2013 (UTC)[reply]
  • Question - Should obvious redirect articles, such as a WP:SCHOOLOUTCOMES redirect, still be WP:BOLDly redirected without taking it to AfD? Michaelzeng7 (talk) 00:52, 19 April 2013 (UTC)[reply]
    As I said in my comment, if an article is uncontroversial enough that it would fall under PROD if deletion were being proposed, then a BOLD redirect is fine. -- King of ♥ ♦ ♣ ♠ 01:08, 19 April 2013 (UTC)[reply]
  • Oppose. A real problem has been cited, but this is the wrong solution.
    As has been pointed out on numerous occasions, a merger cannot be carried out in the same fashion as a deletion (i.e. by pressing a button). It often requires a significant amount of time, planning, effort and discussion (before and during the process), along with a higher degree of familiarity with the subject than can be expected of participants in an outside process. That's why it makes sense to organize such matters on the articles' talk pages.
    Chris the Paleontologist has "seen AfDs with a consensus to merge closed as keep, with the closing admin stating that merges must be discussed on the talk page instead, despite existing consensus." Such a closure is flat-out wrong. AfD isn't the correct venue in which to propose a merger, but if such a consensus is reached (as an alternative to deletion), it's entirely valid. The correct course of action is to tag the source article with {{afd-merge to}} and the destination article's talk page (where any necessary organization should occur) with {{afd-merge from}}.
    The solution is to inform such administrators that they're acting inappropriately, not to shift all merger discussions to AfD. —David Levy 01:39, 19 April 2013 (UTC)[reply]
  • Support So many times I have seen discussions on talk pages either lay ignored or argued by the same people involved in the article. AfD is a better venue, especially since some of the outcomes result in the deletion/dissapearance of the article in question. And I support the name change to Articles for Discussion, but I have a feeling that'll be a different discussion for a different day. One step at a time. Angryapathy (talk) 01:41, 19 April 2013 (UTC)[reply]
    If a merger proposal is ignored, the merger may simply be carried out. The proposal isn't required in the first place; it's an optional request for input/assistance. That's one of several respects in which merger proposals are fundamentally different from deletion nominations. We needn't shift routine article improvement discussions to a separate venue. —David Levy 01:57, 19 April 2013 (UTC)[reply]
    Not really. We have two cases: either it's potentially controversial or it's not. If it is, then even if the merger proposal is ignored, the merger should not be carried out. If not, then yes, just carry it out; no one is suggesting we get rid of the ability to merge without discussion entirely. In deletion we have WP:PROD for that. -- King of ♥ ♦ ♣ ♠ 02:02, 19 April 2013 (UTC)[reply]
    One of the purposes of proposing a merger instead of simply performing it is to determine whether it's controversial. If no one objects (and no other evidence of controversy exists), it's okay to simply proceed with the merger. No administrative tools are involved (and no content is made inaccessible), so anyone can undo the merger and revive the discussion. It's simply a form of bold editing, not unlike removing inappropriate material, adding brand new material, or reformatting an article to improve its flow. All of these are routine revisions, the discussion of which is the reason why article talk pages exist.
    Merger proposals also serve other purposes, of course. They're made by editors who wish to solicit feedback on how to carry out a merger and those who don't feel comfortable doing so themselves. Again, these are normal talk page discussions. They might take a while, and they often require the knowledge of those who've read/edited the relevant sources/articles and are familiar with the subjects and how they relate to each other. Such discussions aren't comparable to deletion debates. As noted above, a merger can't be performed by pushing a button.
    It makes as much sense to send merger discussions to AfD as it does to send cleanup discussions or expansion requests there. Merging is a form of editing, not deletion. —David Levy 02:31, 19 April 2013 (UTC)[reply]
    Before you can start discussing how to merge, you must decide whether to merge. And that is something which AfD can perfectly handle. -- King of ♥ ♦ ♣ ♠ 09:49, 19 April 2013 (UTC)[reply]
    As noted above, AfD cannot "perfectly handle" all merger proposals. It depends on the context.
    If an article has been nominated for deletion, it's reasonable to discuss merging as an alternative. If the article's very existence is seriously challenged (and relocating its content elsewhere is viewed as a viable alternative to deleting it outright), "merge" is a reasonable AfD outcome.
    But if deletion isn't requested, there's nothing to be gained (and a great deal to lose) by shifting the discussion to a separate forum. In such a circumstance, a merger proposal is an ordinary article content discussion, with no outside process or administrative intervention required. What often is required is input from persons knowledgeable on the articles, their subjects and their sources, discussing the proposed merger over a period likely to exceed AfD's arbitrary duration. It might be a while before editors respond (depending on how much traffic a talk page receives), in which case such a wait is necessary. Artificially accelerating the discussion by shifting it to AfD and closing it after a week or two is actively counterproductive. It greatly reduces the likelihood of soliciting input from editors whose knowledge enables them to understand how the articles' subjects relate, thereby greatly increasing the likelihood of reaching the wrong decision (which will either be undone or never be carried out). This already is an issue, as evidenced by the numerous talk pages littered with years-old {{afd-merge from}} tags describing mergers that never took place (with the source article either surviving or being merged into a more appropriate target).
    Even when "merge" is the correct outcome at AfD, it doesn't bring the process to a tidy conclusion. (We have no "merge" button to press.) Instead of contributing to the backlog of merger proposals, we contribute to the backlog of merger decisions waiting to be acted on, the only material difference being that no helpful input is even being requested (because the decision already has been made — by parties less knowledgeable on the subjects and their relationship).
    User:Feedback noted that a merger proposal generated no response after "almost three days" (not nearly long enough to wait, incidentally), but an AfD listing generated a response within four hours. Well, yeah. Editors spoke up because they saw the article nominated for deletion (an administrative action that most users cannot reverse) and didn't want that to occur. In no way does this help us to perform the proposed merger, which still requires actual editing to carry out. It merely increases the congestion at AfD.
    And routinely handling merger proposals at AfD won't magically generate more participation; it will simply dilute (and overburden) AfD. As I said, it's the possibility of deletion that elicits quick responses. If we change AfD to a forum in which discussions don't necessarily relate to deletion, the community will react accordingly. WP:PM already serves as a central location at which proposed mergers may be advertised. I can't imagine why anyone believes that an "AfD" stamp (with no actual threat of deletion) will somehow send people running to comment. We'll just have a bunch of merger listings clogging AfD (with few generating meaningful input in the week or two before they're closed) — which could have been constructive discussions if they'd been held on the articles' talk pages, with no artificial deadline imposed (thereby enabling knowledgeable parties to participate).
    Imagine treating other content concerns this way. Someone wants to trim, expand, reword or reorganize an article, and instead of discussing it on the talk page, we send them to AfD and demand that a binding decision be reached within a week or two. That isn't much different from what's been proposed above. —David Levy 14:26, 19 April 2013 (UTC)[reply]
  • Oppose. Merges and Smerges and conversion to redirect are not deletion discussions. Redirects that are put forward as "Redirect or Delete but the article and content must not stay" are in practice already welcome at AfD. Merges and Smerges require a lot more care than is appropriate for a seven day discussion. Generally the motivation comes frmo the article to be merged, but then needs to be negotiated at the target, and then things get complicated beyond the scope of a seven day discussion. A disputed merge would be more appropriately listed as an RfC. However, what we need is more bold editing and less process, contrary to the likely effect of this proposal. From the AfD perspective, AfD is a well functioning polished process but so overloaded it is ripe to bust or collapse. Pushing ill-aligned difficult merge discussions, and a large proportion of straightforward merge discussions into it may break its back. --SmokeyJoe (talk) 02:10, 19 April 2013 (UTC)[reply]
  • Oppose Deletion is a restricted function and so requires a special process. AFD is that process (along with PROD and CSD) and is already overloaded. Discussions at AFD are usually poorly attended, especially by editors who have some clue about the topic in question. For a fresh example, see this AFD which has been relisted twice without attracting any comment. Mergers and redirections are, by contrast, something that may be done by ordinary editing and so do not need concentrating in a special place. Such action blurs with other structural changes to articles such as re-sectioning or sorting and the best place for such discussions is on the talk page(s) of the pages in question. If the discussions are poorly attended then the processes of WP:BRD, WP:RFC and WP:3O may be used to attract attention. So, we have plenty of process already and the problem is a lack of interested editors. Changing the process will not resolve the problem and would make it worse by making AFD even more WP:TLDR. Warden (talk) 10:27, 19 April 2013 (UTC)[reply]
  • Oppose - merges and redirecting may be done by any registered user, subject to BRD; deletion is a restricted action, subject to strict policy, and possible only by admins. These should not mix. עוד מישהו Od Mishehu 10:52, 19 April 2013 (UTC)[reply]
  • Oppose per Warden. He says what I would have said had I said it before he said it. --Jayron32 13:40, 19 April 2013 (UTC)[reply]
  • Strongly support We have way too many venues to discuss things such as this. The arguments that closing an AfD should be as simple as pushing a button make no sense to me. Why should it be like that? So that people who are trying to rack up a high score can play the AfD game with no thought involved? That doesn't seem like a good reason to me. Gigs (talk) 16:12, 19 April 2013 (UTC)[reply]
    You've misunderstood. No one is arguing that "closing an AfD should be as simple as pushing a button". The point is that carrying out a decision to delete a page is accomplished in this manner. Consensus is achieved at AfD. Then an admin pushes a button, which deletes the page.
    Conversely, when a discussion results in consensus to perform a merger, we have no such button to make it happen. It requires actual editing, which often follows a great deal of planning and collaboration. Article talk pages exist for the purpose of accommodating such discussion. It's ordinary article revision, which is fundamentally different from deletion. —David Levy 17:20, 19 April 2013 (UTC)[reply]
  • Oppose. This discussion is a demonstration of how formal procedures lead to voting, rather than constructive discussion with everyone aiming for consensus as is more commonly found on article talk pages. When I first commented above I did so without prefixing my remarks with a bolded recommendation, in the hope that others would do the same, but, as is normal for centralised discussions such as the village pump or AfD, this has degenerated into a vote with different sides taking entrenched positions, so I have to give my bolded "oppose" to ensure that my opinion is taken into account. Let's not subject editorial decisions such as merging to the same adversarial procedures. I could say much more, but SmokeyJoe, Colonel Warden and David Levy have expressed my thoughts better than I could do myself. Phil Bridger (talk) 17:37, 19 April 2013 (UTC)[reply]
  • Support - The net result may be fewer deletions, more merges and redirects when everything is more properly on the table. The overlap justifies consolidation, and allows to (perhaps) discuss more and vote less. Dennis Brown - 2¢ © Join WER 18:48, 19 April 2013 (UTC)[reply]
    The option of merging and redirecting already is on the table at AfD. In no way does the current format limit the options to "delete" and "keep as a standalone article".
    An AfD debate can result in a number of different outcomes. This doesn't mean that such solutions should be proposed there. For example, there might consensus that an article shouldn't be deleted, but it requires cleanup. That doesn't mean that cleanup proposals should be made at AfD.
    Merging essentially is a form of cleanup. It isn't comparable to deletion and needn't be routinely discussed in a special forum. —David Levy 19:04, 19 April 2013 (UTC)[reply]
    Of course they are, that isn't the point. The point is that often someone might not know the best course of action, but know a stand alone article isn't the right answer. Having to choose from multiple places doesn't insure a better outcome, and may actually prevent the best possible outcome for each situation. At the end of the day, we serve ourselves best by having a system that simplifies the process of discussing a "problem" article, and doesn't require a nominator to determine the best possible outcome in advance. Dennis Brown - 2¢ © Join WER 22:01, 19 April 2013 (UTC)[reply]
    If someone believes that deletion should be considered (but isn't certain that it's the best solution), he/she can list the article at AfD (and can even mention merging as a possible alternative). This occurs under the current system; no change is required to enable it.
    If someone specifically wants to merge the article with another (and doesn't believe that deletion should be considered), there's no need to list it at AfD; the best discussion forum is the article's talk page (for reasons that I've explained above). The proposal, if implemented, would remove that option. It wouldn't make things any easier for editors who wish to discuss both deletion and merging, who already can do so at AfD. —David Levy 22:43, 19 April 2013 (UTC)[reply]
    No need to bludgeon the discussion, I'm aware of the current system and have participated in it extensively for many years. To say this would take away the ability to use the article talk page stretches credibility to the breaking point. Dennis Brown - 2¢ © Join WER 11:07, 20 April 2013 (UTC)[reply]
    I'm discussing the matter in good faith, with no intention of overwhelming others or ignoring their evidence. I disagree with you, but I'm not attacking you or disrespecting your opinion. I'm sincerely attempting to understand your argument and alleviate any possible misunderstanding on my part or yours.
    Given your familiarity with the current system, why do you assert that the proposed change is necessary to enable combined deletion/merger listings at AfD?
    Regarding the use of article talk pages, I'm unsure of what you mean. The idea calls for all merger proposals to occur at AfD. —David Levy 12:00, 20 April 2013 (UTC)[reply]
    From my experience, most merges don't happen at WP:Proposed merges to begin with, it happens with ordinary discussion on talk pages, a more informal process. This wouldn't prevent that. My argument is based on participating in over 1600 AFDs over the years, and having first hand experience with virtually every possible scenario. Doesn't make me right, but it does mean I'm familiar. Any time an article goes to any of these venues, the underlying problem is "This probably doesn't need to be a stand alone article", so consolidating them will mean a higher likelihood that all options will be considered, not just the default option for that particular venue. I'm shocked Warden doesn't like this, as it will likely mean fewer deleted articles, more merged content, more participation and a broader cross-section of the community reviewing each case. It means simplicity and a system that can be easier to use for the community as well. And the very name "Articles for discussion" can create an atmosphere that is seemingly less hostile that "Articles for DELETION", perhaps resulting in less voting (ie: the useless per nom !votes...) and more actual discussion. Human nature is funny that way. And by all means, express your opinion but please don't "alleviate" anything. While surely unintentional, it makes it sound as if the other person's !vote is based on ignorance or lack of experience. Dennis Brown - 2¢ © Join WER 16:06, 20 April 2013 (UTC)[reply]
    From my experience, most merges don't happen at WP:Proposed merges to begin with, it happens with ordinary discussion on talk pages, a more informal process. This wouldn't prevent that.
    Its section heading notwithstanding, the proposal is for "all the merge and redirect discussions going on talk pages" to be replaced by "merging them all into AFD". As a specific example, the proposer cited a merger discussion not listed at WP:PM.
    Any time an article goes to any of these venues, the underlying problem is "This probably doesn't need to be a stand alone article", so consolidating them will mean a higher likelihood that all options will be considered, not just the default option for that particular venue.
    We already have a venue in which all options can be considered: AfD. I don't object to the idea of renaming that forum to make this fact clearer, and I'm not sure that I even object to the elimination of WP:PM. I object to the proposed relocation of all merger discussions to AfD.
    And by all means, express your opinion but please don't "alleviate" anything. While surely unintentional, it makes it sound as if the other person's !vote is based on ignorance or lack of experience.
    I wasn't referring to your understanding of Wikipedia or position regarding the proposal. Note that I wrote "possible misunderstanding on my part or yours" (emphasis added), by which I was referring to the possibility that one or both of us misunderstood the other's comments (perhaps leading us to talk past each other). This appears to have been the case. —David Levy 18:08, 20 April 2013 (UTC)[reply]
    Note: Via this message, User:Feedback just confirmed that "if an editor feels that these decisions require a discussion, then this proposal says they should go to AFD instead of the article's talk page." —David Levy 12:39, 29 April 2013 (UTC)[reply]
  • About the volume: we tag about 200 articles per week for merging. Only a small fraction of these actually get listed at PM as being controversial or otherwise wanting input from people outside the regular editors at the page. The OP, for example, started this discussion one hour after proposing a merge. He never listed it at PM, where it would have turned up on several hundred watchlists. He just tagged it, put two sentences on the talk page, and then complained here that nobody commented fast enough to satisfy him.
    CAT:AFD has almost 500 AFD debates open at the moment. The daily AFD pages are already very slow to open. And if you add in 200 PMs... well, then you'll get what you expect. And if you're not going to list all of them, then we go back to the original question: why should we list PMs at AFD (opening them up to the possibility of unexpected deletion, because there's no way to prohibit people from !voting to delete what you only wanted to merge) when listing them at PM (whenever people like the OP choose to list them) seems to get the job done just as well? WhatamIdoing (talk) 20:14, 19 April 2013 (UTC)[reply]
    Right, most merger discussions don't really require a community discussion, just agreement on the talk page. So we won't be overwhelmed. that very few come to central page for them contributes to having it neglected, and is a reason to bring it into a more visible procedure. DGG ( talk ) 19:47, 21 April 2013 (edit) (undo)
    Right, most merger discussions don't really require a community discussion, just agreement on the talk page.
    This proposal calls for "all the merge and redirect discussions going on talk pages" to instead occur at AfD. —David Levy 19:53, 21 April 2013 (UTC)[reply]
  • Oppose Been thinking about this since proposed. Fence sitting. D. Levy (above) has it right I think, and I'm off the fence. The Merger discussion needs to take longer than the AfDelete discussion, because it takes that time for knowledgeable editors to make their way to the talk pages of the merge requests. This proposal will overwhelm AfD, and we will unavoidably lose (good content and potentially good) articles because of the discussion-time limitations there. We can use help, by the way, working on the oldest (back-end) articles at Category:Articles to be merged after an Articles for deletion discussion. Thanks. GenQuest "Talk to Me" 23:58, 19 April 2013 (UTC)[reply]
  • Oppose - Merger discussions can be longer than deletion discussions need to be, and the sheer volume of deletion discussions means that they need their own place. Lukeno94 (tell Luke off here) 10:08, 20 April 2013 (UTC)[reply]
  • Oppose per my exact same comment I made several years ago at Wikipedia talk:Articles for discussion/Proposal 1, which remains largely unchanged (with minor edits):

    I don't understand why a blessing from an admin is necessary on anything except a deletion or non-deletion as far as AFDs are concerned. Also, perhaps I'm against this notion of, as opposed to keeping discussions on major editorial actions (such as merging) local and strictly amongst those users who are actively collaborating on an article, having "community exposure" on each and every single major editorial action made on every article on Wikipedia. Article talk pages, not a centralized community venue, are the places to discuss such editorial changes. I think we've gotten so lock-step into just typing in simple !votes for literally everything (like what we're all doing here now) instead of actually having a discussion, which has been at least what I have experienced in the last few merge proposals I have brought up (even though it's been a while, now). I also have to echo some of the concerns that Colonel Warden brought up such as overloading the already-overloaded (IMO) AFD queue.

    Also per Colonel Warden's statements made above today. --MuZemike 17:26, 20 April 2013 (UTC)[reply]

  • Support Many redirects are mergers are noncontentious, and don't need a discussion; but may are, and they are usually a question of notability. Notability is best judged by discussion, and the discussion is best at a centralized place where all the possibilities can be considered. The idea that redirects and merges are just ordinary editing is long obsolete, if it was ever true. We now accept that an afd close can force a redirect or a merge, and many do. And, it still does happen that a redirect or merge is a disguised deletion--and this will succeed if attention is not paid. The way of getting attention is to list at AfD. Articles for discussion is what it really is, and people increasingly do bring articles there even if they are not sure they should be deleted, in order to get a community devision. It's the best way yto get a good result. . Six years ago, AfDs would be summarily closed as inappropriate if the purpose were other than deletion, which is now rarely argued. It is good to have a discussion sometimes not to bring about what one wants, but to see what is wanted. We passed this once, 4 or 5 years ago, but forgot to implement it. let's do it now. DGG ( talk ) 06:28, 21 April 2013 (UTC)[reply]
    The idea that redirects and merges are just ordinary editing is long obsolete, if it was ever true.
    They aren't ordinary editing? What nonstandard tools are involved?
    We now accept that an afd close can force a redirect or a merge, and many do.
    An AfD debate might result in the determination that an article requires cleanup (copyediting, better sourcing, etc.). That doesn't mean that AfD is the correct venue in which to request cleanup.
    Articles for discussion is what it really is, and people increasingly do bring articles there even if they are not sure they should be deleted, in order to get a community devision.
    I'm not 100% clear on what that means, but yes, editors are welcome to list an article at AfD if they're unsure of whether it should be deleted or merged. As you've noted, this already occurs. So why is the proposed change needed? Why should all merger discussions be held at AfD?
    We passed this once, 4 or 5 years ago, but forgot to implement it. let's do it now.
    We passed a proposal to shift all merger and redirection discussions to AfD? Please provide a link. —David Levy 07:33, 21 April 2013 (UTC)[reply]
    Wikipedia talk:Articles for discussion/Proposal 1 is likely what you are looking for. We had the consensus, what was lacking was the follow through on implementation. Dennis Brown - 2¢ © Join WER 11:48, 21 April 2013 (UTC)[reply]
    That was a proposal for a setup in which "anyone could optionally move a disputed merge to AfD, retitled Articles for Discussion". This is a proposal for "all the merge and redirect discussions going on talk pages" to be replaced by "merging them all into AFD". —David Levy 16:26, 21 April 2013 (UTC)[reply]
  • Comment: Again, I would like to reiterate that this proposal does not mean AfD will be the place to discuss how to merge an article into another, but merely whether it should be done (depending on its level of individual notability). The ultimate merging process will be discussed on the talk page, as always. -- King of ♥ ♦ ♣ ♠ 08:30, 21 April 2013 (UTC)[reply]
    ...which is exactly what's done now when an AfD debate results in a decision to merge. As discussed above, we needn't shift all merger proposals there to enable this to occur. The current system facilitates it.
    Most merger suggestions, many of which have nothing to do with the subject's "level of individual notability" (instead focusing on simple matters of length and organization), are best suited to the relevant articles' talk pages. Routine editing discussions don't belong in outside forums. Article talk pages exist to accommodate them. —David Levy 16:26, 21 April 2013 (UTC)[reply]
  • Support, standardization and uniformity and centralization would be a good thing. — Cirt (talk) 18:17, 21 April 2013 (UTC)[reply]
  • Support. The current system is confusing for new users. It can take a good while for users to get their heads around our different notability criteria and precedents at AfD, and it is easy for them to choose the wrong venue. Putting all these discussions in one place with one procedure would make things simpler, and the less steep our learning curve is the better chance we have of retaining editors.

    If doing this makes the daily logs too slow to load we should fix this by technical means - there's no need to throw out a promising proposal because it doesn't match the exact page structure we have at the moment. For example, we could link all the discussions in the daily logs instead of transcluding them, and in addition create daily logs sorted by the subcategories in Category:AfD debates where all the discussions were transcluded. We could also consider more closely integrating WP:DELSORT with the current AfD structure. — Mr. Stradivarius ♪ talk ♪ 15:32, 22 April 2013 (UTC)[reply]

    It can take a good while for users to get their heads around our different notability criteria and precedents at AfD,
    And the solution is to send more discussions there (including many that have nothing to do with notability)?
    and it is easy for them to choose the wrong venue.
    Under the proposed change, users attempting to discuss ordinary editing (reorganizing content by transferring it from one page to another) on the relevant articles' talk pages would be informed that they've "chosen the wrong venue" and forced to file a special listing at an outside forum, where editors who've never seen the articles before will reach a binding decision by an arbitrary deadline. This is supposed to make things easier and less intimidating?
    Putting all these discussions in one place with one procedure would make things simpler, and the less steep our learning curve is the better chance we have of retaining editors.
    Why stop with these discussions? Why not eliminate article talk pages entirely and move all content discussions to AfD? "Want to discuss expanding an article, rewording a section, or updating some of the sources? Take it to AfD. We're making things simpler by putting everything in one place with one procedure." —David Levy 17:27, 22 April 2013 (UTC)[reply]
  • Support, since many AfD discussions result in mergers and/or redirects anyway as it is; AfD is, de facto, "Articles for Discussion". Miniapolis 21:41, 26 April 2013 (UTC)[reply]
    AfD discussions result in all sorts of outcomes other than deletion. It might be determined that an article requires cleanup (copyediting, better sourcing, etc.). Should we transfer all cleanup requests to AfD? —David Levy 00:26, 27 April 2013 (UTC)[reply]
  • Support This is pretty much happening already, and a lot of mergers and redirects touch on notability and other topics at which regular AFDers are expert. This would also, hopefully, reduce the distressing number of "hanging" merger and redirect proposals. RayTalk 23:36, 26 April 2013 (UTC)[reply]
    This is pretty much happening already,
    Merger discussions are being barred from talk pages and preemptively sent to AfD?
    and a lot of mergers and redirects touch on notability and other topics at which regular AFDers are expert.
    A lot don't. Many merger discussions relate strictly to considerations of article length and organization (and have nothing to do with notability or anything similar). Routine article content discussions don't belong in a special forum. The articles' talk pages exist specifically to accommodate them.
    This would also, hopefully, reduce the distressing number of "hanging" merger and redirect proposals.
    ...by enforcing an arbitrary deadline instead of waiting for someone knowledgeable on the articles' subjects and their relationship to participate. Then we'll have a huge backlog of merger decisions instead of merger proposals (because, as discussed above, we have no "merge" button to press). Numerous talk pages already are littered with years-old {{afd-merge from}} tags documenting mergers decided upon at AfD but never carried out. —David Levy 00:26, 27 April 2013 (UTC)[reply]
  • Support for borderline cases. Merge and redirect have long been possible outcomes at AfD, and I have for many years observed that the backlog at those other pages make it very unlikely for a decision, discussion, or any outcome whatsoever to occur at the other venues in a timely fashion. However, I believe these venues should be retained for complex or highly controversial merge and/or redirect proposals. AfD is perfect for borderline cases: pages that could stand to be deleted, but a merge or redir accomplishes the same outcome. Pages like these are simple to review, and the merge tends to be a copy-paste of a paragraph into the destination article. However, the community at AfD would be incapable on the whole of evaluating a complex merge or split proposal. —/Mendaliv/2¢/Δ's/ 21:54, 28 April 2013 (UTC)[reply]
    As discussed above, in borderline cases (in which someone is unsure of whether an article should be deleted or merged), the current system permits an AfD listing (in which both options, along with other possible solutions, are considered). No change is needed to enable this; it's how things work now.
    The proposal calls for "all the merge and redirect discussions going on talk pages" to instead occur at AfD, which you obviously don't support. —David Levy 22:31, 28 April 2013 (UTC)[reply]
    When I said borderline above, I should have said "notability-based". That is, I support the rolling of pure merge or pure redirect proposals into AfD where such proposals' rationales are based on relatively bright-line notability (as well as WP:NOT) issues, which are the bread-and-butter of AfD. I support this because the "rules of procedure" for AfD already explicitly allow this, or at least can be amended to allow it with little disruption. I admit, this may well apply to the vast majority of proposed merges. But what of the remaining ones? Merges proposed more for stylistic or prosaic concerns, or splits for that matter? Or undue weight issues? I think AfD at present requires very different skills, and to force the entirety of proposed merges onto AfD would either disrupt the culture this proposal hopes to harness, or result in a large number of ignored merge/redirect requests just as under the present system. —/Mendaliv/2¢/Δ's/ 23:06, 28 April 2013 (UTC)[reply]
    Thanks for clarifying. Depending on its implementation, I might support a proposal to shift disputed mergers based on notability concerns and WP:NOT issues to AfD (even when outright deletion isn't sought).
    But if there isn't an active dispute, this shouldn't be a first-line measure. Unlike deletions, mergers needn't even be proposed. Lacking evidence/suspicion of controversy, editors are encouraged to simply merge articles as they see fit. Even when a merger is instead suggested on the article's talk page, this doesn't necessarily indicate that it's controversial. (It might simply mean that the editor seeks advice on how to carry out the merger or doesn't feel comfortable on a mechanical level.)
    In the case of a notability/WP:NOT-based merger that's contested (either opposed or reverted, with no clear consensus emerging on the talk page), I can understand why an AfD listing might be helpful. —David Levy 23:37, 28 April 2013 (UTC)[reply]
    This proposal does not take away the ability of an editor to boldly merge two articles, or boldly use ATD-R. If an editor feels that his edit doesn't require a formal discussion, then by all means, he/she can edit boldly. However, if an editor feels that these decisions require a discussion, then this proposal says they should go to AFD instead of the article's talk page. At AFD, they will get more participation and a much clearer community consensus. Feedback ☎ 11:59, 29 April 2013 (UTC)[reply]
    Yes, I understand your proposal. I've explained why most merger discussions belong on articles' talk pages and why shifting all of them to AfD wouldn't result in "more participation and a much clearer community consensus". —David Levy 12:18, 29 April 2013 (UTC)[reply]
    This can be handled by a slight tweak, instead of "that require a discussion". make it "that are disputed". DGG ( talk ) 02:49, 2 May 2013 (UTC)[reply]
    "Proposed mergers lacking consensus (for or against)" might be a better description. (Otherwise, a single editor could block a strongly supported merger and send the matter to AfD by opposing it without explanation.)
    In a no-consensus situation, I still see no need to transfer the actual discussion to AfD (especially if it's already active on the article's talk page). A possible alternative is a notification system, similar to RfC, though which messages are posted at AfD to invite its editors to participate. —David Levy 03:45, 2 May 2013 (UTC)[reply]
    You keep replying to everybody with basically the same points. Take a chill pill and try to avoid spamming the discussion. All of your 22 above posts are available to everyone who participates in the discussion, you don't need to repeat them under every single vote. Feedback ☎ 01:34, 4 May 2013 (UTC)[reply]
    Good-faith discussion ≠ "spamming". Some of my comments are repetitious because I'm attempting to interact with editors casting votes without addressing relevant concerns previously expressed. Some of the supporters misunderstand what you've proposed (in part, most likely, because the section heading refers to "WP:Proposed mergers" instead of all merger discussions), and they evidently aren't reading the previous messages in which the discrepancy was explained.
    It's odd that you wrote the above complaint in response to a message in which I expressed partial agreement with a supporter and suggested a possible implementation not previously mentioned. —David Levy 21:33, 4 May 2013 (UTC)[reply]
    I see why it can cause confusion, but think the title is still adequate. I'm asking to merge the three processes above. Merge, Blank-&-Redirect and Deletion discussions should all be done at AFD. Feedback ☎ 02:19, 5 May 2013 (UTC)[reply]
    I'm not blaming you for the misunderstanding. (Having read your comments, I found your proposal clear.) I'm explaining why my replies have been partially repetitive: some editors seem to be skipping past earlier messages, including those in which you explained that the idea is to relocate all merger discussions (not merely those listed at WP:PM) to AfD. Some users are supporting the proposal without realizing that. (One stated that AfD "won't be overwhelmed" because "most merger discussions don't really require a community discussion, just agreement on the talk page." Another stated that "to say this would take away the ability to use the article talk page stretches credibility to the breaking point." Both equated the proposal with an earlier one calling for disputed merger requests to optionally be transferred to AfD.) —David Levy 03:59, 5 May 2013 (UTC)[reply]
    Given the number of people whose comments basically amount to "I didn't read Feedback's clearly explained proposal", I'm adding a nutshell in this edit that summarizes the key points that people keep missing. Perhaps it will result in comments that have something to do with this proposal, rather than with some imaginary proposal. WhatamIdoing (talk) 04:21, 6 May 2013 (UTC)[reply]
  • Support: merge discussions in talkspace are woefully underdiscussed; Talk:Men and feminism#Split and merge was proposed last March and didn't get any input until this February, and as of May, still no action has been taken. At the same time, with AfDs often getting relisted, I suppose that a standard 14-day limit with an early close option of seven days may be a good idea to ensure enough input for both merge and deletion discussions. Sceptre (talk) 04:44, 5 May 2013 (UTC)[reply]
    How, in your view, would such a change be beneficial?
    Let's assume, for the sake of discussion, that an AfD listing would generate more input (despite the lack of urgency brought about by the threat of deletion). And let's assume that the decision is to merge. Then what? Who's going to perform the merger?
    As noted above, numerous talk pages contain {{afd-merge from}} tags from years ago, describing AfD-determined mergers that have never occurred. Instead of contributing to the backlog of merger proposals, we'll contribute to the backlog of merger decisions waiting to be acted on. The latter is worse; the material difference is that no helpful input is being solicited (because the decision already has been made — by parties less knowledgeable on the subjects and their relationship). —David Levy 05:56, 5 May 2013 (UTC)[reply]
  • Comment: This proposal is based upon the premise that AfD debates receive a great deal of participation not because of their subject, but because they occur at AfD. This simply isn't true. They attract attention because they're about potential deletions — last-resort administrative actions that most users cannot undo.
    It doesn't make sense to think that we can take other topics (with far less urgency and no administrative intervention needed), slap an "AfD" label on them and magically duplicate the amount of feedback received via the current format. We'll simply end up diluting (and overburdening) the entire process, while simultaneously shifting the discussion away from the eyes of the editors most capable of addressing the relevant concerns (who might not show up within a week or two, but will be willing and able to provide assistance when they do arrive). —David Levy 06:21, 5 May 2013 (UTC)[reply]
  • Oppose. Merges and splits are content issues and should be part of the WP:BRD cycle. As previously stated by others, any user can perform or revert mergers and splits, and thus do not need admin intervention. Also, a merge discussion can usually take more than the seven-day AFD deadline because content issues need to be resolved. This includes whether it should be a full merge (pasting all or most of the content from the source article to the target page) or a selective merge (selecting only part of the content that should be merged). I disagree with the assumption that by moving all merger discussion to AFD, they will automatically receive more participation and become a better efficient way to "achieve consensus". Again mergers, especially selective merges, are content issues. Many participating in the normal AFD discussions will not know the intricacies of the subject of the articles to judge the 'gray area' of what verifiable content to keep and what to remove, and how to merge all this material in line with WP:BETTER, WP:WIAGA, WP:WIAFA, etc. (as oppose to the more blank-and-white deletion policies and guidelines), and thus will most likely not be able to post more helpful comments. Thus, this would become a fruitless exercise that adds to an already overburdened AFD process, with closing admins just posting the AFD-merge tag without actually performing the merge, and we are back to square one. IMO, it is more efficient to just go with the BRD cycle and subsequent dispute resolution steps involving merges and any other content related issues, rather than moving each and every such discussion to a central "Articles for discussion". Zzyzx11 (talk) 18:35, 5 May 2013 (UTC)[reply]

Protection of archived pages

Archived debates in AfD, MfD, and et cetera state that "this is an archived discussion......please do not modify it. Then, shouldn't archived debates be indefinitely protected by sysops the moment the debate is finished?--Seonookim (What I've done so far) (I'm busy here) (Tell me your requests) 09:56, 18 April 2013 (UTC)[reply]

I don't think the need is there, since disruptive editing of archives is rare (and like all edits, logged). There are also legitimate edits that sometimes have to be made to archives or archived discussions - sometimes extra notes on that page but not part of the archive; some technical fixes in the archive; and so on. These could be reduced by only protecting after a couple of days, but I think that would defeat the point and add to the workload. Grandiose (me, talk, contribs) 10:13, 18 April 2013 (UTC)[reply]
  • Oppose per Grandiose. It isn't really necessary, and edits that are truly disruptive can just be reverted, and single users who prove to be disruptive can be warned and blocked. This would only add to the heavy backlog of these discussion venues. Michaelzeng7 (talk) 12:12, 19 April 2013 (UTC)[reply]
  • Oppose per above. "Please do not modify it" refers to the content itself, but not such things as the categories or templates that may be used. It is merely to show that another view, or support or opposition of a mentioned view, shouldn't be added to it.  Hazard-SJ  ✈  04:49, 26 April 2013 (UTC)[reply]
  • Support, in some cases. When an archive is "closed" (i.e., Archive 5 is closed when Archive 6 is started), it could be protected, if dispruption is likely (such as archives of global-warming-related articles); the cost of having bot edits (substituting {{unsigned}}) and appropriate changes fail may be less than the cost of having to monitor the archive for vandalism and BLP violations. Those archives probably should be semiprotected, if we can ensure that bots are not prevented from operation by semiprotection.
    Sections which are archived discussions (and have that comment) cannot be protected unless the entire file is protected, which may not be appropriate. — Arthur Rubin (talk) 21:46, 1 May 2013 (UTC)[reply]
    Your caveats could be prevented easily by making SineBot, etc. admins. I support semiprotection for general archives so that temporary socks cannot interfere with them for some time, and full protection of the most contentious article archives. Wer900 • talk 23:15, 3 May 2013 (UTC)[reply]

Free Distribution of WikiReaders to offline schools around the world, funded by Kickstarter.com or Indiegogo.com

We want to buy ALL of these and give them away to schools in far-off communities around the world that don't have internet

Hi Everyone,

So I and my partner User:Ashstar01 had an idea: We saw that the WikiReader -- an open-hardware touchscreen LCD palm-sized reader of offline Wikipedia content (and other free-content too) -- manufactured by OpenMoko in Taiwan hasn't been selling and now has dropped significantly in price - you can purchase them new for as little as $10 on Amazon.com in the United States. We had a crazy thought - what if we started a campaign on Kickstarter.com or Indiegogo.com to buy ALL of the remaining inventory and give the WikiReaders away to schools in far-off communities around the world that don't have internet? I bought one to try it out, and they run on AAA batteries that last a while. Sometimes there is missing content (like graphs) or out of date info but so much is already there. They are also easy to use. User:Ashstar01 got in touch with the manufacturer who said that he has 21,000 devices in inventory that he could part with between $15-$20 USD depending if we took 10,000 or 21,000 units. That's $200,000 - $315,000 PLUS shipping and fees that would need to be raised.

We would like to run this idea by the community for a few reasons:

1.) We would need a list of schools and addresses of schools that could use these devices - plus photos to use to make a video for the campaign.

2.) Would Wikimedia Chapters be interested and able to help distribute these readers to schools in their communities?

3.) Another potential issue is that the units seem to ship with a 4gb card with an older version of English Wikipedia on them, and the latest version in English is 5gb, so it requires a new card, and a new update of the encyclopedia. This may not be an issue assuming that the places that we are sending the WikiReaders to may appreciate information that is a few years out of date (I know when I was in school in the 1980's some textbooks said that mankind still hadn't landed on the moon).

4.) Are there better options / other devices that might work better? I think that these are the lowest-power & cheapest offline readers of Wikipedia around, but I could be wrong. They are %100 open-source too :)

5.) What would be a good price point for the campaign? I'd hate to not raise enough to be able to give them away.

We think that it's unfortunate that the WikiReaders haven't been flying off the shelves in the first place, but what's more unfortunate is that there are kids who could use them (for whom the internet and even Wikipedia Zero is not an option) and they are just sitting in inventory.

Thanks for reading!

(for clarity, I'm doing this as a volunteer, not as an employee of Wikimedia) Victor Grigas (talk) 16:42, 20 April 2013 (UTC)[reply]

This idea is greatly appreciated! Surely, there is a source, a channel and a destination for this goodwill idea to triumph! ViswaPrabhaവിശ്വപ്രഭtalk 17:55, 20 April 2013 (UTC)[reply]
Comment Sounds like a great candidate for the Wikipedia Foundation Grant Program. You should check out the program and make a dollar request there for implementation. GenQuest "Talk to Me" 20:15, 20 April 2013 (UTC)[reply]
Brilliant idea. Definitely recommend a WMF Grant as an option for funding here. Steven Zhang Help resolve disputes! 20:50, 20 April 2013 (UTC)[reply]
Awesome idea! A meta page could serve as a good co-ordination point for discussion and implementation. Also, it sounds like a perfect proposal for Wikimedia Grants. TheOriginalSoni (talk) 11:19, 22 April 2013 (UTC)[reply]
Seems like a great idea! I agree with the others you should look into the WMF grants --Cameron11598 (Converse) 21:49, 22 April 2013 (UTC)[reply]
This does sound like a great idea, but one question that occurs to me is whether the batteries are going to be an affordable commodity for people in places where there is no access to the Internet. Formerip (talk) 22:08, 22 April 2013 (UTC)[reply]
Good point, maybe it would make sense to find out if this is a problem before shipping to a particular location, and if it is, then also ship a solar-powered AAA battery charger and an appropriate number of batteries too. However, this may not be an issue depending on where they go. Victor Grigas (talk) 22:42, 22 April 2013 (UTC)[reply]
(ec) Certainly. No internet does not mean no electricity. Even in villages with no electricity, battery items like torches, and therefore batteries themselves are accessible, if not commonplace. Also, AAA batteries cost very little comparing to the 'reduced price' of the WikiReaders (around 5-6 batteries a dollar), and are going to last for some time. So I think they are very affordable. TheOriginalSoni (talk) 22:46, 22 April 2013 (UTC)[reply]
Maybe, at an appropriate juncture, seeking advice from Oxfam or someone like that would be the way to go. I hear what you are saying, TOSoni, but I wonder if even a dollar might be a prohibitive price in some communities. I do know that the wind-up radio was introduced to address the problem of people in sub-Saharan Africa not accessing AIDS education because battery operated radios were no use to them. That is 20 years ago, but I think assuming that things are different now would be rash. Formerip (talk) 23:42, 22 April 2013 (UTC)[reply]
Yes. But only in some communities. And I am not sure those communities will be most benefited by Wikipedia, as they should be able to read English first. (No offence). IMO the most benefited one will be the BPL communities slightly above the one we were talking about who can afford to educate, but not provide it adequately. Moreover, we can also buy and give the batteries, if that was the case TheOriginalSoni (talk) 02:11, 23 April 2013 (UTC)[reply]
I've worked for Oxfam Solidarité in Belgium. Well... I'm not sure Oxfam could offer great feedback, as the methods and philosophy are different: Oxfam doesn't work on a top-down approach: they don't offer projects directly from Occident, but finances project requested by locals, tailored to their needs. The top-down approach is judged inefficient (false good ideas) and too paternalist (some projects could be resented as interference, intrusion). That's in phase with the philosophy to empower development. --Dereckson (talk) 09:43, 24 April 2013 (UTC)[reply]
I'm a little confused: Why does buying them wholesale ($15-$20) cost more than buying them retail ($10)? -- King of ♥ ♦ ♣ ♠ 22:21, 22 April 2013 (UTC)[reply]
The $10 price only comes from a few retailers on Amazon who want to clear out their stock. Currently, you could likely only get a few dozen units at most at this price. Of course we could wait a few months for the price to drop even more. The $15-$20 is a first offer via email from the manufacturer who likely has a motive to move the units as soon as possible. Victor Grigas (talk) 22:42, 22 April 2013 (UTC)[reply]
What is the target language? The options seem limited. --  Gadget850 talk 02:09, 23 April 2013 (UTC)[reply]
Even if it's English-only, India definitely can use them. -- King of ♥ ♦ ♣ ♠ 02:44, 23 April 2013 (UTC) (formerly misplaced, moved 10:59, 23 April 2013 (UTC))[reply]
Yes. My point was just that most of those who can use them can afford the batteries. TheOriginalSoni (talk) 10:54, 23 April 2013 (UTC)[reply]
WikiReader have language packs for many other languages. If a local chapter wants to distribute them in another language they just need to install the right packs in the SD Card. Crang115 (talk) 20:01, 29 April 2013 (UTC)[reply]
Yes, Crang115 is correct, the manufacturer has agreed to install whatever languages we specify and the micro-SD cards hold 8gbs, so we can choose from the available languages Wikipedia available in a text-only version. This includes about 16 languages. Making experiences more meaningful and less-broken. (talk) 22:51, 30 April 2013 (UTC)[reply]
We are planning to start the Indiegogo campaign on May 6th and are currently looking into possible grants that are able to be requested in the next month or so as the manufacture is looking to move his supply sooner rather than later. If no Wikimedia grant options are possible in the near time, we plan to submit a grant proposal after our Indiegogo campaign completes for a second round of fundraising to buy more devices as there are 21,000 devices waiting to be moved by the manufacturer. Making experiences more meaningful and less-broken. (talk) 20:16, 30 April 2013 (UTC)[reply]


Hi Everyone! We started a campaign here on Indiegogo: Click for the Indiegogo campaign The campaign is 45 days, please send the link everywhere you can! Victor Grigas (talk) 04:11, 5 May 2013 (UTC)[reply]

Temporary Watchlist

Tracked in Phabricator
Task T8964

Hello Wikipedia. One of my biggest annoyances on Wikipedia is logging onto Wikipedia, clicking on my watchlist, and seeing several dozen entries for articles that I don't remember at all. Then, when I go to clear those entries from my watchlist, I see a wall of many, many more articles that I don't remember at all. Clearing all of those articles out is a pain, and takes near forever. This problem is compounded because I watch a lot of articles for vandalism in the short term that I have no interest for in the long term. I suggest a simple solution: an expiration function for the user watchlist. This has been suggested several times before (not recently), with the conversation fizzling out or failing to occur both times; however, I believe it deserves a more serious look. The UI side of it would be simple: if you want to watchlist an article, when you hover over the star icon at the top, a dropdown list could appear that offers several watchlist expiry options (think favoriting pages on Chrome), such as general expiration (delete this page from my watchlist after __ days), edit-dependent (delete after __ days since my last article edit), or action-dependent (delete if this article [ ] becomes a redirect [ ] is deleted (think PRODed and CSDed articles)). You could continue to add pages to your watchlist indefinitely by clicking the star at the top, as usual. This would also add pages indefinitely even if your preferences default was non-infinite (see expansion below); you would always add articles that you wanted to expire via the dropdown menu. However, this would make your watchlist much more navigable and less daunting. This could also reflect in your watchlist entries themselves; a couple of sample entries could read as:

Jimmy Wales (talk | History) This page will be removed in 3 days [change]
Wikipedia (talk | History) This page will be removed if the article is deleted [change]

which would invoke the same dropdown list. I know this is a bad time to suggest a newT watchlist overhaul with the whole new notification system coming in, but is there any reason this can't be implemented at some point? This could even be a new notification class, like "Wikipedia was just removed from your watchlist." I think this would help me (and many other watchlist-weary editors) immensely.

So, Wikipedia, what do you think? Deadbeef 02:21, 26 April 2013 (UTC) (ironically, now watching this page)[reply]

Expansion: You could also make a section in the preferences page to prefill default selections in the dropdown menu. This would make it so that simply clicking the star would still add a page to the watchlist normally, but the dropdown menu could have certain items set by default, depending on your preferences page. That way you wouldn't have to spend time every page picking the same watchlist expiry options, but you could still change them for a single page and have the options default back for the next one. Deadbeef 21:50, 26 April 2013 (UTC)[reply]

  • I think your general motive is good.  Hazard-SJ  ✈  04:52, 26 April 2013 (UTC)[reply]
  • No: This will make it very complex. Already the watchlist page is very complex with many many links. I suggest you to remove pages from watchlist periodically using this script --Tito Dutta (contact) 04:55, 26 April 2013 (UTC) Tito Dutta (contact) 00:22, 30 April 2013 (UTC)[reply]
  • I'd love this and have asked for it before. I'd be happy with a 30-day option: click "watch" for indefinite listings and "watch for a month" for a temporary listing. (Maybe a drop-down menu from the usual star?)
    AFAICT the script Tito links is irrelevant. I want "my watchlist will never again show me the dozens of user pages that ended up on my watchlist because I left one message on them two years ago" and it gives "only display pages that have changed since the last time you looked" (which is not very different from what I've got now, with changed pages listed in bold). There are currently more than 300 user pages on my watchlist. I want my watchlist itself to contain only those that I care about, or at least only those that I've edited this year. WhatamIdoing (talk) 05:37, 26 April 2013 (UTC)[reply]
  • Strong support. I don't know if that is technically possible, but if it is, I fully support it. I am an NFCC enforcer and have Watch this page enabled by default to not miss any comments or edits regarding the non-free content in question. However that doesn't necessarily mean I am interested in the specific article and so yes, my watchlist gets rather long quickly as well. -- Toshio Yamaguchi 07:23, 26 April 2013 (UTC)[reply]
  • This is awesome. Brilliant idea. Not so sure about technical implementation, but I support wholeheartedly as a frequent WP:NPPer. —Theopolisme (talk) 11:24, 26 April 2013 (UTC)[reply]
  • Support though I suspect it would be hard to implement. I'd love to see this integrated with the Twinkle preferences: eg add an article to my watchlist for 14 days (only) when reverting vandalism, watch someone's talk page for 3 days (only) after leaving a warning message. Otherwise the watchlist just gets bigger and bigger. -- John of Reading (talk) 12:45, 26 April 2013 (UTC)[reply]
  • One of the best suggestions to come out the site.--Launchballer 12:52, 26 April 2013 (UTC)[reply]
  • Strong support, although I suspect the technical changes may be too major for it to actually get implemented. I'd also like some way of applying the options for folk (like me) who set their prefs to automatically watchlist any page they edit; whilst that's generally useful, it does clutter up one's list somewhat (currently 2,318 pages and counting, in my case). Prehaps there could be a default 30 days setting for such users, with override options for individual pages... However it's done, it strikes me as a very good idea. Yunshui 雲‍水 13:01, 26 April 2013 (UTC)[reply]
  • Yes, of course. I do not know how to do that facepalm thingie, but that would be one occasion to use it as in: why did no one think of this before. Lectonar (talk) 13:08, 26 April 2013 (UTC)[reply]
  • Support This would be helpful for 'vandal fighters', 'mergists', and admins especially. GenQuest "Talk to Me" 20:18, 26 April 2013 (UTC)[reply]
  • The downside of a drop-down type thing is that this would make watchlisting a little more time consuming every single time anyone watchlisted an article. That's not insignificant; it adds up. But I still think the upside of a more useful watchlist for everyone would outweigh the downside. I support this as written, and would wholeheartedly support it if there was a way to make "forever" the default value if you just click "watch", so those who don't want to mess with it don't have to. And on Utopiapedia, the user could set what the default duration was in their preferences... --Floquenbeam (talk) 20:39, 26 April 2013 (UTC)[reply]
  • Conditional support. I don't want to risk losing the pages I watch permanently, but if a page can be added to the watchlist for a nominated period, say 1 month, It would be fine. • • • Peter (Southwood) (talk): 09:34, 27 April 2013 (UTC)[reply]
  • Support Great idea! Feedback ☎ 16:26, 28 April 2013 (UTC)[reply]
  • Comment Honestly I'd rather just have a script that prunes from my watchlist pages that were added because I was using Huggle and Twinkle. I would not use something like this. —/Mendaliv/2¢/Δ's/ 23:22, 28 April 2013 (UTC)[reply]
  • Support as long as it's optional, since I have absolutely no use for such a thing and definitely wouldn't want it. Use a dropdown as Deadbeef proposes, or have something in Special:Preferences, or do anything else to permit either opt-in or opt-out, and I'll happily support. Nyttend (talk) 23:53, 28 April 2013 (UTC)[reply]
  • Support as a useful addition, provided there's a way of making "forever" the default value, per Floquenbeam above. It really is far from insignificant to have to mess with a dropdown every time one clicks "Watch". A default would be needed anyway for the pages I start to watch by editing them/moving them, etc, without even having to click "Watch", wouldn't it? (Per Preferences —> Watchlist —> Advanced options, surely useful and common choices). Bishonen | talk 12:43, 29 April 2013 (UTC).[reply]
  • Support - obviously a useful option for some, at least some of the time. But as so often with interface changes, it would need to be done in such way that those people who want to stick with the status quo can. Rd232 talk 18:10, 29 April 2013 (UTC)[reply]
  • Support It'd be bloody useful. Even better would be to have a little Ajax flyout come out after I 'star' a page asking me how long I want it watchlisted. This (plus cross-wiki watchlists, obviously) would make me very happy. —Tom Morris (talk) 14:45, 1 May 2013 (UTC)[reply]
    Actually one thing I was going to say but forgot: be careful on the "until deleted" thing. There may be a reason why an admin deletes something and then brings it back a few minutes later (revdel/oversight, history merge, etc.) It might be advisable to either not have the "until deleted" feature, or to strongly discourage its use. —Tom Morris (talk) 14:47, 1 May 2013 (UTC)[reply]
  • Support - As it's optional, this is a fantastic idea. Lukeno94 (tell Luke off here) 20:12, 1 May 2013 (UTC)[reply]
  • Strong support I love it. I'd definitely use it. Can't come soon enough. --BDD (talk) 20:15, 1 May 2013 (UTC)[reply]
  • Strong support: I've often thought how useful this would be, but waited for someone else to articulate it. I stub-sort a lot, and come across a lot of articles where I've got no particular long-term interest but would like to see whether anyone does anything in the immediate future in response to my actions or talk page messages. A 30-day watchlist option would be great (there are 5k items on my watchlist at present). As a Second proposal: it would be wonderful to be able to watchlist a section of a page, specifically a user talk page or a project talk page. If I've left someone a comment, I'm interested in their, or anyone else's, replies on that topic, but I may or may not want to be alerted every time someone else leaves a message on their talk page. But perhaps I should make that a separate proposal. PamD 08:58, 2 May 2013 (UTC)[reply]
  • Strong support Great idea. And as it would be optional, how could anyone reasonably object? Edwardx (talk) 13:24, 2 May 2013 (UTC)[reply]
  • Support', so long as the default "default" option is "forever". Ignatzmice•talk 16:01, 2 May 2013 (UTC)[reply]
  • Strong support Great idea. I would use it for all user pages, especially ip-users that I have given a welcome or a warning. They are on my watchlist because I want to know if they answer me but it's a drag having them on my watchlist half a year or two years after I posted them a message. Lova Falk talk 16:09, 2 May 2013 (UTC)[reply]
  • Very strong support I wonder why I never thought of this myself. As with others, most of my watchlist is new editors, ip or otherwise, whom I need to track for a month or two. I think there's essentially unanimous support for this, and we could snow close the rfc. 'DGG (at NYPL) (talk) 19:56, 2 May 2013 (UTC)[reply]
  • Support - Yes, for a long time I've wrestled with either being very restrained of what I put on my watchlist or putting a lot on and having to do regular cleanouts which can get tiresome. Having the option of setting an expiry would be very helpful. CT Cooper · talk 21:02, 3 May 2013 (UTC)[reply]
  • Support and idea - There are a few some many articles on my watchlist that are meant to be gotten rid of as soon as the article passes a certain standard (GA, FA, etc.) so I suggest the following:
  • Support - I have a whopping 8,224 pages on my watchlist, most are for articles I patrolled or users I warned. I had already been thinking of "purging" my watchlist of unneeded pages for quite some time, but this would work as well. Narutolovehinata5 tccsdnew 15:09, 5 May 2013 (UTC)[reply]
    I did this a little while ago. Grabbed the title of every page I had edited, then copied the ones I had edited at least twice into the raw watchlist feature. Dropped something like 7000 pages immediately, and nothing of value was lost. ~ Amory (u • t • c) 23:18, 5 May 2013 (UTC)[reply]
  • Support This is a great idea. I have hundreds of pages on my watchlist, many of which were added as the result of seeing some posting at a community noticeboard, but I have no real interest in editing long term. A Quest For Knowledge (talk) 15:30, 5 May 2013 (UTC)[reply]
  • Neat idea, would like to see it implemented. ~ Amory (u • t • c) 23:15, 5 May 2013 (UTC)[reply]
  • Yes. And it would be great if this was− implemented on wikia as well. --Shabidoo | Talk 00:44, 6 May 2013 (UTC)[reply]
  • I would suggest different strategies.
    • First multiple watchlists e.g. add a page to your main watch list, or BLP list etc.
    • Second to put <notes> on the watch list e.g. Barack Obama <BLP issues>.
    • Third to be able to categorise your watchlist entries e.g. I can have a list of 16 or so definable cats that I add to watchlisted items, I can then display my watchlist per category e.g. BLP, temporary, articles I created, etc.
    • I would personally prefer the second and third options. I don't like the idea of articles being automatically expired, especially deleted articles. I keep some deleted articles on my watchlist in case they are recreated. Martin451 (talk) 00:15, 7 May 2013 (UTC)[reply]
  • Strong Support I have 11,000 pages on my watchlist (and that is net of several sessions of pruning, which is tedious and boring). Many on my watchlist because I made some minor change or left a comment, and would like to watchlist for a few days. In most cases, I would be happy if the item dropped off my watchlist after some period of time. While I see some clever conditions suggested (drop if article reaches GA) I'm worried that adding cleverness will delay the implementation so I urge that this be done in two steps. Step one, agree on a single termination measure, and Step Two, after step one is implemented, look into more robust measures. As a straw man for a single termination date, I suggest 3 months. I'll also suggest a slight modification, which may be even easier. Allow users to add to a watchlist list with a temporary flag. Once a quarter, a bot removes all entries that are more than three months old. This means is might last up to six months, but might be easier to implement, as the bot could be run four times a year.--SPhilbrick(Talk) 13:41, 8 May 2013 (UTC)[reply]
  • Support Wow I like this idea. -DJSasso (talk) 13:48, 8 May 2013 (UTC)[reply]
  • Yes, I would like this for the "watchlist all articles I edit" option, but I would want certain classes to be exempt from timing out otherwise it would be useless to me. Exemptions should include articles I created, articles to which I added more than x bytes, pages in my own userspace, and articles which I explicitly watchlist. SpinningSpark 14:44, 8 May 2013 (UTC)[reply]

Proposal to restart Template:Expand

Hi I would like to propose that someone restart Template:Expand because we could include a detect code so it will detect if it is a template and show the information for the template or it can detect an article and detect that one or something else since template:expand article is being deleted we might as well restart this template I will try out a new set off codes to propose to include in template expand 90.211.52.178 (talk) 13:18, 28 April 2013 (UTC)[reply]

It is unnecessary to point out to somebody that an article is hopelessly short by stuffing an annoying template at the top. Given the presence of a multitude of stub templates, I think the Expand template is unnecessary and it should be left obsolete. Thank you. Praemonitus (talk) 15:00, 28 April 2013 (UTC)[reply]
what about recreating template:article and creating some new template expand template for expand some new one could be like template:expand template and template:expand Wikipedia - used for the project pages and more template:expand 90.211.52.178 (talk) 15:24, 28 April 2013 (UTC)[reply]
You need to start writing in proper sentences if you want people to understand what you are proposing. Phil Bridger (talk) 15:37, 28 April 2013 (UTC)[reply]
ok if I test out some new expand template in sandbox could we create the template if they are ok with you 90.211.52.178 (talk) 16:57, 28 April 2013 (UTC)[reply]
please visit User:Paladox2014/sandbox because that where I am testing the new expand templates and template:expand article 90.211.52.178 (talk) 17:31, 28 April 2013 (UTC)[reply]
The {{expand}} and {{expand article}} templates weren't deprecated because of anything wrong with the way that they were coded, but because there is no need for them. No attempt to rewrite them will change that. Phil Bridger (talk) 18:56, 28 April 2013 (UTC)[reply]
Comment: One look at an article tells you if expansion is needed. The template(s) were redundant with common sense, that's why they were retired. GenQuest "Talk to Me" 19:01, 28 April 2013 (UTC)[reply]
ok but I like the templates and yes people would know that they needed expanding but what about if it is big a ouch but has been expanded in a while and so people would know that it needs to be expanded 109.155.55.77 (talk) 19:34, 28 April 2013 (UTC)[reply]
If an article hasn't been expanded for a long time, do you think adding a template at the top will help? It doesn't. Many of these templates are four or more years old and the issues have still not been addressed. How does adding another template help, other than by adding clutter? If you find an article is too short, then do the work and expand it. Praemonitus (talk) 21:43, 28 April 2013 (UTC)[reply]
  • Support Yes, it does help. It serves as a reminder. It can even be used for a chronological category, and people who like to do this sort of work could specifically look for them. It does no harm, and if even a few percent of the articles get improved because of this, all the better. 'DGG (at NYPL) (talk) 20:09, 2 May 2013 (UTC)[reply]
  • Oppose. Articles get expanded completely independent of the existence of this template, and if the purpose is to categorize pages, we could just use categories for that. --Conti|✉ 20:14, 2 May 2013 (UTC)[reply]

Acknowledgement required messages - a proposed new capability for admins

"I didn't see that message" is a common response to an inquiry as to why an editor did or didn't do something requested in a message left at that editor's User Talk page. Sometimes the response is in good faith, sometimes not. It's especially difficult and frustrating to deal with an editor who habitually ignores User Talk messages and keeps on doing whatever it is that appears disruptive. Often the only thing that can be done is to bring it to the attention of admins (probably at WP:ANI) and the only tool admins have in this situation is a block, with a requirement for that editor to be unblocked to acknowledge the message.

Some editors state that the big orange "You have new messages" bar isn't visible enough in the first place, and with the latest changes coming with Echo (the new notifications system) the orange bar itself might be going away (it's already gone as of the writing of this proposal).

This proposal intends to provide admins with a new tool to require the attention of an uncommunicative editor before that editor may resume editing, and would not require a block:

  • Add a new technical capability for admins to leave "Acknowledgement required" messages.
  • The editor would not be able to proceed with any editing capabilities without being shown the message and clicking on "I acknowledge receipt of this message". There may be an explanatory note stating that it is not necessary that the editor agree with the content of the message, just that it was acknowledged as received.
  • There will be a user log record for the editor of having done so when acknowledged. This audit trail would increase accountability, would increase the likelihood that the editor would actually change their behavior, and would be useful in providing a history in support of further remedial action if not.

Note - although this proposal was prompted by a discussion over Echo's removal of the orange bar, it is not dependent on it: if the orange bar comes back, this proposal still stands.

Input appreciated... Zad68 15:32, 1 May 2013 (UTC)[reply]

  • Support There have been times when I've been forced to block an uncommunicative user just to get their attention, which is a bit fly/sledgehammerish. I think there will have to be some form of guidance on when and how to use it (it could be abused fairly easily), but there are situations where it would be valuable. Acroterion (talk) 15:43, 1 May 2013 (UTC)[reply]
  • Good idea, with the caveat that any prevention of editing due to a new "acknowledgement required" message should ensure that the user doesn't lose what they were working on. Probably in practice this would be similar to what happens now when a page becomes protected whilst someone is trying to edit it (which I've never seen but assume is handled sanely...). The problem though would be implementation - probably it would end up being something to do with Blocking, but with special blocks, logged separately, where the user can unblock themselves after being shown the message. Rd232 talk 15:46, 1 May 2013 (UTC)[reply]
    • Problem: as with the #.22You_have_new_messages.22_alert_for_not_registered_visitors_to_expire_after_30_days issue, such messages directed at IPs might require someone other than the intended recipient to acknowledge receipt. Rd232 talk 15:54, 1 May 2013 (UTC)[reply]
      • ...yet still an improvement over how the same situation would have to be handled today. Right now, if you have diruptive editor "D" using dynamic IP 1.2.3.4 to make problematic changes that aren't quite vandalism to article X, an admin would have to block that IP for a certain amount of time. If during that time of being blocked, IP 1.2.3.4 gets reassigned to potentially productive editor "P", that new editor is stuck and can't edit.

        With acknowledgement required messages ("ARM") in place, edits through that IP can be initially stopped without a block. If editor D is still at that IP, D is required to acknowledge receipt of the message, and if D continues at it, the IP can be blocked with good justification. If D goes away and the dynamic IP gets reassigned to P, editor P at least has the opportunity to acknowledge the (irrelevant) ARM, and then can go to productive editing on article Y. We can put a note in with messages for IPs like "If this message doesn't seem relevant to you, please disregard" or an explanation along the lines of what we have in {{Anonblock}} or {{Mobile IP}}. The bottom line is if a strongly-worded ARM* is acknowledged and yet the bad behavior continues, then a block would be justified.

        *I can already see the shortcut WP:STRONGARM being created to point the documentation for this new feature, and used in conversation like, "That editor won't stop making those changes without consensus, and won't respond to requests to stop and discuss it? Better WP:STRONGARM that editor into getting the message..." Zad68 17:28, 1 May 2013 (UTC)[reply]

      • Adding: Rd232, if as you suggested the implementation is done with special blocks, that would actually tie in nicely with this feature: The ARMs could be "indef", meaning there is no expiration on the amount of time editing is disabled until the message is acknowledged, or they could be given expiration times. Zad68 17:58, 1 May 2013 (UTC)[reply]
  • Support - This is a great idea. Mlpearc (powwow) 15:47, 1 May 2013 (UTC)[reply]
  • Support Great idea; can't see any substantial drawbacks. Nyttend (talk) 17:27, 1 May 2013 (UTC)[reply]
  • comment: Wikipedia:Notifications was just added. --  Gadget850 talk 17:38, 1 May 2013 (UTC)[reply]
  • Strong support, in fact I urged Zad to take it here, when he floated the idea in passing in the Echo discussion on AN. My thinking is that it probably wouldn't be used very often, but would be extremely helpful for instance in cases of not-listening edit-warring SPAs (who are not necessarily always IPs); very good for everybody involved, as the editor may never have found their talkpage, and be blissfully unaware that edit warring and name-calling are offenses — until they're blocked for them. Why don't we already have this very convenient feature? I hope it's technically feasible. Bishonen | talk 19:32, 1 May 2013 (UTC).[reply]
  • Support. Thinking out loud here, the only possibility of any abuse would be an admin (or group of admins) constantly re-messaging the user as soon as they confirm receipt, which wouldn't be any different from the possibility of abuse via an indef, no-talk block (except harder to accomplish). Ignatzmice•talk 21:38, 1 May 2013 (UTC)[reply]
  • Support as yet another great idea. Theopolisme (talk) 22:22, 1 May 2013 (UTC)[reply]
  • Seems pointless to oppose this the way it's going. Plus, several people above me are almost always right about things, and I'm surprised to disagree with so many of them. And I seriously doubt it is easy, technically, anyway, so it will probably never happen. But... I really don't like this idea. It makes my skin crawl. It's going to start out with the best of intentions and "limited use", but I guarantee it is going to quickly degenerate into "all admin communication must always be acknowledged by the peons". Either that, or a 15-page manual for when it is appropriate to use, and a separate log, and arguments about whether it was appropriate or not, and lost edits when they try to save a page with a pending "respect mah authoritah" message... same old same old, but with another layer on top. If you give someone a final warning, and they ignore it, block them. If they claim not to have seen the final warning in an unblock request, then unblock, and it worked. I've blocked several editors before for not responding to talk page messages, and almost always that was all that was needed to get them to realize the error of their ways and start responding. This would theoretically solve an actual small problem, but at a big risk of creating a bigger one. --Floquenbeam (talk) 22:40, 1 May 2013 (UTC)[reply]
    • But you speak lightly of blocks there, Floq. "I've blocked several editors … and almost always that was all that was needed to get them to realize the error of their ways." — All? I think it's important to avoid any blocks that can be avoided. Blocks hurt. A block log is not a good start here. Go see the headmaster. P.S. But I do see the problem. We should perhaps have a trial period, with complementary coming-down like a ton of bricks on any admins that overuse the feature. Bishonen | talk 23:01, 1 May 2013 (UTC).[reply]
      • A block should be expected if lots of messages are being ignored. My position is complicated by this new notification thing - in the old days you couldn't plausibly claim that you didn't know you had messages - but I expect they'll fix that. if I had some assurance that this would only be used in lieu of a block, I'd support it. But it won't, it will be used more and more by admins to make mere mortals acknowledge that they've been put in their place. I can feel the truth of this in my bones, although I obviously can't prove it. --Floquenbeam (talk) 23:50, 1 May 2013 (UTC)[reply]
        • acknowledge that they've been put in their place - you make it sound like recipients would need to write out in their own words what they think the message means and how it applies to their behaviour, and then have that acknowledgement approved by the admin before they're unblocked. Ironically, that's a closer description of the status quo than the proposal! The proposal would see messages "acknowledged" by merely clicking a button (something like "yes, I've read this", presumably). Rd232 talk 23:59, 1 May 2013 (UTC)[reply]
    • "all admin communication must always be acknowledged by the peons". - language aside, let's look at that worst case scenario. Let's say, to make it practical, that every standard warning message issued by an admin needs an "I read this" click action, without which the user can't edit. Is that really so terrible? As long as "you can't save because you need to read this message" actions are handled well, I don't think it would. Remember this is far into the future in terms of ever happening - years. So it would be part of the new Echo notification system, which means you can imagine a flyout over your Save Page form, "read this message, then click OK, then you can Save". Having said all that, if Floquenbeam's concerns are widely shared, then much the same could be achieved by allowing admins to send those intrusive "you should read this" flyouts, without any logging or blocking of Save. Rd232 talk 23:17, 1 May 2013 (UTC)[reply]
      • Yes, I think it would be a horrible thing if all admin messages had to be acknowledged by mere mortals. Admins already have heads that are way too big. I assume you wouldn't support everyone having this ability, just admins. --Floquenbeam (talk) 23:50, 1 May 2013 (UTC)[reply]
        • When the acknowledgement is really easy, I don't see why it's that terrible that we shouldn't even introduce the feature in case that's how the community ends up using it (which is what you seem to be saying). As for admin-only: probably (for simplicity), though in principle it could be extended to other sufficiently trusted users, perhaps as a new (and therefore revokable) user-right. Rd232 talk 23:55, 1 May 2013 (UTC)[reply]
    • Floquenbeam, keep in mind that any admin tool could be abused, so that criticism would apply equally to blocks or deleting pages. We trust the community to give the tools to those who can be trusted to use them responsibly, right? In the case where this tool is used, you're probably avoiding handing out a block. And given what this tool will most likely be used for, whatever edit was in progress and failed when the tool is enabled was probably one of the troublesome edits that caused this tool to be used in the first place. Zad68 23:39, 1 May 2013 (UTC)[reply]
      • Yes, but abusing this tool would be so much easier, and so much easier to brush off as harmless. If I want to do something to piss off an IP editor, and so I block them for no reason, I'll be given a good thrashing at ANI. If I leave a message that requires them to ackowledge it, I can put on my puppy dog face and say "well geez, it was just a message." --Floquenbeam (talk) 23:50, 1 May 2013 (UTC)[reply]
        • So make it applicable only to standard warning notices. You can already abuse those (with admin heft behind you), and having to click "yes I've read this" doesn't really change that. Rd232 talk 00:01, 2 May 2013 (UTC)[reply]
  • Cautious Support In general, I think this is a great idea. However, it hasn't taken long to point out some potential pitfalls. IPs are an issue. Rd232 points out a concern about edits in progress. So whatever it done should be trailed and tested before fully implemented, but worth pursuing.SPhilbrick(Talk) 22:41, 1 May 2013 (UTC)[reply]
  • Neutral leaning oppose Floq's concerns scare the heck out of me. In addition, I imagine this being thrown around a lot more blocks to get peoples' attention. The big problem with this is the conflict that will occur when editors receive an acknowledgement required while they are in the middle of a large edit. Ryan Vesey 22:46, 1 May 2013 (UTC)[reply]
  • Support - Brilliant idea! →Davey2010→→Talk to me!→ 23:07, 1 May 2013 (UTC)[reply]
  • Support - Though I'd also say that Admins need to be able to force previously dropped notices by users (i.e. DS or GS notices) to be acknowledged, but that's just me Hasteur (talk) 23:52, 1 May 2013 (UTC)[reply]
  • Cautious support - I think this is a good idea for dealing with vandalism and other problems, but I'm worried of the possibility of overuse. There should definitely be a policy governing its use. Also, it should be possible to set expiry times on the message, for example when giving it to IPs. Actually, given this proposal I think the "You have new messages" expiry proposal given above is no longer necessary. Admins should use discretion for the expiry time, defaulting to something like 24 hours but varying it based on how dynamic the IP is and past history of disruption. The expiry should almost never exceed 30 days, just like it is technically possible to block an IP indefinitely but it is highly frowned upon. It should also be possible for an admin to remove an acknowledgement requirement from a user. -- King of ♥ ♦ ♣ ♠ 00:03, 2 May 2013 (UTC)[reply]
  • Conditional support—this proposition has merit. However, I agree with Floq about the potential for abuse. I would be in favor of such a right only if it could be given in conjunction with a level 4 uw, and made automatic. I think that would remove the danger for undue pestilence, as it would only be used in situations that would call for it, while keeping in the spirit of the proposal, for increasing user accountability and avoiding unnecessary blocks/unblocks. Deadbeef 00:12, 2 May 2013 (UTC)[reply]
  • Oppose. Here's what's gonna happen: a) "I don't have to give a shit about any message unless it's from an admin." b) "Why did you block so-and-so without leaving an ARM first?" Choyoołʼįįhí:Seb az86556 > haneʼ 00:18, 2 May 2013 (UTC)[reply]
  • Support - a brilliant idea, can't believe nobody thought of it before. GiantSnowman 09:59, 2 May 2013 (UTC)[reply]
    Support - This will prevent a lot of blocks, for a variety of reasons. Sounds like Registered mail for admin, and yes, a brilliant idea as it will help to start discussions, particularly with new editors who may be unknowingly coloring outside the lines. I disagree with Seb, although his concern has merit with editors with pre-existing behavior issues. This would mainly be good for newish editors. As for Floq, good points but we admin must police each other's use and have clear rules for its use. Dennis Brown - 2¢ © Join WER 11:16, 2 May 2013 (UTC)[reply]
      • "Admins policing each other" is great in theory, but in practice it simply doesn't happen here. You know that. In one day it has already morphed into a suggestion by at least one admin that it be used for all warning templates issued by admins, which means admins will be even more inclined to communicate via template than via human-speak. That's after one day; I can see where this is headed. Can't you? --Floquenbeam (talk) 12:49, 2 May 2013 (UTC)[reply]
        • Floq, after I saw the last few diffs here I'm getting a better understanding of why you might be making the comments you're making... sorry to see the bloom's really come off the rose for you... Zad68 13:31, 2 May 2013 (UTC)[reply]
      • (*I dunno Floq, you make a good point that many might take the easy way out, even if I would like to think they wouldn't. I seldom use templates myself excepting very mundane things like CSD, AFD, but I'm probably in the minority. I have to admit I would like the ability to get a confirmation and would use the code buried in my own handwritten notes, but not everyone like to hand write those kinds of notifications I've found, so it might end up making it even less personal. I dunno. Withdrawing my !vote for now. Dennis Brown - 2¢ © Join WER 03:02, 3 May 2013 (UTC)[reply]
  • Oppose after discussion above and thinking about it longer. It would be handy, but it would also be very easy to misuse. Dennis Brown - 2¢ © Join WER 20:59, 4 May 2013 (UTC)[reply]
  • Weak oppose There is already a feeling of "us" and "them" around concerning "mere" users" and admins, and this will only widen this perceived gap, in the long run. Lectonar (talk) 12:59, 2 May 2013 (UTC)[reply]
  • Comment This discussion is really interesting... It's like someone offered, "Here are some sticks!" and the responses are ranging from "Great, we can use them to knock apples down from trees and burn them in fires to keep warm," to "Terrible, all that's going to happen is we're going to use them to beat each other up." Both could be true, but I'm not sure it's the fault of the sticks... Zad68 13:05, 2 May 2013 (UTC)[reply]
    (edit conflict) No, it never is...the problem is the, let us say ingenuity, of some people to come up with fabulous new uses for seemingly harmless things (be they sticks, or a new tool to used to drive someone up the wall in the most inconvenient moment.....by forcing him to acknowledge to have read a message, by an admin to boot). Lectonar (talk) 13:16, 2 May 2013 (UTC)[reply]
    Nicely put. Rd232 talk 13:54, 2 May 2013 (UTC)[reply]
    I disagree; like nearly all Internet analogies, this one doesn't even begin to address the nuances of the issue. It doesn't address the fact that the sticks can only be held by some people, and that the sticks also have the magic power of preventing others from doing work, etc., etc. I think there's a reason why we don't see a lot of analogies in policy discussions here. Regards, Orange Suede Sofa (talk) 16:10, 2 May 2013 (UTC)[reply]
    Analogies often turn out to have pitfalls, yes. But... the sticks can be held by anyone in principle; that we don't want to hand them out to everyone is a reasonable choice, but not intrinsic to the stick. And the sticks don't have the power of preventing other from doing work exactly, only to cause a slight delay. Rd232 talk 16:31, 2 May 2013 (UTC)[reply]
  • Strong Oppose per WP:BURO. It's another waste of time, and it's easy to abuse (think Wall of Text). It's nobody's business if and when I read messages. If someone systematically ignores important messages for whatever reason, they can already be dealt with under WP:COMPETENCE, not to mention WP:IAR. --Stephan Schulz (talk) 13:14, 2 May 2013 (UTC)[reply]
    • It's not necessarily easy to abuse - at this point both the capabilities of the putative system and the policy for when and how to use the tool are completely unknown. As to "waste of time" - I don't think most people regularly dealing with IPs and new users would think so. However that's probably a fair description of this discussion; we might as well file a bug now, put it on WP:MediaWiki enhancement requests (re-examine status in 2020) and get back to other things for another 7 years. Rd232 talk 13:54, 2 May 2013 (UTC)[reply]
  • Oppose. I find Seb az86556's argument extremely compelling. In particular, I'm concerned that this would lead to a perception that ordinary talk page messages (including all messages sent by non-administrators) are insignificant and may be ignored without consequence.
    As a possible alternative, perhaps it would be feasible to create a feature enabling admins to tag an existing talk page section (written by anyone) in this manner. Hopefully, that would convey "you need to acknowledge this message from the community" instead of "here's a special message from an administrator". —David Levy 15:08, 2 May 2013 (UTC)[reply]
  • Oppose. I sympathize with the idea that we want to reduce the number of blocks, but it's not clear to me that this proposal will actually achieve that goal without introducing additional drama and confusion. The only thing a button click indicates is that a button has been clicked. It does not show that the editor has understood or even actually read the message; research in software interaction design has demonstrated that quite amply ([3], [4], just to get started). The only way we can be sure that an editor has gotten the point (or not) is to examine their actual behavior on-wiki. Regards, Orange Suede Sofa (talk) 15:57, 2 May 2013 (UTC)[reply]
    That's a good point, but even if we don't know if the editor has understood or read the message, we at least know that they've been confronted with the fact that there is one. Rd232 talk 16:31, 2 May 2013 (UTC)[reply]
    I guess what I don't understand then is how that is helpful in making a block/no block decision. If an admin issues a user a final warning, whether that be a standard lvl4 warning or a hand-crafted one, and then the editor engages in the same action once more, then that warrants a block, right? Would knowing that the user clicked on a button change that decision? If they read it or not, they are continuing their behavior, and per the principle of "blocking is preventative", a block would be justified whether or not the user actually read and understood the message. Regards, Orange Suede Sofa (talk) 18:59, 2 May 2013 (UTC)[reply]
    The situation does arise where there's an editor making problematic edits and it's not really clear whether they're receiving the messages intended for them. With this tool, it would remove all doubt as to whether the editor saw the message, and if the behavior continues, the subsequent block would be well-justified, and better justified than the block in the situation you're describing. Take a look at the response from, for example, Acroterion, Bishonen and Dennis Brown above - they're indicating that, based on their own experiences as admins, they could see a use for this tool to possibly avoid a block just like the one you're talking about. Avoiding blocks and getting the needed behavior change are good, right? Zad68 19:09, 2 May 2013 (UTC)[reply]
    Yes, of course blocks should be avoided. And I read Bishonen's and Dennis Brown's supports. What they seem to to be saying (and hopefully they will correct me if I'm wrong) is that the benefit of this proposal is that it creates one last step before blocking where we do our level best to communicate with the editor before blocking. But then I'm seeing supports with comments like "removes plausible deniability" and I just don't see how anything that happens after the message is displayed (besides the editor's concrete on-wiki actions, of course) would have any impact on anything.
    Maybe the best way for me to put it is that I agree with the goal of block reduction, but I'm just not sure if this is the right way to do it, given the potential for additional drama and complexity. Regards, Orange Suede Sofa (talk) 19:44, 2 May 2013 (UTC)[reply]
    I understand your viewpoint... thanks for your considered response. Zad68 20:14, 2 May 2013 (UTC)[reply]
  • Comment I think it would really hamstring the usefulness of this tool to make it allowed only for template messages. The point would be to make sure that a message explaining exactly what the issue is and why it needs to stop right now could be delivered to the editor, and the template messages are a very limited palette. Zad68 19:13, 2 May 2013 (UTC)[reply]
  • Support However, in addition to adding it as an administrator privilege, it should be offered as a standalone feature, much like rollback, for users who fight vandalism and are perennially bugged by this problem. TheOneSean | Talk to me 00:05, 3 May 2013 (UTC)[reply]
  • Comment: The recent move to Facebook-style notifications rather than the "You have new messages" bar has made it even harder for newbies to notice that they have new messages, especially if they've never used Facebook. If they see a giant orange "You have new message," it's entirely unambiguous that they have a new message to read. Now it's just a tiny red number in the upper right. Vandalism, fine, blocking without them seeing a warning is tolerable, because it's bad and they know it. But 3RR? That's like arresting someone for an arcane law that no reasonable person would expect to know. We cannot block someone for 3RR unless we make every effort to make them aware of it, and at a minimum it includes displaying a prominent orange bar but ideally stops whatever they're doing and makes them acknowledge the policy. -- King of ♥ ♦ ♣ ♠ 02:32, 3 May 2013 (UTC)[reply]
    • Maybe so, but just because someone decided to get rid of the orange bar doesn't mean that from now on we can all ignore each other unless an admin tells us to do so. Choyoołʼįįhí:Seb az86556 > haneʼ 02:41, 3 May 2013 (UTC)[reply]
      • I'm not talking about established users. In my opinion this should only be used for the newest of users, just to make sure they actually realize there's a message for them. -- King of ♥ ♦ ♣ ♠ 03:06, 3 May 2013 (UTC)[reply]
        • You been here since when? When there is the possibly to game the system, people will game it. Just like people now come up with "Wasn't given 4 warnings, is therefore allowed to continue until after warning #4" (we even have a template for that!), people will go "Didn't receive ARM or hasn't acknowledged it, therefore cannot be blocked until notice is received.". When blocked anyways, admins will be dragged to ANI with the requirement to explain why they had the audacity to block without prior ARM. Non-admins will eventually be told that warnings left by them are without teeth and therefore without merit and thus shouldn't be given at all. We will then need the Wikipedia:Administrators' Noticeboard for ARM to be given where people ping admins to give such a warning before one is allowed to report at WP:ARV. Choyoołʼįįhí:Seb az86556 > haneʼ 03:19, 3 May 2013 (UTC)[reply]
  • Oppose per Choyoołʼįįhí:Seb az86556. He hits the nail on the head: the problem of unintended consequences here. The issue is not the potential for abuse by admins (since this is essentially "block lite" there's nothing an admin could do here that they couldn't do with a block) but with the potential for gaming the system and wikilawyering over admins that don't use this option should it be implemented. No, this is entirely unnecessary. --Jayron32 03:52, 3 May 2013 (UTC)[reply]
  • I'm really torn here. The utility of such an ability is hard to ignore, and in point of fact we already do something not unlike this when we tell users "do that again and you will be blocked" and the sudden absence of the hard-to-say-yu-never-saw-it-orange-bar-of-doom certainly helps make the case for it. However, the potential for abuse seems high, and the potential for claims of abuse higher still. I don't happen to agree with it, but many users treat WP:TEMPLAR as if it were actual policy, so its easy to imagine how infuriated they would be when presented with a template that they must acknowledge reading lest they be blocked. I'd rather just see the orange bar come back and be an "opt-out" only feature. (and as for the idea presented above that "trusted non-admins" be able to do this, hell no. Blocking, which this is essentially a form of, is not an admin tool we should unbundle, as the community has made clear in many previous discussions) Beeblebrox (talk) 03:53, 3 May 2013 (UTC)[reply]
  • Support if the orange bar goes away. If that happens, then blocking may have to be used more frequently, which isn't desirable. Certainly only for Admins. Using it for IPs is obviously problematic and there need to be guidelines on this, perhaps some form of time limit. Having said this, Seb's points need to be considered. We could have guidelines that clearly restrict it's use. Any editor that has had x warning on their talk page and has never participated in talk page discussions? Dougweller (talk) 05:04, 3 May 2013 (UTC)[reply]
  • Oppose Reminds me of all those user agreements on websites that we are forced to click on that I never read. If an editor really was unresponsive, I believe they should usually be blocked and their unblock request would need to demonstrate that they understand the problem. I've honestly yet to encounter a situation where an editor used the "never got the message" alibi.—Bagumba (talk) 07:31, 3 May 2013 (UTC)[reply]
  • Very tentative support In principle, a good idea; in practice, may cause more issues than it solves. I'd like to see a draft of the proposed usage policy/guideline before committing anything more than token support. Something like this would need very clear guidelines on when it could and couldn't be used, and they should be pretty restrictive. Yunshui 雲‍水 07:59, 3 May 2013 (UTC)[reply]
  • Support. Can't hurt to have the tool in the box. bd2412 T 04:13, 4 May 2013 (UTC)[reply]
  • Translation Yes, there are certain users that are hard of hearing and sometimes admins have to use the block button to get their attention. It would be nice to have an alternative to blocking. But allow me to translate this in to how this proposal would be perceived by some people.

    Fear me for I am GOD
    Thou shalt not be allowed to edit until
    a) You acknowledga that I am your superior, and
    b) I have issued a commandment for you to obey
    Click the button below to agree. Have a nice day and thanks for volunteering at Wikipedia. —signed GOD.

    This is how some fraction of non-admins will view it. This is also how some small fraction of admins will use it. It's a good idea in theory, but in practice it will be far different. I'm sure people can imagine how this would have worked during the civility case at ArbCom. 64.40.54.55 (talk) 01:14, 5 May 2013 (UTC)[reply]
  • Strong Oppose This is basically blocking someone for not reading their messages. Wikipedia is not a democracy, but it's definitely not a totalitarianism either. This is just a very silly reason to block (block = remove editing capabilities) someone. Feedback ☎ 16:05, 5 May 2013 (UTC)[reply]
  • Undecided: It's a slippery slope. If it is allowed, it should only ever be applied in cases that would warrant a block, but where an Admin wants to try to work things out before going to that extreme. It should not be used because of Admin "frustration". Misuse should be sufficient grounds for removal of Admin privileges. Praemonitus (talk) 19:45, 5 May 2013 (UTC)[reply]
  • Oppose. Administrators should have fewer capabilities, not more. Malleus Fatuorum 20:00, 5 May 2013 (UTC)[reply]
  • Oppose This is weird. It seems like a block without a block ("I didn't do anything wrong, I didn't even block 'em!") and seems too easy to be abused. Seb's got it down pat. We don't need to give sysops a shady way to control editor's behavior. ~ Amory (u • t • c) 23:25, 5 May 2013 (UTC)[reply]
  • Oppose. Great idea, and I would have supported if I'd participated before 00:18, 2 May 2013 (UTC), but Seb's comment about unintended consequences trumps all the benefits. Yes, this would help in some ways, but it would have the potential for leading drama and other chaos that can't currently happen (or can't happen to the current extent) right now. Nyttend (talk) 05:15, 6 May 2013 (UTC)[reply]
  • Support. We should pile and pile more and more capabilities on administrators until they crash Wikipedia into the ground, and we can start afresh with a decent admin system. --Epipelagic (talk) 06:32, 6 May 2013 (UTC)[reply]
  • I can't believe I'm actually reading this oppose: Blocking someone until they click a button? This is what is being proposed here. It is nothing less than blocking. Blocking someone because you want to get their attention is...well, it's borderline at the best of times. I am ashamed to see so many administrators actually pretending that this is not blocking someone. Risker (talk) 22:48, 6 May 2013 (UTC)[reply]

Certain categories with pictures

Take this (for example): http://en.wikipedia.org/wiki/Category:World_War_II_tank_destroyers_of_Germany

It would be nice to have a small picture of each specific 'vehicle' there, a small picture, so you could then jump right to the most interesting looking vehicle (for instance), to read about. Just an idea. Makes for faster absorption of information in going through categories. You can determine more quickly from an image than from a category title, what you may want to read about (in cherrypicking, reading for entertainment). Just a suggestion. 86.145.5.117 (talk) 06:57, 2 May 2013 (UTC)[reply]

Keyword screener for recent changes

I just recently started screening for vandalism, and I thought, "Hey, what if a bold red P came up at the end of each change which contained any sort of profane language. That could be a really neat tip for vandalism patrollers." Not all, but a lot of vandalism is simply mindless profanity scrawled across Wikipedia for novelty value. This, while not blocking profane edits (obviously, profanity could be perfectly appropriate in some situations), would provide a marked for potential vandalism and would increase the effectiveness of the humans involved in vandalism patrol. Thank you. TheOneSean | Talk to me 00:00, 3 May 2013 (UTC)[reply]

Updated maps of US cities for 2010 census

Articles on many US cities, towns, and census-designated places, especially on the west side of the country, such as that on Republic, Washington, include maps such as this one, which were created by Shereth in 2007. These maps are now outdated, since the 2010 census added many new census-designated places (such as Curlew, Washington, previously with an article as an unincorporated community), as well as changes to geographic boundaries of communities.

I commented to Shereth about this in August, a couple months before he announced his retirement, asking whether plans existed to update the maps with 2010 census data. I have since become familiar with GIS and the census's shapefile sources, and am considering undergoing this myself. This would entail not only creating the maps, but implementing a bot (I'm fairly familiar with the bot creation and approval process) to update images in the articles, as well as create template-based articles on new CDPs without articles and update outdated sentences on those with articles ("...is an unincorporated community" -> "...is a census-designated place"). I would need to further research templates such as this one, to see if I could convince the bot to perform such tasks as moving the link to Malo in that template to the CDPs section.

Would any other Wikipedians appreciate this? I've posted a link here to WikiProject Maps, as well.  — TORTOISEWRATH 01:18, 3 May 2013 (UTC)[reply]

To illustrate what I mean, I've created a mockup of what the final maps would look like. Obviously, they will be vector and not raster, and be created and uploaded with a script, rather than me spending 27 years making them myself.
  • 2000 data
    2000 data
  • 2010 data
    2010 data
Note the plate carrée projection on my map. I didn't bother to check what projection Shereth used, and am open to suggestions for projection. Plate carrée is, of course, easiest to implement, and would reduce the size of SVG files (for instance, boundaries along particular parallels/meridians could be losslessly encoded as horizontal or vertical pen movements, rather than absolute polygonal points. </nerd>
Also check the map file on Commons; I've annotated my map with notes on the changes that would be made from the 2007 maps.  — TORTOISEWRATH 01:05, 4 May 2013 (UTC)[reply]
Appreciation to the above editor for suggesting these changes, although I really don't see how the 2010 census data affects a city or county map, which is governed by state law and not by the census. (I don't see the difference in the Ferry County maps, for example, except one makes the county look skinnier than the other.) My caveat is that one size may not fit all uses, and I hope TortoiseWrath will elucidate on his or her proposal. Why should this be done, in other words? GeorgeLouis (talk) 03:44, 4 May 2013 (UTC)[reply]
The US census, in addition to recognizing incorporated cities, towns, and villages, defines census-designated places to (from that article) "provide data for settled concentrations of population that are identifiable by name but are not legally incorporated under the laws of the state in which they are located." In the above maps, the 2010 data added 13 CDPs to the county, making the older one (with CDPs from 2000) outdated.
In addition, in the last thirteen years, many cities/towns/villages/CDPs (such as Everett, Washington, off the top of my head) have annexed new land or had otherwise had their boundaries changed, thus making the older maps not only outdated but inaccurate.  — TORTOISEWRATH 04:01, 4 May 2013 (UTC)[reply]
To clarify: these problems affect the entire United States, especially rural areas, not just the state of Washington; I'm just using places in WA as examples because they're those with which I'm familiar.  — TORTOISEWRATH 04:03, 4 May 2013 (UTC)[reply]
  • Yes please, please, please. Outdated data is the scourge of all our place-related articles. Please do. Red Slash 16:05, 4 May 2013 (UTC)[reply]
    • I wouldn't normally have put this through the proposal process, because of that, were it not for that this could affect tens of thousands of articles. I'm glad to see someone thinks like I do.  — TORTOISEWRATH 16:58, 4 May 2013 (UTC)[reply]
      • Because I have a generally good feeling about this, I'm going to start work on the bot to create and upload images to Commons; once I figure out which projection to use (it looks like WP:MAPS recommends equirectangular for most maps of this type, which is awesome), there won't be many more changes needed to the maps should they be implemented.  — TORTOISEWRATH 17:55, 4 May 2013 (UTC)[reply]
  • Comment - Shereth, the author of the original maps, has expressed interest in doing this, which is great. He is also proposing the implementation of this WikiProject Maps-compliant color scheme. Which scheme do you all prefer; the compliant one or the old one that I've used above?  — TORTOISEWRATH 16:55, 5 May 2013 (UTC)[reply]
  • Definitely support. We need to continue using the ones currently in use until something better appears, and this is definitely better, as long as you can get the proportions right. I'd suggest that you omit the bodies of water, since those make it harder to tell where the boundaries are; the point of these maps seems to be showing the boundaries (as exact as you can be at this scale) of the municipalities and CDPs, and we need maps that can do that. The current scheme is a good deal better, because the other one clogs it up with lots of other elements, like major roads. Such a map is helpful, of course, but that's why we have a map1 parameter: the primary map needs to be one that shows just the location of the city and its boundaries, and a secondary one can be created to show rivers, highways, things in other counties, etc. Nyttend (talk) 05:10, 6 May 2013 (UTC)[reply]
    • I completely agree with you. I think I've found a way to get the proportions to where they feel correct, and I've been talking to Shereth about who will perform the actual implementation (we both want to do it). In regards to water bodies, though, I added them to assist in presentation of places like Michigan; I'll experiment with ways to omit them, as they result in unnecessary complication and embarrassingly large SVG filesizes (5MB+ in some cases).  — TORTOISEWRATH 00:45, 7 May 2013 (UTC)[reply]
  • Definite yes to updating maps for those places that have changed, though for the many entities that did not have any boundary changes it may not be necessary. With regards to textual updates, I'd suggest some care is needed. A CDP is for the most part an unknown designation other than among census wonks. For the most part, if these places were previously unincorporated communities, then they should remain described as unicorporated communities, regardless of whether the Census Bureau decides to compile statistical data for them as a CDP. This might mean adding text about the CDP status (and when defined) rather than replacing existing text. older ≠ wiser 00:57, 7 May 2013 (UTC)[reply]

Universal disambiguation parameter needed for templates.

Too many times I have come across a disambiguation link generated by a highly complex and multi-layered template which either has no mechanism built in for calling the correct target page instead of a disambiguation page, or has some strange and unintuitive parameter that must be inserted in some strange and unintuitive place to correct the link. I propose that we have a simple, common sense universal rule that wherever any template calls a link, it must be structured so that it is possible to add a disambiguation parameter by adding |dab=(foo disambiguator) after the location of the term which will appear in the link. bd2412 T 04:18, 4 May 2013 (UTC)[reply]

I can't say I know what you're on about. An example of a template that does something like this would help muchly. Rd232 talk 21:29, 4 May 2013 (UTC)[reply]
I can give you a perfect example. Daxuecheng Station was recently changed from a regular article to a disambiguation page, with the original page being moved to Daxuecheng Station (Chongqing). Since the original link appeared in a template, showing up on pages like Eling Station, I tried to fix the link in this template:

Village pump
General information
Line(s)Line 1
Services
Preceding station   Chongqing Rail Transit   Following station
Template:CRT lines
As you can see, Daxuecheng Station shows up in the template, but oddly not in the formatting, which looks like this: {{s-line|system=CRT|line=1|previous=Lianglukou|next=Daping}} Furthermore, because of the way the template operates, there is no link to the page needing to be changed from Daxuecheng Station's "what links here page". I therefore subst'ed the template, and then subst'ed all of the subsequent sub-templates on the page just to find the one that references Daxuecheng Station: Template:S-line/CRT right/1. I tried to fix the problem there, but nothing worked without breaking the template. I sought help, and eventually an editor familiar with these templates made the correct change - to Template:CRT stations (which previously had not mentioned Daxuecheng Station at all, but needed to have a line added to disambiguate this term. I understand that these templates are highly functional, but we have enough problems fixing disambiguate links without having templates that call links without offering a straightforward and intuitive method of fixing disambiguation links. I have had the same problem on many occasions with templates designed to call all of subject "foo" for a particular region, like Template:European topic, for which a parameter can be added to invoke, for example, "Transportation in" a list of all European countries, without offering an easy opportunity to fix an ambiguous link for a particular country. bd2412 T 00:22, 5 May 2013 (UTC)[reply]
I see, thanks. Yes, that's really troublesome. (Though the "European topic" type templates shouldn't really need disambiguating?) Rd232 talk 11:44, 5 May 2013 (UTC)[reply]
I once had exactly this problem with the Template:Oceania topic template, when editors used it to create a "Football in" series of templates. "Football" has multiple meanings depending on where you are, so some of the links generated were to disambiguation pages. bd2412 T 21:30, 5 May 2013 (UTC)[reply]
Ah. Aha. Rd232 talk 23:35, 8 May 2013 (UTC)[reply]
If we do something like this then we should allow any link target. It would be crazy to go through the trouble of editing a large number of templates and then only have the capability to pipe to a title which starts with the text you want to display. And many templates make links from multiple parameters so we would also need a universal naming system to deal with that. If X is the name of a parameter then X-link could be the name of an optional parameter saying to generate [[X-link|X]] instead of [[X]]. There is a hack which sometimes works now. If a template says [[{{{name}}}]] then name=X-link{{!}}X will use Template:! to produce [[X-link|X]]. PrimeHunter (talk) 12:53, 5 May 2013 (UTC)[reply]
I am rethinking this in light of the complexity of some templates already well established and long in use. At the very least, every such template should provide an easy way to find the location where the fix needs to be made, and should provide very clear instructions on what edit must be made to fix that link. bd2412 T 21:30, 5 May 2013 (UTC)[reply]
I wonder if some move to Lua for some of this would be helpful? The complexity of some of these template structures could perhaps be reduced that way. Rd232 talk 23:35, 8 May 2013 (UTC)[reply]

Suggested new user right: "Referee" (or something like that)

Vandalism is still a big issue for us and it takes up admin resources that can be used elsewhere. I think that patrolling AIV and blocking vandals is a "dirty job" for most admins. I therefore propose the creation of a "Referee" user right (a referee in sports makes quick decisions, and makes sure no time is wasted) that can be granted to users in good standing and with experience in fighting vandalism.

The Referee would be able to preemptively block users and IPs for up to 24 hours, as long as a level 3 or 4 warning has been issued previously to the user or IP. They shall then report it to a purpose-created noticeboard if the behavior is recurrent, where an administrator can deal with setting the duration of the user/IP's block.

I believe that this will greatly ease the work load of our administrators. When a user or IP is reported to AIV, it may take up to several hours before the request is seen by an admin and the user can be blocked. The vandal has then often in the meantime left a big mess that has to be reverted and cleaned up. LiquidWater 20:43, 4 May 2013 (UTC)[reply]

  • Support - once a level 4 warning has been issued, blocking should be a given once vandalism continues, no matter who first notices it.  — TORTOISEWRATH 21:17, 4 May 2013 (UTC)[reply]
    • I'm afraid blocking is not that simple. You have to check if the warnings were appropriate, if the edits are actually vandalism and not a good faith editor screwing up, if the behaviour actually does warrant a block, judge if the disruption is likely to continue based on their past editing patterns in case the disruption has already stopped etc etc. A block is never applied just because somebody has been issued a level 4 warning. Chamal T•C 03:22, 5 May 2013 (UTC)[reply]
  • Support, but extend to 31 hours. Blocking admin like that one because they may show up at the same time in school the next day with the 24 hr. block expired.--Canoe1967 (talk) 21:52, 4 May 2013 (UTC)[reply]
  • Oppose. This seems a solution in search of a problem; vandalism has, year on year, been going down. Yes, a lot of admin time is spent handling vandalism - but there's no indication that they'd engage in other activities were they to suddenly find themselves unable to contribute in a major focus area. Unless you can show that there's genuinely a crisis - that stuff is getting missed, or that admins are burning out - I don't see a need for this. Ironholds (talk) 23:00, 4 May 2013 (UTC)[reply]
  • Comment Thanks for offering the suggestion, but most likely this proposal will not pass. Similar proposals have occured every few months for the last 4 or 5 years and have always been rejected. The community is very reluctant to unbundle the block button mostly because if somebody can be trusted with the block button, they can be trusted will all of them. So this would be the same as running for adminship and only using the block button meaning there's no need for a seperate right. 64.40.54.55 (talk) 01:47, 5 May 2013 (UTC)[reply]
  • Comment: This proposal is a complete waste of time and should be closed. Admins never relinquish controls they already have or allow other groups to use them, they only add to them. And this proposal makes the current crazed system even more crazed by allowing yet another group of unsuitable users, such as schoolboys and users with no experience or understanding of content building, to run around blocking the experienced editors. There should be an entirely separate group tasked with the discipline of experienced editors. Experienced editors are not in the same category as vandals. A point which seems to be lost on the mover of this proposal as well as many administrators. --Epipelagic (talk) 23:23, 5 May 2013 (UTC)[reply]
    • Did you read the proposal in its entirety? Nowhere in the above paragraph does LiquidWater propose unbundling the block button for liberal use, nor would the "referee" user right be intended for inexperienced editors. Kurtis (talk) 10:20, 6 May 2013 (UTC)[reply]
  • Oppose per King of Hearts. Besides, reports to AIV that are truly active vandalism rarely take that long. ~ Amory (u • t • c) 23:31, 5 May 2013 (UTC)[reply]
  • In practice, I suspect that this access level would only be granted to editors who have proven highly competent and trustworthy in fighting vandalism (ie. knowing exactly what vandalism is), so I doubt there would be a sudden dramatic increase in unjustified blocks of well-intentioned new contributors. However, I don't really see the point of this user right. There is seldom a particularly pressing need for extra hands at AIV, and blocking petty vandals is generally among the easiest jobs an administrator does (assuming that the user's edits are clearly intended to disrupt the project and they have been given enough warnings already). If someone is trusted enough to have this hypothetical "referee" user right, why not the full sysop package? Oftentimes other features of the administrative toolset are also needed in when dealing with blatant vandalism (ie. deleting pages, viewing deleted pages, deleting revisions, semi-protecting articles, etc). The block button would be limited without them. Kurtis (talk) 10:20, 6 May 2013 (UTC)[reply]
  • Oppose. I have a lot of experience (not recent) at anti vandalism, and can get a trigger finger. We need a third party to look at the issue from a disparate position, rather than someone who is on recent patrol. Things like this need someone who has had there history checked out, rather than an easily obtained user right.Martin451 (talk) 02:13, 7 May 2013 (UTC)[reply]
  • Oppose. From my experience as an editor, such a status would add very little, if the person is that reliable, why not grant him/her full admin status, even if they only use it for blocking vandals - my real problem is dealing with sock-puppets. Martinvl (talk) 06:07, 7 May 2013 (UTC)[reply]
  • Oppose Is AIV that backlogged? --Jayron32 06:34, 7 May 2013 (UTC)[reply]

Wikipedia Editor's Email OR OTRS Reach Out

I regularly send emails to request for permission (generally images). But, my success rate is alarmingly low. So far, I have sent 53 emails, have received only 6 replies and I could collect only 1 image. Someone gave their phone number in reply email and asked to me to call the number, which I did not do. I use the draft email posted at Wikipedia:PERMISSION.

I personally feel, one reason of such low success rate is my Gmail domain's email. In one email, my request was rejected with the comment they would think if they get a request from Wikimedia officials (yes, they don't understand how Wikipedia works, I tried to explain, but, no luck), in another conversation, the requested party was surprised to see my gmail email.

Suggestions
a) Create an email domain like username@wikipedia-editor.org so that the approach becomes more professional. The main domain page may have information on how Wikipedia works, who are Wikipedians etc.
b) Create a separate section in OTRS— "OTRS reach out" which will work on requesting content permission. General editors will request "OTRS reach out" members and they'll attempt to collect permission from third parties.

Feasible? --Tito Dutta (contact) 08:24, 5 May 2013 (UTC)[reply]

I like the editor e-mail idea.
As to the permissions, it also depends upon the type of images you are seeking. Celebrity photos tend to be worth a lot of money, and it is unlikely photographers will give them to you for free. There is a Wikipedia editor, however, who does shoot red carpet shots. I have not dealt with him in years, but I see he is still editing, and when I asked him before he had no trouble getting shots for the articles I was creating. User:David Shankbone
Science pictures are much easier to get. I have never been turned down, except for temporarily. When I am dealing with non-scientist photographers, like National Geographic photographers, however, I also offer the option of submitting a low-resolution version of a good image.
It is cool that you take the time to ask. It's a great way to get images. -68.107.137.178 (talk) 14:42, 5 May 2013 (UTC)[reply]
  • Comment I can't seem to find it, but Ithink the WMF already nixed this idea because of the possibilty of abuse and their legal requirements. In general people are always skeptical about emails from Wikipedians. The best way to handle this is to start a disussion on the approriate page and link to that page in your email. That way the recipient can see there is actually a discussion on Wikipedia about the picture/issue/proposal or whatever. Linking to the related policies, such as WP:PERMISSION, in your email also helps. Contacting the right people can help too. If it's a corporation, contacting their public relations/sales/customer support department is often helpful. This usually changes the 90% failure rate in to a 90% sucess rate. Cheers. 64.40.54.43 (talk) 16:37, 5 May 2013 (UTC)[reply]
  • Discussion in talk page has been tried, does not work. I can find this at this moment. There are 1-2 more. Moreover it makes thing more complex. A good number of people don't understand creative commons, Wiki policies and when you start talking on these in details, they want to leave. Someone told me in an email "You want image, just collect it from internet. I don't mind if someone uses my image for an article on me."! -- Tito Dutta (contact) 05:06, 7 May 2013‎ (UTC) (signed at 16:16, 7 May 2013 (UTC))[reply]
  • Comment / Suggestion Doesn't OTRS have a generic email @wmf.org or something? Couldn't users fill out a form and let an OTRS bot of some kind actually "send" the original email and CC it to the requester? I would think that would alleviate any hesitations of authenticity because it would be from "[email protected]" and it could include a "reply to" link back to the requester so that communications would be initiated from an authentic MW entity, but all communication would be with the individual editor. Technical 13 (talk) 01:00, 6 May 2013 (UTC)[reply]
User:Technical 13, Excellent suggestion! Can it be done? --Tito Dutta (contact) 05:06, 7 May 2013 (UTC)[reply]
I don't ask for OTRS permissions very often, but when I do, I send it directly from the system. This is a great idea, as it will allow people without OTRS accounts to do the same. -- King of ♥ ♦ ♣ ♠ 05:28, 7 May 2013 (UTC)[reply]
Hmm, is letting anyone send an email with WMF-looking authenticity that great an idea? It would need to include some boilerplate "This is NOT an email from the WMF, content not endorsed by us etc. etc." to guard against phishing and maybe other legal issues, kinda nullifying the authenticity Jebus989✰ 18:18, 7 May 2013 (UTC)[reply]
  • Support Technical's idea. I'm uncomfortable with a username@WP address, simply because it would potentially require lots of maintenance for something that's not our core purpose; imagine it becoming someone's primary email address, for example. Conversely, as long as we can figure out how to make it so that you can view emails related to ones that you've sent and not be able to view emails related to ones others have sent, the permissions@WP idea is great; far fewer people would question its origins. I also agree with 64.40's point about on-wiki things; my requests for permissions generally have to do with illustrating US historic sites, and I'll customarily include a link to the unillustrated article with the implication of "just imagine how much nicer this would look if you donated your picture". Nyttend (talk) 12:23, 6 May 2013 (UTC)[reply]
  • I have had reasonable success with: Subject:Wikipedia
Hi Betty, (the PR person)
Vicky doesn’t have a picture for her Wikipedia article. You are very welcome to provide one but we need the permission of the copyright holder which is usually the photographer. They would need to release it under a ‘free license’. See: http://commons.wikimedia.org/wiki/Commons:OTRS for details. If you email one to me with verbal permission of the photographer then I can have it in the article within minutes and we can wait for them to fill the form out and email it to OTRS. They have a large backlog so sending it to me may be the fastest and easiest for you. This should prevent some fool from uploading a lame image that they snapped in a grocery store, etc.
V/r (my real name and phone here)--Canoe1967 (talk) 05:22, 7 May 2013 (UTC)[reply]

Request for comments on the Main Page (2013 main page redesign proposal)

The 2013 main page redesign proposal is a holding a Request for comments on the Main Page, in order to design an alternative main page based on what the community asks for. Please leave feedback regarding any aspects of the Main Page you like or dislike, and discuss the Main Page's purposes and aims.

Evad37 (talk) (on behalf of the 2013 main page redesign proposal team) 00:41, 6 May 2013 (UTC)[reply]

Proposed addition to the toolbox

I'm proposing that we add a new link to the sidebar — "Subpages". This would appear in the toolbox menu on any editor's userpage, project namespace pages, or anywhere else that the subpage policy applies. Right now, the quickest way to access a page's subpages is to click "page information" in the toolbox and follow the link in the bottom of the first table. But unless people have actually read the subpage policy in its entirety, they may not even be aware of this function; until just recently, I looked for subpages by checking an editor's contribution log, scrolling to the bottom, and clicking the relevant link in the footer. I didn't even know there was such a matrix for project namespace subpages (nor any other namespace, for that matter). A "Subpages" link in the toolbox itself would be faster and more accessible, both for new users and experienced editors. It has already been in use over at Wikimedia Commons for roughly six years now, where it's proven itself convenient.

As far as I'm aware, this was proposed only once before, yet received absolutely no attention at the time. Thoughts? Kurtis (talk) 09:59, 6 May 2013 (UTC)[reply]

"Updated since last visit" markers

It has been over a year since watchlist notification was turned on, only to be hidden immediately after. Now that the CSS has long been changed to allow better control over how to show changed watchlist items, I proposed to change the bullets back then, which met no opposition, but I never got around to implement it. So if there are no objection, I can put CSS in place the will replace the standard bullets ( and ) with green bullets ( and ), and re-enable the reset button. — Edokter (talk) — 11:12, 6 May 2013 (UTC)[reply]

Hotcat-like editing of redirects?

Firstly, apologies if this should be at the ideas lab - I'm not entirely clear of the distinction between this page and that one. Also apologies if this idea sounds stupid (it may do :).

Is there any way of making a hotcat-like editing function for pages marked with the #Redirect markup, so that if a target page is moved, it becomes quicker and easier to repoint any redirects, in much the same way that articles can quickly be moved to a renamed category using the ± button? I suspect it's not possible, since the #Redirect lies within the body of the "article" text, but then again, so do the [[Category:Foo]] links... Grutness...wha? 13:08, 7 May 2013 (UTC)[reply]

Maybe I'm not reading this correctly, do you mean to fix double redirects? A bot takes care of those. ~ Amory (u • t • c) 17:10, 7 May 2013 (UTC)[reply]
A bot does them eventually, but surely we're always being told to do the most used ones as soon as the page is moved? Grutness...wha? 00:32, 8 May 2013 (UTC)[reply]
Frankly, I don't bother; the bots have gotten quite speedy (just a few hours). Theopolisme (talk) 10:57, 8 May 2013 (UTC)[reply]
OK - as long as I have your permission not to ;) Yeah, this task is probably quick enough automated not to cause any major problems. Cheers, Grutness...wha? 12:00, 8 May 2013 (UTC)[reply]

Restore preference

Suggesting additional option to "restore preference settings to default by page". Tito Dutta (contact) 16:22, 7 May 2013 (UTC)[reply]

Yes, that would make sense (you mean the tab-like [in Vector and Monobook, anyway]) sub-divisions of Special:Preferences sometimes called pages, I believe). Currently at the bottom of every Special:Preferences tab we have "Restore all default settings". But when fiddling with options you might well want to reset just one preference tab. Rd232 talk 16:52, 7 May 2013 (UTC)[reply]

Wikipedia 2.0

I see that yet another editor has given up (after 31,851 edits). We have seen a large number of editors come and go, and now have a declining number of active editors. While this will clearly level off at some point, and stabilize, it is useful to continue to look for ways to make Wikipedia a more reliable source. A WP:Wikipedia 2.0 would help, a stable version that was professionally created, by real named people who are experts in their field. We could probably even pay them, as I see that WMF has more money than they know what to do with it. Is this a failed project? No. Do editors get burned out and quit? Yes. Apteva (talk) 18:39, 7 May 2013 (UTC)[reply]

Citizendium? There is an issue of maintaing active editors and drawing in new ones, but I don't think forsaking the Wiki(p|m)edia model is a fix. ~ Amory (u • t • c) 18:44, 7 May 2013 (UTC)[reply]
Well that's not going to happen. But we could have a discussion about what Wikipedia might look like in 2020, if it survives til then. Wikipedia's future is too rarely thought about holistically, and such an exercise might be interesting. Rd232 talk 18:49, 7 May 2013 (UTC)[reply]
Just like WP 1.0, 2.0 would be a CD, or DVD, and not something subject to revision. It would just take the best of WP and turn it into something that could be used by us even, as a reliable source. Apteva (talk) 18:52, 7 May 2013 (UTC)[reply]
Actually, a better name for the next CD version would be to use the year it was created, such as WP:Wikipedia 2020. Apteva (talk) 18:58, 7 May 2013 (UTC)[reply]
It's worth taking these meatball:GoodBye statements with a grain of salt. Frequently, if you check back in a couple of weeks, you'll find that the editor has reappeared. WhatamIdoing (talk) 20:48, 7 May 2013 (UTC)[reply]
I often wonder how much real-world work experience some portions of our community have had. The comings and goings of experienced users are no mystery to someone with experience in service or labor workplaces. One day the guy next to you will just realize they don't want to do it anymore and will walk out the door, maybe without saying a word, maybe yelling and screaming, or maybe politely explaining that they just need a change and have are moving on. It happens all the time. For work that is completely voluntary and totally unpaid what is surprising is that there are so many of us that stick around. Realistically, the day will come for almost any user when they just don't want to do this anymore. It doesn't mean there is something fatally wrong with the project, its just simple human nature. Beeblebrox (talk) 21:07, 7 May 2013 (UTC)[reply]
This, x1000. I won't try to elaborate, you summed it up well. –Quiddity (talk) 05:33, 8 May 2013 (UTC)[reply]
That being said, I think a stable version of Wikipedia that contains only subjects of academic interest and is geared toward schools is an excellent idea and have advocated for it before myself. The answer I got was "good idea, go ahead and do it." Obviously I felt that was a rather large task to take on myself but i would be very interested in forming a group to create a fork like that, not on cds but on the internet so it could be updated, just not by anyone who wanted. I imagine something done by using the import tool to transfer over stable versions of good articles on such topics. It would only take a few dozen people to maintain something like that. Beeblebrox (talk) 21:11, 7 May 2013 (UTC)[reply]
All of the "stable release" and "selected release" type projects, are (or should be...) listed somewhere within the pages, at Wikipedia:Version 1.0 Editorial Team, and meta:Static content group.
If any of you want to help re-energize these projects, one good way would be to help track down all the related endeavours that haven't been indexed yet (eg this gadget, which we don't seem to know much about, despite there being a slashdot article about buying up the remainder so that we can send them to kids without internet). This is not a wheel that needs to be re-invented - it's a wheel that has many many children, some of which have been overlooked for too long. Go update the lists of what we've accomplished so far! –Quiddity (talk) 05:33, 8 May 2013 (UTC)[reply]
  • Support Support Support Excellent suggestion! User:WikHead is another editor who has left 100,000+ solid edits. From time to time we all feel frustrated and many of us are still trying to find the answer of the question we sometimes face "What do you get by doing (almost) a full time job in Wikipedia?"
    If they have enough money in hand, they can start an "Editors' grant"! --Tito Dutta (contact)
  • Oppose: An unnecessary division of resources. Suppose you split off the best 10,000 articles into its own wiki? You've now got 10,000 articles that are full of red links and have very little cross-linking. Why would people go there? Praemonitus (talk) 23:15, 8 May 2013 (UTC)[reply]

Developer's Noticeboard

Recent events have highlighted the need for more effective communication between our software developers and the Wikipedia community. When software changes happen without enough input from the community, there are usually problems. When the community reacts against changes because of unforeseen problems, this in turn can alienate the developers from the community and creates a cycle that perpetuates the lack of communication. Right now, announcements and requests for input tend to happen in places other than this wiki. Even when they do not, they are posted to high traffic noticeboards such as the Village Pumps, which are hard for many people to keep up with.

I propose that we create a Developer’s Noticeboard on Wikipedia. Developers and Wikipedians who are subscribed to the software mailing lists could post advance notice of changes, and there would then be a centralized place for discussion to occur. Staying abreast of important software changes would no longer require watching multiple wikis, email lists, or noticeboards. ⇌ Jake Wartenberg 23:53, 7 May 2013 (UTC)[reply]

Suggestion: I think the first sentence should talk about more effective communication, not more communication. WMF staff already puts a lot of time and effort into communications. I think the issue is how those resources are spent, not how much are spent. -Pete (talk) 15:39, 8 May 2013 (UTC)[reply]
Done. Thanks ⇌ Jake Wartenberg 02:13, 9 May 2013 (UTC)[reply]
  • Support a noticeboard if it is separate from WP:VPT clearly, as a place for Wikimedia developer announcements, not general tech discussion. We post on VPT all the time (it's the number one edited project namespace page for my work account), but people seem to think it's too noisy. I don't think that, as an experiment, a noticeboard devoted to Wikimedia technical announcements would hurt. Other ideas that have floated around are newsletters, eventually incorporating notifications for subscribed editors, and lots of other things. We also already publish mandatory Wikimedia engineering reports on MediaWiki.org and the blog, and lots of other things, but I would be happy to post announcements to a Wikimedia tech noticeboard specifically devoted to key feature updates. And we can still try other communication methods or close the noticeboard if it doesn't work. In the long run though, the volume and velocity of work by the Wikimedia Foundation engineers, designers, product managers, and data analysts is only going to increase. We're already discussing moving MediaWiki (for all 800 wikis) to a weekly release cycle instead of every two weeks. We already bust our butts trying to announce changes, and we still get shit thrown at us every time someone is surprised or annoyed. I think now is a good time for English Wikipedia to think of ideas for how it wants to hear announcements about upcoming changes. Steven Walling (WMF) • talk 00:06, 8 May 2013 (UTC)[reply]
  • Or maybe we could have automatatic local duplication of the Wikitech-ambassadors list... --Yair rand (talk) 00:13, 8 May 2013 (UTC)[reply]
  • Strong support. If I recall correctly, the WMF (or was it the devs?) have previously vetoed this idea because enwp isn't the only project around, and they feel it wouldn't be fair or a good use of their time to do "special" announcements here that aren't done elsewhere. So if anyone is about to deploy that argument: I can only say that from the perspective of an enwp editor...that's not a reason to continue to dig yourselves this hole. We, sitting here on enwp, would really like to know about upcoming deployments. You, sitting there in San Francisco and such, would really like us to stop being shocked at and, increasingly, reflexively opposing code changes. Many devs and staff, like Steven and Oliver, do bust their butts to let us know things, but they're limited by the fact that there's just no effective local place to tell us these things. A real noticeboard here, on enwp, is indisputably the best way for you guys to get us, the enwp community, to stop being shocked by these things. That you're also not telling, say, svwp, or enwikt, or any other project about upcoming deployments is probably a sign that you ought to work on your communication strategies, not a sign that it wouldn't save you spectacular amounts of grief if you were better able to notify the community(ies) of things you're working on. You know, from bitter experience, that the enwp community isn't going to follow you to mediawiki.org and ferret out what changes you're planning on making to code that affects enwp. That strategy, the making us come to you, isn't working, even if it's what's technically "fair", and as a result you guys are catching some serious nastiness and dug-in opposition to nearly anything you say from the community here. Please, pleeeeease consider a newer strategy: just telling us what changes you're planning on making, in a centralized location, on the project your changes will be affecting. You can tell svwp and enwikt too, if you want, or not - we won't judge and we probably won't notice either way anyway - but please don't not tell us and create more grief for yourselves just because you don't want to have to tell the Xhosa Wikiquote or something. A fluffernutter is a sandwich! (talk) 00:41, 8 May 2013 (UTC)[reply]
  • Support Fluffernutter really hit the nail on the head with the word "reflexive." Sometimes it is indeed better to ask forgiveness than permission, but better communication could prevent a large amount of nastiness. ~ Amory (u • t • c) 02:10, 8 May 2013 (UTC)[reply]
  • Support - worth a try. See also Wikipedia:Petition to the WMF on handling of interface changes. Rd232 talk 04:18, 8 May 2013 (UTC)[reply]
  • I think it's worth a try, but I don't expect it to work. It will just change the complaint from "I hate this surprising change" to "Even though they posted it to some page I don't read, nobody personally informed me about it, so I was still surprised and I still hate it".
    Think back to the discussion about turning on the Mediawiki default for watchlists, which places un-read pages in bold-faced type. It was discussed at Village Pump (proposals) for a month, it was advertised at CENT, and it had overwhelming support and almost no opposition from a couple of dozen editors. Then the change was made, and suddenly people are screaming at the devs (who were utterly blameless) pushing stuff off on the community without consulting them. I don't recall seeing any apologies for that bit of slander, either: people who were informed of the month-long open discussion generally just complained that near-unanimity from a couple dozen editors didn't count as a community consensus, rather than striking their mistaken comments about the devs. And the feature is still crippled by default, which means that most editors don't even know that it exists.
    So think about those people. Think about the people for whom a month-long open discussion, not at VPT and additionally well-publicized at CENT, was just a trivial sideshow that happened to disagree with the True Community Consensus™ (defined as "any statement that agrees with the speaker's personal opinion"). Do you honestly expect those editors to accept a posting at a noticeboard as a valid method of communicating with "the community" unless each and every one of those editors individually chooses to read the noticeboard? I'm thinking that the only thing that would actually work is that recent proposal for blocking people until they acknowledge receipt of the message. These people seem to behave like the people who start the stupid petitions every time Facebook makes a change to its interface—hating on it for a couple of months, and then not even quite being able to remember how the old version worked. I think that we might all be better off with an explicit policy of not listening to en.wp about general design issues (which 99% of editors are no more capable of providing advice to the devs than 99% of Facebook users) but, of course, dealing promptly with practical things, like templates or bots breaking. WhatamIdoing (talk) 04:33, 8 May 2013 (UTC)[reply]
    • Completely and 100% agree that the changes are just an immediate anger that will subside rather quickly once people get over the newness. (personally, I found that it took me all of five minutes to adjust to the section edit link moving) Having yet another noticeboard isn't going to 1) make people any less pissy about changes, and 2) won't force people to read when changes are coming. EVula // talk // ☯ // 05:04, 8 May 2013 (UTC)[reply]
    I think there's a distinction to be drawn between informing and asking permission. WhatamIdoing is right that asking permission from the enwp community for a code change is pretty much a non-starter; we specialize in failing to agree on anything, and anyway, one project shouldn't have veto power over MW-wide code. However, there's some ground to be gained in informing the community of these changes, even without asking our permission. If there were a reliable location people could check to find out "The code for X will be changing on date Y," it would save us tons of after-the-fact VPT threads ranging from "OH MY GOD WHAT HAPPENED TO X??" to "X suddenly changed and now there are salamanders crawling out of my vector.js, what do I do?" It probably wouldn't prevent all the "X-changers must die" threads, but those are never going to be entirely killable anyway. Why not pick the low-hanging anger-fruit and at least improve things incrementally? A fluffernutter is a sandwich! (talk) 14:28, 8 May 2013 (UTC)[reply]
    If each and every one of these people actually read (and remembered reading) the announcements on the noticeboard, then sure. But they won't, so I don't think it will matter in actual practice. It might be a nice gesture, but ultimately a fruitless one. WhatamIdoing (talk) 16:07, 8 May 2013 (UTC)[reply]
  • Oppose: I don't think the answer to a sprawling system of mailing lists, IRC channels, local wikis (and their noticeboards), and global wikis (with their noticeboards and central notices) is to create yet another forum for announcements and discussion. This feels very similar to the proposed Wikipedia:WMF noticeboard.

    Given the existence of dedicated mailing lists such as wikitech-ambassadors and the entire Wikitech wiki, I can't see it being a great idea to create a noticeboard here that nobody will use. I agree that technical changes need better advertising, discussion, and feedback. m:Tech/Ambassadors has some thoughts on this (including its associated talk page) and there may be other ways to address the underlying issue here, but I don't think yet another noticeboard is what we want or need. --MZMcBride (talk) 05:02, 8 May 2013 (UTC)[reply]

  • Oppose per all the reasons Max outlined. Plus, I have a sneaking suspicion we've discussed this before...development talk should be centralized somewhere (either on meta, mw.org, wikitech), not regulated to a noticeboard on a single project. ^demon[omg plz] 05:06, 8 May 2013 (UTC)[reply]
    • @^demon: No one is proposing that we centralize developer discussions on to English Wikipedia. What's being proposed is that we separate out announcements about WMF work from the stream at WP:VPT, which is pretty noisy. Folks like me, Oliver, and others already spend no small amount of time advertising and discussing changes relevant to this project locally, so all we'd be doing is moving those announcements and hopefully gaining some additional visibility. Steven Walling (WMF) • talk 07:23, 8 May 2013 (UTC)[reply]
      Yes, this. The devs, overworked souls that they are, probably wouldn't even be affected by the creation of such a noticeboard. It would be the domain of the community-facing staff, whose job it is to communicate these changes to us, to do the posting and the talking. And if they're willing to do that, why not let them have a noticeboard to do it at? A fluffernutter is a sandwich! (talk) 14:28, 8 May 2013 (UTC)[reply]
      I suspect that you're right, and I certainly hope this is true, because given a choice between "the engineer does actual work" and "the engineer talks about working", I pick actual work every single time. WhatamIdoing (talk) 16:07, 8 May 2013 (UTC)[reply]
Who's Max? --Closedmouth (talk) 07:42, 8 May 2013 (UTC)[reply]
  • What McBride said. As a developer, frankly I'd like there to be less noticeboards. It'd be really nice if, when announcing a relevant upcoming or potential change, I could just put the announcement in one place such that everyone who cares could see it and discuss it. Instead there are already more places than I even know of, and indeed more than anyone could reasonably be expected to use and follow cross-project, and adding further project specific ones won't solve anything when folks can't even follow feedback on all of the existing ones already. Unfortunately, while these are real issues here, I just don't see this as a solution. -— Isarra ༆ 05:14, 8 May 2013 (UTC)[reply]
  • The problem isn't so much that people don't see announcements from the dev's (and chasing them to a noticeboard isn't likely to help visibility that mcuh, imho), but that by the time interface changes are "proposed" they are often presented as a fait accomplit. Just encourage the developers to say, for example, "we want to replace the OBOD with something, do you think this is a good idea?" Then wait for a consensus to occur on the change, suggesting different options if/as needed and remembering that changes that affect many people should require a very broad on-wiki consensus and may require advertising elsewhere is participation is lacking. Similarly, don't present huge packages that change everything or use extremely long presentations. Proposals/presentations that are short, simple, with the various changes split out as separate proposals even if they are meant to be part of a larger package, will result in higher participation than TLDR proposals. The location of the proposal is barely even relevant compared to the attitude and approach of making the proposal in the first place. – Philosopher Let us reason together. 06:30, 8 May 2013 (UTC)[reply]
    • Yes, it's the development process that's the problem (cf WP:interface changes). There needs to be more exposure of what thinking has gone into different decisions, and what sort of evidence base is being used. Some of the problem is the community not having input into the process; some of it is the community simply not knowing why things are being done, which contributes to a feeling that a change is arbitrary. Rd232 talk 11:04, 8 May 2013 (UTC)[reply]
    • It sounds like you're still expecting the devs to get our permission to make visible changes. They don't need it, and our interests are not best served by having any power over the devs' work. Design by an ad hoc committee of hundreds of mostly ignorant amateurs is always a disaster. We don't let the coders and designers control our decisions about achieving NPOV on a contentious article; they shouldn't all us to control their decisions about the website. WhatamIdoing (talk) 16:17, 8 May 2013 (UTC)[reply]
  • Technical discussion is already so fragmented, another noticeboard isn't going to help (relevant xkcd). We should utilize the current methods and fix the current problems (why is m:GMD going to WP:VPM???). I'm on the wikitech-ambassadors mailing list, and nearly everything gets announced there, and in non-tech speak too. Legoktm (talk) 07:38, 8 May 2013 (UTC)[reply]
    • To appease those who refuse to involve themselves with mailing lists, we could have a bot or script that automatically reposts relevant messages from wikitech-ambassadors to a noticeboard page here on enwiki, which users could then watchlist. — This, that and the other (talk) 08:33, 8 May 2013 (UTC)[reply]
  • Support a centralised, on-wiki noticeboard where the WMF communicates planned interface changes. Furthermore, I suggest that a structure similar to the Arbitration Committee noticeboard--i.e. announcements on the noticeboard itself, discussions on the talk page--may make it easier to follow and prevent it from duplicating the functionality of WP:VPT. wctaiwan (talk) 12:32, 8 May 2013 (UTC)[reply]
  • Support - Brilliant idea!, →Davey2010→→Talk to me!→ 14:36, 8 May 2013 (UTC)[reply]
  • Oppose -- I agree that communication is at the root of recent problems, but don't think that creating a new venue for communication will address that. I would rather see a solution that involves clear and inclusive development and articulation and goals, of transition plans, of backup/contingency plans, etc. I don't think there's any compelling reason that product development staff can't find more effective ways to communicate and develop and execute plans within the existing communication tools. -Pete (talk) 15:39, 8 May 2013 (UTC)[reply]
    • I want to note, my opposition isn't strong -- I don't see problems resulting from such a noticeboard. I just don't think we should allow ourselves to believe that the creation of a new venue will solve a problem involving complex communication dynamics. -Pete (talk) 15:42, 8 May 2013 (UTC)[reply]
  • Oppose for all the reasons already said. Communication is needed throughout the development program with proper feedback and consultation. A noticeboard will only allow this not to happen with a response of "well we posted it on the noticeboard" when the complaints start to come in of an implementation that nobody was aware of or expecting. SpinningSpark 16:36, 8 May 2013 (UTC)[reply]
  • Sigh. Communication is a two way process. Speaking and listening, writing and reading. Screaming into a well is not communicating with the community. Reading reports from your developers is not communicating with the community. You can make many changes that the community will never notice, but when you make a change that they might notice, you should really feel assured that they will notice, and some of those will object to the change. It is (at least in my opinion) your duty to seek out those objecting opinions and discover how the proposed change can be made with the least disruption. Surprise is a wonderful military tactic, but it's not a good way to win friends and build trust. It's true that FB complainers don't remember the way things used to be -- there are so very many of those ways, after all -- but the overwhelming memory is that the FB developers are screwing with them, and they don't like it. This is not a good way to encourage participation in an abstract undertaking like building an encyclopedia. I'm much more likely to want to see my grandkids, and will put up with a good deal more to do so. htom (talk) 18:18, 8 May 2013 (UTC)[reply]
  • Oppose People will always be upset by change. This will just be another board they don't read and they will still be upset that they weren't personally told that the changes were coming. This doesn't help anything and if anything is more likely to wheel spinning. People get over change remarkably fast once the newness wears off. -DJSasso (talk) 18:34, 8 May 2013 (UTC)[reply]
  • Indifferent I'm mostly indifferent on this because if this is deemed needed in addition to the messages I send out to wikitech-ambassadors, then I guess it needs to be done. I hoped those on -ambassadors could do much of the actual dissemination on the various 'pedias/projects because having someone local to the wiki, both in language and in expertise, is better at communicating what the real issues/changes will be for that community specifically, whereas I have to be fairly general for the exact opposite reasons (I'm English-only and not an expert in all the projects' methods/standards). I personally try to send out important/interesting-looking deployments to the -ambassadors list every Friday (when I send out the weekly Deployment and Roadmap update emails). There's way too much detail in those raw emails for most projects, even on a technical village pump (the intended audience is WMF Engineers and Volunteers). User:Greg (WMF) (talk) 18:55, 8 May 2013‎
  • Support if it would help but I'm not sure it would. We already have Village pump (technical) and a few other venues where the techies normally hang out. I think it makes some sense though to have a specific place where the developers (both the WMF and non WMF ones) can talk and discuss issues and notify the comunity. Kumioko (talk) 20:00, 8 May 2013 (UTC)[reply]
  • Comment: what about putting a Developer's Noticeboard on Meta, to counter the objection of giving too much prominence to English Wikipedia's concerns? Until cross-wiki watchlists arrive, that has an obvious downside, but that might be a good usecase for a sort of "cheap cross-wiki watchlist", where a bot mirrors pages from Meta to a protected copy of the page on English Wikipedia, so that edits on Meta can be seen here (notably, appearing in the watchlist). Rd232 talk 20:37, 8 May 2013 (UTC)[reply]
    • @Rd232: MediaWiki developers (staff and volunteer) already have MediaWiki.org, and mostly use Wikitech-l, which is one of our most high-traffic mailing lists. Developers don't really need another discussion space, the proposal is a lot more about how to advertise user interface changes to people who aren't developers. With that in mind, and considering the fact that Meta has very little real community of its own, I don't think a wiki noticeboard there would be much help. Steven Walling (WMF) • talk 08:01, 9 May 2013 (UTC)[reply]
    • @Steven Walling (WMF): - yes I know developers don't need another internal discussion space, but they do need a space where they can engage with non-developers on issues where non-developers can usefully give input, and in ways where they can clarify their thinking etc. I suggested Meta because that emphasises that the purpose is engagement with the Wikimedia community; and suggested the cross-wiki watchlist bot thing because putting it on Meta without something like that would be pointless. Rd232 talk 08:19, 9 May 2013 (UTC)[reply]
  • Sigh. I understand what the developers are talking about with having so many places to communicate. If there was just one place to watch, I'd watch that. I've just signed up for the wikitech-ambassadors mailing list, but when it was first announced I was of the impression that it was a mailing list for people who were willing to *act* as ambassadors, and who understand at least 50% of what is on VPT and wikitech-l and so on. (Incidentally,I watch both of them, but understand well under 10% of wikitech-L and under 20% of VPT.) I looked at the messages about moving the section edit button on wikitech-ambassadors-L, and the thread title is "Breaking change notice", which suggests to me that it's something for other developers to be aware of, not that a significant UI change is about to take place, so I'm not sure I'd even have opened that thread if I had been subscribed at the time. It seems that most of the 150 or so subscribers are actually developers or WMF staff, so I've got the feeling it's a bit of an echo chamber. There does not appear to be any significant discussion there; few threads seemed to have responses. So, what I would like to see is a central location where I can find out about changes that will affect me as a user, particularly UI changes, that provides complete information on what will change (both what will be new and what will be eliminated), provided at least two weeks before the change will happen. That way, if there are serious concerns about the change (like the fact that Notifications has major accessibility and usability issues), they can be addressed before there's a raging torrent. Oh, and it needs to be written in plain language; the reason so few "regular" editors watch VPT is that they can't understand the vast majority of what is there. And whatever you do, don't send people to bugzilla. If this means a project-specific noticeboard, I'll be happy, and I'll put it on my watchlist. Risker (talk) 04:41, 9 May 2013 (UTC)[reply]
  • Neutral, leaning oppose I frequently speak to both developers and Wikipedia editors, so I'm on the fence. In my opinion, while the community can't be prevented from making this noticeboard, I don't feel it would resolve the issues we tend to have. Developers must keep track of many things each day, and often don't have the time for another page to watch. I think the community can improve on the current system by working for more participation in discussions about rather-sweeping features changes. For example, I strongly feel that the consensus generated on this page (without a full RfC) for the changes to the watchlist was inadequate for such a change. I do not think we can keep faulting developers for what I view as at least partly the community's fault.--Jasper Deng (talk) 05:58, 9 May 2013 (UTC)[reply]

Fixed Navigation Bar

This proposal seeks to establish the community consensus regarding the introduction of fixing the navigation bar to the top of the window. It will bring the look and feel more in line with other famous sites out there, as well as, in my opinion, make it more personal, which may lead to better editor retention.

I have made a crude mock up in case I haven't described it well. 1 2 The design is irrelevant; it is a demonstration of positioning.

This would have the side effect of making the new echo notification system a lot more visible.

Thoughts? 930913(Congratulate) 22:15, 8 May 2013 (UTC)[reply]

@Theopolisme:Just a note that I've started a quick mockup css, just add @import "//en.wikipedia.org/w/index.php?title=User:A930913/fixnav.css&action=raw&ctype=text/css"; to Special:MyPage/vector.css 930913(Congratulate) 07:01, 9 May 2013 (UTC)[reply]

Discussion

  • Support (or is this section for actual discussion, not voting? Feel free to rearrange). With the caveat of not everyone uses JavaScript, this is a great idea. (Maybe it doesn't have to use JS. Remember frames?) It would keep the "new messages" notification (and the Notifications notifications!) where you could see them. Not sure how much use it would be besides that, but it would look nice, definitely. Ignatzmice•talk 22:40, 8 May 2013 (UTC)[reply]
    • This could be done with CSS. There are even some script around that fix the entire top area (including the tabs) to stay visible during scrolling. — Edokter (talk) — 22:48, 8 May 2013 (UTC)[reply]
      • In that case, the only drawback would be "It's not very useful", which would be outweighed by "Yes it is, for this one thing". There could even be (yet another!) gadget to turn it off. Ignatzmice•talk 22:52, 8 May 2013 (UTC)[reply]
  • Wikipedia...omg lulz so Web 2.0. But I like it. @Edokter: do you know what that script is called? If you smack a bit of sexy shadow CSS on the bottom I think you could hit it big. Theopolisme (talk) 01:00, 9 May 2013 (UTC)[reply]
  • Maybe. This would certainly increase visibility. However, in general I don't like fixed tabs; they take up too much space. Right now I have 4 lines on top of each webpage: "Editing Wikipedia:Village...", "File Edit View History", the actual tabs, and the URL bar. A fifth would be very cluttersome. And some browsers have even more stuff on top. And this is assuming mobile is excluded. -- Ypnypn (talk) 02:25, 9 May 2013 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=554257333"