Jump to content

Wikipedia:Village pump (proposals)/Archive 118

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Redirects for ALL emoji flags

When you combine two Regional Indicator Symbols to form a ISO 3166-1 alpha-2 two-letter country code some devices (Android, iOS, OS X) interpret the symbols by displaying the flag of the country. Originally only 10 flags (CN, DE, ES, FR, GB, IT, JP, KR, RU and US) were supported by Apple and Google. When Android 5.0 "Lollipop" was released hundreds of flags were added to the operating system, the Unicode specification already supported those flags but no major company actually supported them until then. We currently only have redirects for the original 10, so I propose to create redirects for all other flags. I created a list (here) with the code (for readability), the emoji code (where the redirect comes from) and where the redirect should go. This was already requested on the administrator' noticeboard and bot requests, but it was suggested to reach consensus here first. Robin van der Vliet (talk) (contribs) 14:15, 14 January 2015 (UTC)

I can only imagine such a character combination to end up in the search box from someone who wonders what that little symbol is they are looking at. Since redirects are cheap, I have no real objections to it. Traffic for these redirects is really low, but there is traffic. http://stats.grok.se/en/latest90/%F0%9F%87%B7%F0%9F%87% http://stats.grok.se/en/latest90/%F0%9F%87%AB%F0%9F%87%B7 . I vote strong sure, whatever. I learned something new today. Martijn Hoekstra (talk) 16:16, 14 January 2015 (UTC)

Images category

Hi all,

I am posting this here because I am not sure of any better place. I propose introducing this category. It has been tested for the last 7 months in 12 Wikipedia languages, and has been succesfully used to add images to 18.000 pages.

In short it means:

  • Make a category of pages that have no image - but have an image on Wikidata
  • Someone adds an image
  • The article automatically disappears from the category
  • All images are from Commons and are free
  • The category is hidden, and not visible to the reader

How it works is by a template that is added to the infobox template used in articles. This compares the template section "image" to that same section on Wikidata. If there is no image it is added to the category, if there is an image it is not. The category has flaws, only about 90% of suggestions are usefull. For example images outside the template are not counted, second templates and some images on Wikidata are not usefull to Wikipedia. After a while you end up with only useless image suggestions, but on the English Wikipedia it will still produce several thousands of images before this stage is reached. Because it uses infobox templates, very few changes are needed to fully remove the category again if it becomes out of use.

My proposal is to only introduce this category for now, since it is the most usefull, and not any of the other 4 categories at simple:User:Taketa/Wikidata Images. This to keep it simple for the moment. I would appreciate feedback on whether or not we should introduce this category to Wikipedia.

Sincerely, Taketa (talk) 23:28, 7 January 2015 (UTC)

PS: as a sidenote, I have already added about 800 images to the English Wikipedia, purely as a side effect of the category on the 12 other Wikipedias when I noticed the English Wikipedia also did not have an image. - Taketa (talk) 23:35, 7 January 2015 (UTC)
I think this is a great idea. Also, if it could be broken down by subject area (even as an occasional report), that would be even better. WhatamIdoing (talk) 22:40, 14 January 2015 (UTC)

Better watch list options

My proposal: In addition to watchlisting a single page, we also add these options:

  • Watchlist a page and all transcluded templates (This would, technically permitting, be dynamic, updating the watch list as templates are added and removed)
  • Watchlist a page and all sub-pages (Same as above, dynamic if possible)

The transcluded pages option would help in the situation described at Wikipedia:Village pump (policy)/Archive 117#Changing templates, where editors might not be aware of template changes on there favorite pages. The sub-pages would be helpful for pages like this one, allowing you to watch this page and all its archives, for example. Hoping to find support for these proposals. Oiyarbepsy (talk) 07:24, 10 January 2015 (UTC)

  • Comment How about an alternate approach, add a watch list preference option that causes transcluded templates of watched pages also to be shown similar to the "Show Wikidata edits in your watchlist" option. Something like "Show transcluded template edits in your watchlist"? PaleAqua (talk) 07:43, 10 January 2015 (UTC)
    Well, I would think that you might want some pages watched with templates and some without. Oiyarbepsy (talk) 07:56, 10 January 2015 (UTC)
    I think it would be more likely to be interesting to be able to watch templates for every page I watch, but to be able to turn that on and off without having to remove and re-add pages to my watchlist and without worrying that the last change viewed got reset if I did. Also we already have a precedent with Wikidata, seems like it would be more confusing to have two similar features work very differently. Finally my approach avoids changing how the watch list is edited, including raw watch list, and simplifies adding pages to the watch list. Instead of having to worry about a page being in the watch list in one of two states. PaleAqua (talk) 01:43, 11 January 2015 (UTC)
  • Unsurprisingly, I support this proposal. Martijn Hoekstra (talk) 09:51, 10 January 2015 (UTC)
  • Support, though it might be easier to implement as PaleAqua suggested. —PC-XT+ 23:41, 10 January 2015 (UTC)
  • Comment, while working on this, I encountered some ambiguities, especially for the "static" case proposed by PaleAqua:
    • When watching a page, all transcluded pages are watched as well. When unwatching a page, do all transcluded pages get unwatched as well? None? Only those that are not transcluded on other pages you are watching? Or is watching transclusions a one-way street, and do they have to be unwatched on a case-by-case basis. The last is clearly implemented most easily.
    • Should a page that has some transclusions watched display its transclusions watched or not watched, or a third option? I think it should show unwatched.
  • What would you all like to see done first, a userscript that can watch transclusions, one way street, at least at first, or a userscript that can augment the watchlist to show transcluded pages too (but no option to differentiate between pages that do or don't watch transclusions)? Both my time and my skill are limited, so I'd like to prioritize based on demand. Martijn Hoekstra (talk) 15:32, 13 January 2015 (UTC)
    You can now import this script (importScript("User:Martijn Hoekstra/watchthingy.js"); in your common.js), and the basic watchlisting should work. If anyone wants to try that work in progress and provide feedback, I'd be really happy. Martijn Hoekstra (talk) 22:22, 13 January 2015 (UTC)
  • Comment While these would undoubtedly be very useful changes, proposals to modify the operation of the watchlist have been made for a long time and the Foundation and developers do not seem keen on implementing the suggestions that have already been made (which include multiple watchlists, being able to watchlist an article for a specific period, watchlisting category membership or template use, a personally auditable log of when you put items on or took items off the watchlist). I'd love to have the watchlist be brought into the current decade but I'm not sure that such improvement is likely to be implemented any time soon. —Tom Morris (talk) 16:38, 15 January 2015 (UTC)
    • Tom, I'm finding that with the API it's fairly doable to implement anything that doesn't have a database component on the client side. The bare bones version for watching all transclusions on a page is already done, and works. When "works" will turn in to "works well", I'll go for the dynamic watchlist for transclusions. If I can get enough help from people who do actually know how to work with JavaScript, and the functionality is considered useful, this could probably easily be turned into a gadget. Sitting back and blaming it on the foundation is only ~20% as fun as fixing it. 17:10, 15 January 2015 (UTC)
    • There has actually been a little positive chat about multiple watchlists among the devs again. It's much too early to predict an outcome, but it's possible that we might (finally) see some progress on that. I'm not certain, but I believe that mw:Requests for comment/Support for user-specific page lists in core would be the main page to watch for any developments (if they actually eventuate). Whatamidoing (WMF) (talk) 19:40, 15 January 2015 (UTC)

Turn the MoodBar back on

Consensus was in favor of enabling the program again. That said, this Phabricator discussion that discusses the actual logistics of getting the program working again suggest that the amount of work required is not feasible according to the WMF. Please see this discussion for more information on these conclusions. I, JethroBT drop me a line 09:34, 28 February 2015 (UTC)

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

This was published back in September, but just got a Signpost write-up today: Ciampaglia, Giovanni Luca; Dario Taraborelli (September 4, 2014). "MoodBar: Increasing new user retention in Wikipedia through lightweight socialization". arXiv:1409.1496.

After six months, 3.6% of editors who were able to use the MoodBar were still editing, compared to 3.3% of those who did not have the option. It doesn't hurt anyone who doesn't want to use it, so let's turn it back on. EllenCT (talk) 02:44, 4 January 2015 (UTC)

0.3% of everyone who tries creating an account, but 9% more retained editors after six months, and per Figure 5 (right) on page 7, the proportion of retained editors grows over time. Also, I should point out that 0.3% amounts to 216 editors per year at the current rate of new account creation. EllenCT (talk) 06:48, 4 January 2015 (UTC)
  • Support I also noticed that in the Signpost, and was wondering why it was shut off if it genuinely improves editor retention. Considering that little else has seemed to work, we should be doing things that do. Oiyarbepsy (talk) 07:22, 4 January 2015 (UTC)
  • Weak support: I'm not a statistician, but if it does no harm and editors are willing to reply to messages through it, then whether it makes 20 or 200 new editors I don't see any objections to turning it on. This is on the understanding that already experienced users will never be bothered by it? BethNaught (talk) 17:26, 4 January 2015 (UTC)
  • Support. I don't see any reason not to. Gamaliel (talk) 17:35, 4 January 2015 (UTC)
  • Support, if it produced better content, how could it have been harmful to the project?--RightCowLeftCoast (talk) 21:10, 4 January 2015 (UTC)
  • Note, at the moment the MoodBar is broken on nlwiki. People can feedback, but it isn't possible to comment, delete or hide feedback. Note that development of the MoodBar has stopped. Sjoerd de Bruin (talk) 09:41, 5 January 2015 (UTC)
  • Support - Like the Feedback tool this'll probably get abused, Plus IMHO it does seem rather childish, But I'd rather this get abused then the articles so meh why not. –Davey2010 Merry Xmas / Happy New Year 03:23, 6 January 2015 (UTC)
  • Support I was very active on this project, and was disappointed when it was discontinued. Some editors responded back and continued to edit productively when I addressed their feedback, particularly the negative ones. This is an easy way to connect with productive editors early on and get them to stick around. I, JethroBT drop me a line 08:28, 6 January 2015 (UTC)
  • Support - I did like the tool when it was active, and I was sad to see it go. Seeing that it has a quantified positive effect, I'd support bringing MoodBar back. ~SuperHamster Talk Contribs 08:50, 6 January 2015 (UTC)
  • Oppose - As I recall, the moodbar was rarely used for its correct purpose; editors mainly used it to feedback on individual articles, and the talk page is the best place for that. Added to which, most of the comments were unhelpful at best and downright destructive at worst. There are many reasons why editor retention had a slight increase during that period but I don't think the moodbar was one of them. I would much rather see effort going into promoting some of the excellent mentoring programmes that already exist such as the Teahouse and the adoption scheme.--Ykraps (talk) 15:37, 6 January 2015 (UTC)
  • Support. Can't see any harm in it; seems to have improved the project (if only slightly). APerson (talk!) 01:42, 9 January 2015 (UTC)
  • Support. A marginal improvement in new user retention is, in the long run, a big deal. The Land (talk) 11:04, 10 January 2015 (UTC)
  • Support. I don't see why not. Retaining more constructive editors is always a good idea. Tony Tan98 · talk 02:07, 13 January 2015 (UTC)
  • Questions: Who's going to monitor any comments made? Identify the ones that need to be hidden and/or suppressed? I'm not inherently opposed to the idea of starting it up again when it's working (if, indeed, it is felt useful enough to get working again - not my call). However, any process that permits feedback needs to be patrolled and problematic edits promptly identified and managed (via hiding and/or suppression as appropriate). We also know that the last time around, there were issues with blocked users being able to use it (both relatively benign blocked users and some hyper-vandals too); not sure if that was fixed, and I'm not about to go digging into the Bugzilla archives to look. As The Land notes, this is actually a fairly significant increase in the retention rate, so the community may feel it is worth the time invested in managing the comments, but we need to keep in mind that there is an increased workload for the patrolling editors (and the oversighters, who were kept busy with this and with AFT5). Risker (talk) 05:55, 13 January 2015 (UTC)
Well, I feel it should work the same way with revision deletion and oversight. Admins able to remove the revisions content from view, and oversighters having authority over oversighting. That's how all that stuff is usually handled, even on more mainstream, 'popular' pages. Tutelary (talk) 19:52, 14 January 2015 (UTC)
  • Oppose - I don't think I was around for this, but 0.3% does not seem like a statistically significant change to me, certainly not when you take the potential random variation into account. Even that 9% figure that gets touted there, which I find to be distinctly dubious, doesn't seem like anything; I'd imagine that random variation over time could easily add up to that, and indeed exceed it. To me, this looks incredibly childish and tacky, and excessively targeted at a younger demographic; surely we want to be targeting older editors who have experience rather than kids? I can say for certain that I'd have been put off by this sort of thing when I first edited, and that was when I was 16. Another overhyped WMF experiment that we don't need. And if something as simple as this is broken on nlwiki right now... well, that says everything. Lukeno94 (tell Luke off here) 19:58, 14 January 2015 (UTC)
Lukeno94 (talk · contribs)What information do you have that this is more likely to attract younger editors? As far as the bugs, obviously the consensus here to re-activate would result in the mood bar getting fixes, since there would be consensus to use it. It appears the bug mentioned above was fixed on the sixth. Oiyarbepsy (talk) 20:39, 14 January 2015 (UTC)
Oh yeah, also, what makes older editors better? Surely we'd rather have 60 productive years from a new young editor than 10 years from a new senior citizen editor. Oiyarbepsy (talk) 21:30, 15 January 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

ICD9 template - commercial site

Please forgive me if I am posting in the wrong section--saw that an old message from several years ago recommended this proposal be taken here. It looks like for several years the ICD-9 template has been pointed towards a commercial site. Many users have raised complaints on the talk page over many years, though this issue has never been rectified. The template has also been edit protected. Can someone please take a look and weigh in? -download 21:09, 17 January 2015 (UTC)

Infobox links like that are regulated by WP:External links guideline, which treats for-profit and non-profit websites identically. However, if you would like to get this one changed, your best bet is to propose a viable alternative. If memory serves, nobody who has objected so far has actually been able to (or bothered to?) find a non-commercial alternative. WhatamIdoing (talk) 22:03, 17 January 2015 (UTC)

Make a bot do all the minor edits using AWB

I don't see why not. AWB has made my life much easier, but it is still kinda tiring to have to manually put the "See also" section in its right place when AWB detects that error. Tetra quark (don't be shy) 23:45, 17 January 2015 (UTC)

Typhaine Case User:Panam2014/Typhaine Case

Hi Can you help me to translate [1]. It could be a good article for our encyclpedia. Regards. --Panam2014 (talk) 09:46, 16 January 2015 (UTC)

Stub created at Typhaine case for any Francophone who wants to tackle this: Noyster (talk), 16:05, 18 January 2015 (UTC)

Proposal to address Admin misconduct

Hello all. I am proposing this based on the recent ARBCOM case talk page statement 3.Administrator misconduct is our responsibility because the community has failed to come up with a workable community recall process. If a call is made to make it editor business I think we should heed that call.

My proposal is simple; essentially we would run a reverse RfA (60% threshold) for the community to decide if conduct is severe enough to remove the admin from their position. The filer would be given 500 words and 50 diffs, the admin 500 words and 50 diffs and any additional individuals may submit 100 words or 10 diffs if they feel something is overlooked, with judicious hatting of irrelevent material. Any users that would be considered involved with regards to the admin would not be counted in any consensus phase.

I believe this will help in two ways. First the community has a greater ability to hold people accountable, and the exception to involved individuals will curb the axe to grind concept. Second RfA should become easier, since the individuals who are in that slot can be removed much faster if the community is shown issues with the actions taken. Granted the actual removal of tools will still need someone with rights but I think this would be a positive step for the community. Thoughts? Am I off my rocker and should I climb back to my hole? Tivanir2 (talk) 17:55, 12 January 2015 (UTC)

This is a perennial proposal and if you want to get it off the ground proposing solutions the issues of the possibility for abuse and requirements for filing would be the best way to go about it. Sam Walton (talk) 19:37, 12 January 2015 (UTC)
It might be helpful to look at how they do it over at the Spanish Wikipedia. (The translation is clunky, I know, but it's readable.) In my opinion, it seems like a sensible and fair system, although a few minor modifications could be made. Apparently, they haven't yet fallen apart, so it is possible. I think we just need to be bold and take a few chances. --Biblioworm 20:22, 12 January 2015 (UTC)
In due course it could do with some qualifiers re bad-faith or needlessly repeated recall attempts, and some indication of who determines the consensus. But i like the basic principle. -- Euryalus (talk) 21:23, 12 January 2015 (UTC)
Seems like a good proposal. Sam.gov (talk) 22:11, 12 January 2015 (UTC)
An Arbitrator, speaking for himself alone, doing a bit of off-the-cuff people don't appreciate our behind the scenes work enough whinging (in response, to be fair, to some non-Arbitrator whinging) as part of a multi-part comment isn't a solid basis for a major shift in policy. It's probably not a good idea to frame your proposal that way.
In any case, can you actually think of any real examples of admins who would (or should) be desysopped by this process that you can't deal with through existing processes? I mean, if you can clearly state your case in 500 words and 50 diffs, then congratulations—you can file a request for arbitration. If it's a clear-cut case – and it doesn't involve misconduct by other editors that the ArbCom properly needs to address – then the ArbCom can deal with it expeditiously by motion. (Indeed, it has done so on a number of occasions.) Heck, cases don't even need to reach the stage of acceptance or motion—admins faced with such filings may also resign their bits without being compelled by ArbCom action. (This has also occurred a number of times.)
The solution to the mistaken perception that we cannot desysop admins who behave badly isn't to (re)invent a noisy, flawed, unpleasant new process. It's to better educate editors who hold this misconception about how to use existing processes. TenOfAllTrades(talk) 22:45, 12 January 2015 (UTC)
As the whinging arb in question, my remark was specifically about off-wiki backchannel stuff. Public cases involving a single admin and their misconduct are no more difficult than any other (and can often be handled summarily by motion). The issue is that, absent a community process, we get a large amount of email making all kinds of accusations about admins and these really need a process, perhaps with an investigative element, that falls short of a case, to handle them.  Roger Davies talk 09:03, 13 January 2015 (UTC)
The emails and accusers should be redirected to WP:TEA or /dev/null as appropriate. Stifle (talk) 10:18, 14 January 2015 (UTC)
If we need to modify the amount of text and diffs we can. This proposal is mostly to get the ball rolling, and if it can be handled without having to rush to ARBCOM each time we feel there are admin issues I think that will help both ARBCOM and the community. RfA is so difficult because the community is handing you tools and it is harder than it should to revoke them if the person abuses it. As always if requested we can always allow extended requests, 500 and 50 were just arbitrary numbers I used from the initial filing request for ARBCOM. I will be checking on the spanish wiki to see how they do it at the request of another editor. Tivanir2 (talk) 11:38, 13 January 2015 (UTC)
Would it be possible to get rid of the "discussion" portion entirely? Frankly, the interminable and prejudicial chatter is off-putting to many/most. Could we not invite only the posting of diffs and allow uninvolved members of the community to decide for themselves whether an abusive pattern worthy of desysop exists? • Astynax talk 18:56, 14 January 2015 (UTC)
Two responses. First, I think a lot of editors would be more likely to support candidates for admin if they knew they could lose the right more easily. Second, it seems that requests for admin is not the disaster it used to be. The trolls who post useless garbage are mostly gone and the atmosphere isn't all that nasty anymore. Oiyarbepsy (talk) 15:48, 13 January 2015 (UTC)
That was the reasoning behind not counting involved parties. Also I figure people could move to hat sections if it clearly looks like someone is trying to get revenge, which would be a quick link to conduct problems for refusing to drop the stick over at ANI. Tivanir2 (talk) 16:34, 13 January 2015 (UTC)
Even so, you would need to look art everty dispute the admin ever dealt with to find all involved parties. Some users may have long memoriy when it comes to things like this. עוד מישהו Od Mishehu 15:56, 15 January 2015 (UTC)
  • First of all, I have to call bullshit on the idea that "Administrator misconduct is [ArbCom's] responsibility because the community has failed to come up with a workable community recall process". I'm old enough to remember this fiasco, in which an admin was properly recalled by the community, but refused to step down. ArbCom ruled that recall was a strictly voluntary process, and that the rest of us were suckers for believing in a campaign promise which they refused to enforce. Every thinking person realized at that point that no community process was workable—no de-adminship process is workable unless ArbCom is willing to enforce it. So what really happened is that the community had a process (albeit an imperfect one), but when the rubber hit the road ArbCom didn't back it up and the credibility of the community process collapsed. Granted, this was many years ago—ArbCom has changed a lot, as has Wikipedia—but the current state of affairs was very much created by the actions of previous iterations of ArbCom.

    As for solutions, I'd certainly be open to some kind of community process. I guess I'm pessimistic about the current community—I've noticed that the quality and cluefulness of input at noticeboards like WP:RS/N and WP:BLP/N has sunk to the level of "useless and probably dangerous", so I'm not sure how productive a massive community de-adminship discussion would be. A different option would be to appoint/elect an Admin Review Board consisting of experienced admins and non-admins, who would hear and screen admin-abuse cases. This Board could either be given authority to desysop people themselves, or could decide which complaints had enough substance to pass on for review by ArbCom. Either way, this sort of delegation would likely reduce ArbCom's workload. I think that similar ideas have been proposed in the past and not enacted, so there may well be a fatal flaw I'm overlooking, but those are my 2 cents. MastCell Talk 19:46, 13 January 2015 (UTC)

    The simplest thing may be to make Recall compulsory then? Cas Liber (talk · contribs) 19:52, 13 January 2015 (UTC)
    Do you mean in the sense that all admins would have to be open to recall, or that admins who are recalled would be compelled to step down? MastCell Talk 20:02, 13 January 2015 (UTC)
    I believe they meant both. If a smaller subsection of editors and admins are selected for the duty that would also be fine though declaring who is fit and unfit to hold such a position will be an interesting process. I essentially meant with the original proposal that once it was discussed by the community there would be a single person or perhaps even ARBCOM that would enforce the decision. This process I was putting forward is by no means suppose to be voluntary, if someone can show how an admin is abusing their power it would act similar to ARBCOM with immediate removal of tools. Granted identifying the enforcing individual (hell even if we appoint a single individual in the capacity that this is all they do) will cause some issues, but I never envisioned this proposal to lack teeth. I don't like playing useless merry go round. Tivanir2 (talk) 20:14, 13 January 2015 (UTC)
    I agree with MastCell's first paragraph. Stifle (talk) 10:17, 14 January 2015 (UTC)
  • comment - Could start with a community ban for 1 week. If that works nicely make it a month etc 84.106.11.117 (talk) 08:20, 14 January 2015 (UTC)
  • Oppose - I believe that the type of admin who, if such a vote started, would have the lowest chances of remaining an admin - is the type who enters heated conflicts and tries to solve problems - as the solutions would tend to satisfy no one - or the type who deals with highly controvertial issues, where any solution would xeem wrong to many users. Unfortunately, these are also the most important types of admin we need to retain. עוד מישהו Od Mishehu 10:44, 14 January 2015 (UTC)
    True but there is also a difference between an admin that makes tough calls and one that actually violates usage of tools. As a community I like to think that the average editor can do the "well I think they have made questionable calls, but they didn't violate usage of tools." I think the smaller subset discussed by mastcell might be a better plan; also it is possible we could have a rotating pool of people that can deal with this so if anyone would be considered involved with the admin they can recuse and we have more available for decisions. The hardest part is vetting people to ensure they actual know the policies, since that is something that is hard to quantify. Tivanir2 (talk) 13:55, 14 January 2015 (UTC)
    The editor who feels wronged by this admin would probably be more likely to voice his/her opinion than the average editor - partly because the average editor would need to look into the background of the complaint and decide whether or not there was actually a violation, while the editor who feels wronged already knows what the answer is (remove the adminship) and just needs to read the other opinions of users who said so (there will always be at least one, the nominator) and word the reasoning. עוד מישהו Od Mishehu 17:58, 14 January 2015 (UTC)
    I don't think so. MastCell certainly fits all of your criteria (enters conflicts, deals with controversial areas, tries to solve problems), and I really can't see anyone trying to recall him. Perhaps the kind of admin who not only works in heated areas but does so abrasively and offensively might be at risk, but perhaps it would actually be better for us if admins without good social skills didn't work in the most difficult areas, no? WhatamIdoing (talk) 22:57, 14 January 2015 (UTC)
    I didn't say that admins like MC would be nominated for recall all the time; I said that should such a request be made, they would be at a distinct disadvantage. No admin would be immune to having a recall request made against them; the question is, how likely are they to retain their adminship once such a request is made - and even the civil admin with good social skills, if they handle these areas, are at a disadvantage, while those are the admins we have the highest need to retain. עוד מישהו Od Mishehu 05:45, 15 January 2015 (UTC)
  • Leaning toward support but only leaning because I can see too many ways for such a system to be gamed too easily if there are not additional, very well defined rules in place before a system is actually implemented. John Carter (talk) 15:34, 14 January 2015 (UTC)
  • Tentative support speaking for myself only, though a new member of arb com, (and based on only what I have seen from the outside) I see this as dealing not with cases of gross misuse of tools in a specific incident, which as far I can judge arb com has handled adequately, but with generally subpar administrative behavior, which I doubt that arb com handles at all--nor would I personally want it to. That's the sort of judgment the community should be making, just as it makes the decision to appoint new admins. DGG ( talk ) 16:39, 14 January 2015 (UTC)
  • Tentative support Seems good in generalities, but not sure if the specifics would hang us up too much. --SarekOfVulcan (talk) 17:03, 14 January 2015 (UTC)
  • Support. As the user who initiated the old case where ArbCom refused to validate the community process, I applaud User:MastCell's first paragraph above.[2] I didn't think anybody remembered, but it was a proper disgrace, and disinclined me for many years from having any truck with the committee, whinge whinge. (Though I made an exception for RFAR'ing Jimbo.) It's for sure not easy to desyspop misbehaving admins. I wish it was easier. I understand the risks of an anti-RFA process being flooded by users with personal grudges, but I think it's worth trying. Note the support above from three arbitrators, Euryalus, Guerillero and DGG, who apparently understand the need for a community process. If it's reasonably easy to yank the tools in cases where they don't work out well, even without blatant long-time abuse of the arbitrable type, it would be less dangerous to create new admins to "give them a chance", and then we could lower the bar for new admins. We sorely need new admins. A process which can be discontinued if it turns out not to be useful is a fairly cheap experiment, surely. We should stop eternally talking about de-adminning processes and try something for once. Bishonen | talk 18:58, 14 January 2015 (UTC).
    In my last RFA, there were only 3 or 4 opposes out of 37 that I'd put in the "personal grudges" category, and I would expect that most would be lower than that. --SarekOfVulcan (talk) 19:45, 14 January 2015 (UTC)
    I can personally think of at least 3 people in the last year whom I did not support at RfA, but whom I would have supported had a process like this been available. DGG ( talk ) 19:49, 14 January 2015 (UTC)
  • Weak support I suspect there will be some conflict in power since only ArbCom has the authority to desysop admins who do not wish to give up the tools. Though I suppose that'll be remedied if ArbCom just follows the community will on this sort of thing. I also don't want this to purely be for desysopping. Admins should get warnings not to do X, or that Y is in violation of Z policy and that they should generally not do it. I'd rather not shoot them with a shotgun on first attempt, plus that would just lead a lot of !oppose votes to the anti-RfA. Though the oppose !vote did make a great point; Wikipedia is full of ideological battles, users who have felt wronged, and the like. Some person getting involved in a dispute with an admin may, after losing said dispute, watchlist the page for Anti-RFA and latch onto the first complaint against the admin. An unpopular admin decision isn't always one that went against the rules and policies following. Granting that, I weakly support it because I can see some future abuse in the future, but that yes, we shouldn't have to go through a 3 month long ArbCom case to get rid of bad admins. To add, there once was a proposal for an 'admin review' board where you could request outside input on an admin's actions and see if community consensus affirmed such. Maybe this could be a sequential step to that. Tutelary (talk) 20:01, 14 January 2015 (UTC)
  • Information The German Wikipedia has a recall system that mostly seems to work out for them, on balance. I believe that the rules run something like this: if any 50 experienced editors (defined in detail; de.wp has actual votes, and you must meet certain requirements to be able to vote) vote in the space of 30 days to have your admin bit removed, then you are de-sysopped. Any de-sysopped editor is permitted to be re-elected again, through the normal RFA process, immediately. If you survive a de-sysopping vote, then a second vote cannot be opened again for another 365 days. It's not perfect, and I can think of at least one way to game it, but they seem to be satisfied with it. WhatamIdoing (talk) 22:57, 14 January 2015 (UTC)
  • Oppose. Comparing Reverse-RfA with RfA is like comparing apples with oranges. While I am constantly deliberating over the issue of desyoping or sanctioning poorly performing admins (I recently launched an RfC myself), I oppose reverse RfA in any shape or form. As Od Mishehu points out, truly active 'front-line' admins would certainly be subjected to mob rule and kangaroo court much in the same way that 'oppose' votes on RfA are often vindictive. While the comments of Roger Davies are absolutely valid, here or anywhere else, the only solution, IMO, is a rotating committee of respectable and highly regarded users and/or 'crats who can adjudicate without the background noise of the anti-admin brigade and the peanut gallery, and without the monumental red-tape of the Arbcom. --Kudpung กุดผึ้ง (talk) 07:48, 15 January 2015 (UTC)
    The "monumental red-tape of the Arbcom" is an oft-stated but seldom-examined issue. If we look at the most recent 8 instances at Wikipedia:Former administrators/reason – about a year's worth, going back to December 2013 – where editors' bits were removed under circumstances where there were issues with their conduct (as opposed to lapsing due to inactivity), we find:
    • 4 instances where an editor resigned "under a cloud": Nikkimaria, Kaldari, Jclemens, and Eloquence. (Of those, Jclemens resigned after an ArbCom case request was filed but before it was accepted. Eloquence resigned after a case had been opened; the case was suspended with a motion taking formal notice that the resignation occurred under a cloud.)
    • 2 instances where an editor was desysopped by ArbCom motion: Secret and Toddst1. (Technically, Toddst1 wasn't desysopped, though the effect was the same. He announced his departure from the project, and the ArbCom barred him – by motion, on pain of desysopping – from using his tools without ArbCom's explicit permission should he ever return.)
    • 2 instances where an editor was desysopped after a full arbitration case: Kafziel and Nightscream.
    Some interesting features start to pop out. In the majority of instances now, desysoppings aren't the result of standard-issue, complete, month(s)-long Arbitration cases. Former admins are often capable of reading the writing on the wall when faced with strong community disapproval and well-formed objections to their conduct. The pressure of an ArbCom filing – potential or actual – or the opening of a case is often sufficient to bring about a resignation. (Worth noting is that under-a-cloud resignation has been a specific, codified bar to re-sysopping for only a few years; as far as I can tell, the relevant language was added to WP:ADMIN sometime in 2012. It seems to be a very constructive and useful way to avoid or terminate more cumbersome or formal processes of any flavor.)
    Among the instances that do demand a formal finding by ArbCom, some significant fraction are handled rapidly, by motion. The desysopping of Secret took 15 days from his misuse of the tools to enacting the motion. For Toddst1, it was 7 days from the filing of the first request on RfArb to the motion barring Toddst1 from using his tools.
    Overall, in the last 8 instances of problematic admin conduct, 6 had the tools removed without requiring a full ArbCom case. The perception that the only way to see a 'problem admin' desysopped is through a lengthy arbitration is mistaken, and it would be an error to promulgate new policy predicated on that misconception. Desysoppings through full ArbCom cases are now a minority. TenOfAllTrades(talk) 19:05, 15 January 2015 (UTC)
  • Support. At this point, I support any community-driven desysop process, no matter what the details are. If we finally get a critical mass of people and a proposal is adopted, then it can be tweaked if there are problems with it (i.e. if it turns out it can be too easily co-opted by trouble-stirrer-uppers). But if we wait until we have a perfect proposal, nothing will ever happen. It so happens that I like Mastcell's idea of an admin review panel thingy best, but that doesn't alter the fact that I also support the OP's proposal. --Floquenbeam (talk) 14:17, 15 January 2015 (UTC)
  • Without controls, this proposal will mean that admins can no longer block for disruption or patrol venues like Arbitration Enforcement. Otherwise, once they have sanctioned a critical mass of editors, they will be subject to interminable, retaliatory desysop proposals. If you do something like this, there needs to be at last one restriction: (1) editors may not propose or comment on desysop proposals for any admin who has ever sanctioned them. Probably there should be a second restriction: (2) any editor sanctioned within the last year, and the sanction was not lifted as an error, may not propose or comment on desysop proposals. We can not let editors prone to disruption use a desysop process to create more disruption. On balance, I think our system using ArbCom is lousy, but the best one possible. Jehochman Talk 14:52, 15 January 2015 (UTC)
  • Oppose as written - Multiple editors have noted that, without significant restrictions, a community-based recall system would mean that admins who take part in activities such as blocking for disruption would face recall from disruptive editors. A community-based recall system that had restrictions sufficiently strong to avoid that problem might be so complicated that it didn't work. Unless I see a community-based recall system that already contains provisions that protect active admins from being desysopped by disruptive editors, I have to oppose. As it is, without seeing what the fixes are, community-based recall gives the lunatics the keys to the asylum and puts the employees in straitjackets. (In a few cases, "lunatic" isn't a figure of speech. A few disruptive editors really are crazy. Most just act in good faith and don't understand collaboration) Robert McClenon (talk) 16:04, 15 January 2015 (UTC)
  • Support; an actually sensible and workable admin recall proposal! I would agree with DGG's sentiment that there is at least one editor who I recently opposed at RfA who I would have certainly supported had a binding community recall process been available. I trust that the bureaucrats will discount obviously invalid or grudge votes at a recall. That is why they are elected to the position they are: they should know how to judge consensus when promoting admins, and should know how to judge it when removing admins as well. StringTheory11 (t • c) 20:24, 15 January 2015 (UTC)

All of these are good points. I am trying to improve the overall setup in the below posts, and I hope I encapsulated everything. If I did miss something let me know. I mainly put this here to get the ball rolling; I think this proposal is doable with the right input and caveats, which will give us a much better community process. Tivanir2 (talk) 16:16, 15 January 2015 (UTC)

I was actually inclined to support the above, but the tweaks below lead me to a rather different inclination - so I don't think I have a view. You might be getting ahead of yourself with the tweaks maybe. Ncmvocalist (talk) 12:20, 17 January 2015 (UTC)
  • Oppose i used to be strongly in favor of a community-based binding recall process for admins, but I have come to realize that such a thing would inevitably have a chilling effect. We would see good, bold admins who deal with problems head on being constantly challenged by the vocal minority who basically hates all admins and thinks we are all corrupt. Good admins would end up walking away rather than facing these constant challenges, and we'd be left with milquetoast admins scared to do anything real. (yes, these do exist, in larger numbers than you may think)
Additionally, having participated in arbcom desysyopping proceedings both as a filing party and an arbitrator I find that this process actually works pretty well. In the case I brought to the committee I came correct, I had evidence of recent misuse of the tools and evidence that said misuse was part of an ongoing pattern going back some time. It is only when you have such evidence that an admin should be removed, and they were. And during my term as an arb we removed several other admins who showed a pattern of poor judgement. Is it a perfect system? No, but it is better than this idea. Beeblebrox (talk) 21:05, 18 January 2015 (UTC)

Tweaks to the above

Given input and good information people have brought up I propose the following to help streamline it a bit more. The new system will require:

  • 60% threshold to remove an admin
  • will consist of at least 30 (down from 100) editors who have contributed at least 1,000 main space and conduct related boards
  • no individuals may vote in any decision of an administrator that has performed a block or other administrative action towards them within the last six months (down from one year) (they may include evidence for reference to establish a timeline)
  • the boards will be 200 (down from 500) words and 20 (down from 50) posts for the originator
  • 200 (down from 500) words and 20 (down from 50) diffs for the admin plus additional space to rebut any other individuals that present evidence
  • 100 (down from 200) words and 10 (down from 20) diffs for any additional people presenting evidence

If it appears that administrators are being targeted for action due to a dispute the community may vote to nullify the request. This will take:

  • 15 editors that have not interacted with either party
  • The discussion shall be closed by a group (at least three) editors that have not weighed in, and only after a minimum of 7 (down from 14) days. Unless the clear consensus is landslide (90%+) at 7 days, the process should run 14 (down from 30) days to allow the maximum number of particapants to weigh in on the behavior discussed.
  • If the admin has participated in areas with WP:DS all editors for that article shall be unable to vote in the current proceeding. This applies to all articles within the last six months. These editors may still present evidence.

The filer will be sent to ANI for disruption and/or tenditious editing. No events with fewer than 30 participants will be considered passed (so we have a threshold of at least 100 editors) and IP users will, unfortunately, not be able to vote due to SPI concerns though they still may offer evidence and comments for others to consider. Thoughts on the slightly updated and more defined process? Tivanir2 (talk) 16:06, 15 January 2015 (UTC)

I actually think 60% is too high. 50% would be better, and I could probably get behind 40%, with proper convincing. :-) After all, if only 40% of the community is behind you, you probably shouldn't be an admin, and even if it's as much as 60%, that's significantly under the discretionary range for passing an RFA. I think a year is too much -- 6 months would be better. I'd also suggest cutting out the hard limits here - they're either too high or too low, and I'm not sure which. --SarekOfVulcan (talk) 19:47, 15 January 2015 (UTC)
We can always modify the numbers as people weigh in. If 6 months seems more reasonable than a year on consensus we can always modify that. If people can come up with hard numbers that meet consensus I am more than happy to modify my tweaked version. I view this entire process as draft and revision not necessarily a finished product as it needs more input before put into motion, since at a minimum I think we need to have a larger community input altogether before we declare it a viable process. Tivanir2 (talk) 20:20, 15 January 2015 (UTC)
I would add something, although I'm not at all sure of the phrasing, regarding not allowing participation by individuals who have been on "one side" of an argument in which an admin acted to block or ban a problematic editor. Some of our most contentious disputes really are of an "us vs. them" type, at least at some level, and allow reprisals from friends of a blocked individual would be very likely. John Carter (talk) 20:31, 15 January 2015 (UTC)
Would an expansion to include editors that have been in any articles under DS being disqualified except for evidence phase as well alleviate these concerns? I am trying to keep this as unrestricted as possible while making sure we don't have gaming of the system. Or we could put that any specific matters that happen in DS articles are referred to ARBCOM, which would prevent us eliminating their load but it should still reduce it significantly. Tivanir2 (talk) 15:06, 16 January 2015 (UTC)
But what color will you paint the bikeshed? And have you reviewed the dozen or so previous, similar, and rejected or failed proposals listed at WP:RFDA, to see which wheel you're reinventing? TenOfAllTrades(talk) 21:08, 15 January 2015 (UTC)
For the most part I can see that people want some sort of process, it is hammering out the process that is the problem. Overwhelmingly it seems from the last few attempts that the idea of a select commity is a bad plan, and I have avoided that thus far. There does need to be a way to limit the battleground attempts which will be worked on in the near future. I am willing to spend time on this for the sole fact that people know there is a problem, figuring out how to tackle it is harder. Compromise and weighing which ideas are considered the most acceptable are going to be key with this I believe, which is why I fully expect this draft to change multiple times before it becomes a full up idea. Tivanir2 (talk) 14:58, 16 January 2015 (UTC)
The community has been around this merry-go-round many times before. When you say that "people know there is a problem", can you be specific about what the problem actually is?
  1. Is the problem actually that the existing procedures for desysopping don't work (or can't easily be made to work)?
  2. Or is the problem that many editors aren't aware of the flexibility and power of existing procedures, and are just failing to use them appropriately?
  3. Or is the problem a perception that not enough editors are running/succeeding at RfA, and a new desysopping procedure is hoped to be an effective scheme to recruit more admins?
  4. Or is the problem that admins are too big for their britches, and we need a new process to threaten them a bit more often?
  5. Or is the problem that writing policy is fun, and there aren't very many opportunities to do that now that this project is relatively mature?
I have a strong suspicion that problem #2 is being too-frequently mistaken or misunderstood as being problem #1. Problem #3 – RfA isn't turning out enough new admins – is often mooted as being a consequence of #1, but it might constructively be fixed by solving #2. (And it doesn't address the effect that a loud and unpleasant new desysopping process will have on the number of RfA candidates.)
While almost nobody will admit to being motivated by #4 and #5, they make their own contributions to the pro-desysopping-scheme faction. (Before someone jumps in to say that I'm not assuming good faith, I will note that #4 has been specifically asserted as a valid justification during previous discussions of desysopping schemes. As to #5—well, you have to admit that anyone who hangs out at at the Village Pump has at least a bit of policy wonk in them.)
I'm just going to leave you with a link to User:TenOfAllTrades/CDAresponse. It's a critique that I wrote four (almost five, now!) years ago of another failed desysopping proposal (community de-adminship: Wikipedia:Guide to Community de-adminship). Not all of those criticisms apply directly to your new proposal, but it's going to hit a bunch of them. Some of the criticisms are actually more potent today. Fundamentally, I believe it very likely – and history supports me – that any open-voting-based desysopping scheme is going to have insurmountable flaws with respect to fairness and function. I hope that the community will continue to recognize that when faced with these types of proposals.
Time would be much better spent educating editors who are concerned about hypothetical (or even real, specific) "problem administrators" about their existing options under current policy. Solve the real underlying problem, Problem #2, rather than constructing an elaborate, unpleasant, and destructive new process. TenOfAllTrades(talk) 00:57, 17 January 2015 (UTC)
I went through the proposals of the past and it seems with all the recent ones the community as a whole liked the idea of having more control and ownership of the process, as long as it didn't boil down to another small subset of editors like ARBCOM calling the shots. Responses to the above 5 points
  1. It isn't so much that the current system doesn't work; the original schema design was that ARBCOM wasn't suppose to handle admin problems, there just wasn't an alternative.
  2. Again not so much an issue but when an ARBCOM member themselves brings up that they took the role because the community couldn't deal with it under what existed at the time, doesn't mean you stop trying to fix the process. It means you spend more time getting it right to me.
  3. I think it would help for recruiting but that is more a by product than an actual no kidding priority.
  4. I don't think I have ever truly had a negative experience with an admin, and the only time I was even warned was from a technical problem on my end and not behavioral. Threatening other people is bad so not sure what you were going for on this one.
  5. I find writing policy to be excrutiatingly painful (disclosure I am a mid rank in the military - policy crap is my life) so it is by no means fun. This actually came about because I am following the ARBCOM case for the gamergate article. I saw it on the ANI boards when I took a gander at them, started reading the article (which was a mess, but the draft is getting better), and wanted to help contribute to cleaning up readability and overall setup which of course led me to taking an interest in the case. It was the proposed decision talk page that had me land here, I don't watch this section routinely. Tivanir2 (talk) 21:00, 19 January 2015 (UTC)
I'm not a big fan of the whole "presenting evidence" thing. That just sounds too much like an ArbCom case. If you need 50 diffs to explain what someone did wrong, then it's probably too complicated an issue for the community as a whole to handle. With the originator, plus rebuttal, and other evidence, you're talking about the equivalent of 3-4 printed pages of single-spaced text, not counting all the diffs. And with a process that can last as long as a month, it barely even resembles a "reverse RFA" anymore. That's longer than an ArbCom motion would take, and only a couple weeks shorter than a full case. At this point I don't see any benefit to this vs ArbCom and I'm struggling to think of a situation where a process like this would be useful. Blatant abuse can usually be handled quickly by an ArbCom motion. And for more subtle or long-running issues, I'm not sure I really have confidence in 100+ uninvolved users to individually research everything themselves. The only thing I can think of where this might be desirable would be a parallel to the US justice system where defendants can choose a bench trial (ArbCom) or a jury trial (community). But whether anyone would actually want to go through a community process rather than ArbCom or this would just be bureaucracy for its own sake, I'm not sure. If people had the choice between ArbCom or WP:CSN, I can't imagine many would have actually chosen the latter. Mr.Z-man 15:03, 17 January 2015 (UTC)
The big thing is that there are a limited amount of words that convey the right information for what is being presented. Evidence is as good a word as I can think of for proving misconduct. The numbers are of course flexible. I will modify numbers and see if that presents better overall. Tivanir2 (talk) 21:00, 19 January 2015 (UTC)
The problem isn't the terminology, it's the process. You're calling it a reverse-RFA, but except for the vote, it doesn't really resemble RFA at all. And as I said, I'm not really sure where this fits in. Obvious cases of abuse can be handled by AC motion quickly and non-obvious cases probably need more nuance than a simple support/oppose vote. ArbCom also has the benefit of considering the wider issues. You mentioned in another comment that you became interested in this as a result of the GamerGate case, but that's exactly the kind of case that would be a poor fit to this type of process, as the issues go far beyond admin misconduct. Mr.Z-man 03:01, 20 January 2015 (UTC)
  • Oppose - this is a solution looking for a problem, and while it's a good idea in theory, by the time the details are hammered out, it will be inferior to the existing process. ArbCom is very rapid to remove admin access when there's evidence of abuse. We should not create additional bureaucracy. If there's a problem with an admin, post the complaint to WP:AN to get feedback, and if there's a solid basis, somebody will file for arbitration. Jehochman Talk 17:48, 18 January 2015 (UTC)
With the removal of RFC/U it is somewhat easier but it still is a relatively long and painful process, especially with long term problems. I am not trying to turn this into a mess, more like a vote of no confidence if the community deems that an admin should be removed. If enough people weigh in against the proposal we can always regulate it to the dust bin of proposals. Tivanir2 (talk) 21:00, 19 January 2015 (UTC)
  • Oppose First it seems like this proposal has changed slightly every time I look at it; not sure I can support a proposal that hasn't fully settled down yet. While I used to be be in favor of such a system, I actually am no longer convinced of the benefit. We do have ways to remove admins already that work. If necessary we can go the community ban or just launch an RfC on a specific case. Even if a recall procedure has builtin guards against frivolous removals it also has to guard against taking the time for nominations from enemies that can force stress, inconvenience on a target admin. Giving such attacks a chance to wear and tear on an admin even if they will never directly succeed in getting a bit removed is something I worry about with any recall process. This approach seems to have a lot of the flaws of the former RfC/U process without all of it's protections, for example certified nominations etc. I'mu also not convinced that it will help much with the admin shortage issue. I don't recall that many close call RfAs lately, so any shift in vote because of the existence of a recall procedure would not change the outcome that much. I also worry that a recall system might get in the way when the removal of admin bits required greater speed. PaleAqua (talk) 23:25, 19 January 2015 (UTC)

Alternatively, Facilitation Group

ArbCom is an elected group of trusted users. They reliably desysop admins who have committed abuse. However, the typical user is reluctant to file an arbitration case. How about we create an informal group of experienced users who would review complaints of admin abuse and then file arbitration cases when warranted? This could be a WikiProject dedicated to improving admin conduct. It would not create any new hats or mandatory bureaucracy. It would simply help users navigate existing process which works well when used correctly.

As an example, I recently found several users complaining about and admin Wifione. There were counter complaints of personal attacks, hounding, etcetera. To resolve the dispute I wrote up a request for arbitration. That was accepted and is being heard. This process has been smooth and relatively stress free. Parties on all sides of the issue seem to be happy with the process. Jehochman Talk 14:18, 17 January 2015 (UTC)

I support such a proposal as long as it doesn't add any bureaucracy, such as requiring users to use this vwenue for filing an ArbCom case. עוד מישהו Od Mishehu 16:54, 17 January 2015 (UTC)
To be clear this is not mandatory. Anybody can go directly to ArbCom if they wish. Jehochman Talk 17:02, 17 January 2015 (UTC)
This suggestion – while well-intended – makes me rather twitchy. The community did not have a good experience with the Association of Members' Advocates (WP:AMA, 2004-2007ish)—a volunteer group that nominally provided assistance to editors navigating the arbitration process. Wikipedia:WikiProject Administrator (2009-2011ish) – which nominally had admin improvement as its goal – never really managed to complete anything concrete beyond filling up WP-space talk pages.
The recurring problem is that these sorts of projects and groups tend to attract editors who variously have a fondness for process-wonking, hat-collecting, ax-grinding, and/or shit-stirring. Historically, the editors who enthusiastically volunteer to participate in this sort of thing often aren't the editors with the skills, temperament, and inclinations that are called for to have productive, constructive output. Editors volunteer in good faith without realizing the level of skill or commitment of time required to follow through, and then drift away.
The number of admins who are desysopped (or credibly, plausibly considered for desysopping) in any given year is currently quite small. As I noted above, we had maybe half a dozen instances in the last year that involved an ArbCom case, motion, or filing (causing a resignation). Not all of those are going to involve parties that need or want the assistance of whatever new group is formed. If there's a case only once every couple of months (at 'best') then what? Does this group become a shoal of circling hammers, desperate to pounce on any nail – or screw, or thumbtack, or confused marshmallow – that comes along? Will there be a pressure (internal or external) to increase the number of desysoppings considered, advanced, or attempted just to maintain the interest and activity of the group?
Speaking generally and as a matter of principle, I applaud and wholeheartedly approve of providing assistance to good-faith editors who have difficulty navigating Wikipedia's more arcane processes. In practice, we've long seen that such assistance often comes with hidden costs —to which the project and, in particular, inexperienced good-faith editors may be vulnerable. TenOfAllTrades(talk) 22:06, 17 January 2015 (UTC)

Curtailing Maintenance Template Spam

In the last few years I've noticed a profusion of maintenance template spam. At first we had maintenance templates that would warn readers about serious article defects, such as {{COI}}, {{NPOV}} and {{notability}}. These warnings served a purpose: to help prevent readers from placing too much reliance on questionable articles under development. Over time, more and more maintenance templates have appeared, such as {{Lead too long}} and {{lead too short}}. I propose that we establish a guideline that maintenance template should only be placed on articles for serious problems. Minor style issues, such as length of the lead, should be noted on the article talk page. There's no problem if the talk page suggestions are free form text or a predesigned template. The important thing is that we don't damage the user experience by cluttering articles with maintenance templates about relatively minor issues. Jehochman Talk 17:33, 2 January 2015 (UTC)

Interesting thought, though it would beg the question of what constitutes a major vs. minor issue. DonIago (talk) 18:49, 2 January 2015 (UTC)
It would be a great idea to cover that in a Wikipedia:Maintenance tags guideline. We don't need to presuppose the results. When there is a disagreement among editors, they can discuss it and then record the result in that one place for all to see. Jehochman Talk 20:57, 2 January 2015 (UTC)
  • I'll also note, after the attempt to move {{Orphan}} tags to the talk page, it gathering consensus, and then consensus being overturned because it has been established that maintenance tags can not feasibly be moved and maintained on talk pages. None of our bots or tools support it, and it has already been stated that since a major rewrite of the tools and bots would be required to do so, it isn't likely that is going to happen.
This doesn't mean I'm saying that reducing these tags are a bad idea or changing the way they are show is a bad idea. It shouldn't be very difficult to make the same kinds of adjustments to other templates as the ones made to Orphan so that they will be hidden with css after a certain amount of time so that they aren't seen in general most of the time except those users that want to see them such as WP:GOCE members perhaps.
Which makes me think, I'd really like to hear from the WikiProjects that use these tags. I've no idea which projects use which tags, but if someone can post a "please see" on the talk page of any project that might be interested, that would be great. I'll get WP:GOCE. :)
Another possible idea to filter these tags is to have some kind of WikiProject that is focused on the user experience (does one already exist?) that ideas for new maint tags could be proposed to. The project could assist in proper development or try to explain why the proposal would never work in a friendly manner. — {{U|Technical 13}} (e • t • c) 14:16, 3 January 2015 (UTC)
Since when were maintenance templates supposed to "warn" the reader? I always thought the purpose was to identify issues for interested people to fix (if the tagger doesn't feel able to fix it themself), and to point out to readers something they might be able to do and so possibly get them to become an editor. Anomie⚔ 01:03, 4 January 2015 (UTC)
  • I thank Jehochman for bringing this up, it's something that's been obthering me ever since our community driven initiatives to clean up and improve New Page Patrolling were wrested from us by the Foundation. Admittedly they then gave us the excellent new New Page Feed and its associated Curation Tool, but after nearly 2 years of empirical operation some tweaks and improvements are desirable. The downside is that while occasionally the WMF devs will step in to repair bugs that cause downtime or malfunction, the Foundation considers this suite of software to be complet(ed) and will apparently not entertain according dev time to it.
As one of the most experienced users of it and well aware of its deficiencies, if I were a programer I would simply boldly rationalise those tags myself. Many of them are hardly ever used and the number of them originally grew when WP:Twinkle (and before that, WP:Friendly) was still the standard script for tagging at NPP and new things were added to it in GF on simple request to Azatoth who, if I correctly recall, is/was the main developer of Twinkle. I would gladly work with Jehochman or someone together to reduce these templates to a sensible and manageable number. I seem to remember doing some work on this some years ago with DGG but I can't locate the project it was part of. There may be something to be gained by looking at this. --Kudpung กุดผึ้ง (talk) 04:34, 4 January 2015 (UTC)
@Anomie: & @Technical 13:: Maintenance tags serve both purposes: to alert regular maintenance editors/projects to address the issues, and to warn readers that the content may not be factually accurate and invite them to do some editing. WP:NPP is quite extensive as a tutorial for patrollers ({{U|Scottywong and I wrote/rewrote most of it) but at the expense of keeping it as short as possible - and it's already long - we didn't address the use of the many maintenance tags, concentrating mainly on training the patrollers to get their CSD tagging correct and accurate. There was a project some time ago, again with DGG to make the texts of various tags less bitey, and we rewrote many of them. There was also some AB testing but I don't believe it was ever conclusive.
The solution to all of this of course is to improve the quality of patrolling and that may ultimately mean introducing some criteria of competency and experience such as we have for AfC and even uniforms to wear for rollbackers and PC reviewers. IMO, NPP is by far the most important of all our quality controls. --Kudpung กุดผึ้ง (talk) 04:50, 4 January 2015 (UTC)
  • Thank you all for your comments, especially Kudpung. I'd be happy to work on a list of the issues that we do need to warn our readers about. Mere style issues, such as length of the lead, sections that need expanding and so on could be relegated to the article talk page. We exist for the reader. We want to provide them a good experience. We shouldn't distract the from their reading with warnings about non-critical issues. How to best accomplish this I do not know, but defining the list of critical issues would be a good place to start.
This discussion is interesting, but let's not limit ourselves artificially. We have other choices beyond "display a big box in the article" and "display a big box on the talk page". For example, there could be a small indicator somewhere on the article page when an article has been tagged as "having issues". Clicking on this indicator could inform a reader that the article is out of date, that it is in need of copy editing, or that it is poorly referenced (these are just examples; we may want big boxes for some kinds of problems and a smaller indicator for minor problems). A regular non-logged-in reader of Wikipedia might not bother with clicking on, or even noticing, the indicator, but the tags behind the indicator would properly place the article in (hidden?) maintenance categories. Maintenance-oriented editors could use a Gadget to make the issues appear in a more visible way within articles, just as we can use CSS to display various errors that are not visible to civilians. – Jonesey95 (talk) 06:00, 4 January 2015 (UTC)
I agree here, but I would regard such things as being out of date as significant. Perhaps all the templates could be redesigned with a little less visual emphasis. I think moving "orphan" should be revisited, but at least this should be the sort of thing which could go into a problems section. I'll try to give a more specific proposal in a day or two. DGG ( talk ) 06:06, 4 January 2015 (UTC) .
I'm liking this alternate proposal too. Rather than changing the tags just change the display to be less "frightening" or "bitey" to newbies. 104.32.193.6 (talk) 20:28, 4 January 2015 (UTC)
Perhaps the maintenance templates could be reconfigured to be collapsible, with a brief messge by default and a fuller explanation available should one choose to view it? DonIago (talk) 15:55, 7 January 2015 (UTC)

Thanks for pinging the Guild of Copy Editors, with its never-ending backlog :-). There's an excellent essay on tagging (particularly the overtagging section) that would work as a guideline. All the best, Miniapolis 15:23, 4 January 2015 (UTC)

Responsible tagging is another good essay which discusses particular tags. Miniapolis 15:27, 4 January 2015 (UTC)
  • Personally, I would prefer to have all problem tags on the article page itself. This makes it much more likely that someone will do something to fix the problem (certainly I have been motivated to fix problems in articles because I have been embarrassed to see tags on them) and also much more likely that when the problem is fixed the tag will be removed. Yeah, a finished, polished publication shouldn't have such glaring tags on it, but if an article is a work in progress, then I think the motivational benefit outweighs whatever frowny faces are made by people who remain readers but not editors. Some people appreciate the transparency and a peek behind the scenes, anyway. I don't mind the idea of making the tags a little less glaring as a compromise between the ugly factor and the helping-out factor. -- Beland (talk) 16:24, 12 January 2015 (UTC)

Social space

Awhile back, I complained at WP:VPP about what I saw as misuse of Reference Desk. Too often, I felt, responders engaged requests for opinion, and my attempt to hat one such thread resulted in a minor shit storm. I was told, basically, to relax, which I did.

Additionally, RD threads often digress into tangential banter that has little to do with the OP's question. In that respect RD is often a local Facebook or chat room. This has also been a problem for me in the past, but I have mellowed there, too (and have occasionally participated myself, especially recently).

I now feel there's nothing wrong with a desire to engage in unproductive conversation with fellow Wikipedians, provided one doesn't overdo it. It would provide a needed release valve and allow us to interact outside the "work" environment (same concept and purpose as a happy hour). It would likely reduce such activity at RD, which would be good for RD. As far as I know, there is no talk space specifically designed for that purpose. Could there be? Should there be?

Please don't refer me to something off-wiki, such as an IRC channel, or suggest the creation of one. Very few people would bother going there, they just need a quick break from editing and click on RD in their watchlist. I certainly wouldn't. ―Mandruss ☎ 22:47, 20 January 2015 (UTC)

@Mandruss: I've noticed this sort of thing happens on some user talk pages as well in discussions that start off about some article or topic. Here's an example between myself, Crisco 1492, and Curly Turkey. I generally agree that it's healthy to occasionally engage in a little banter or joking around to loosen things up from the sometimes serious and taxing work of building an encyclopedia. I think many editors would acknowledge these kinds of interactions happen on a lot of spaces on-wiki, not just user talk pages and on the reference desk. I guess the question is, would it be so different or disruptive if we formalized a place for this kind of interaction? I anticipate some folks will argue WP:NOTFACEBOOK and say that such a space is a distraction. And I get that-- we don't want folks to come here simply to socialize. But we've been allowing these discussions happen on the ref desk and talk pages for a long time, and I still see a lot of these same editors doing the hard work. I, JethroBT drop me a line 23:46, 20 January 2015 (UTC)
Yes. If we're going to allow it, and I think we should allow it, then provide a space where it's legitimate, obviously subject to WP:NOTHERE. That's pretty much the thrust of my comments. ―Mandruss ☎ 00:05, 21 January 2015 (UTC)

Struck the beginning of my comments, which had nothing to do with this issue. (Sigh. I need a break at Wikipedia:Happy hour!) ―Mandruss ☎ 01:07, 21 January 2015 (UTC)

Wikipedia:Wikipedia is a community bears on this question. Those short on time could read just the Jimbo quote near the top. ―Mandruss ☎ 01:07, 21 January 2015 (UTC)

  • I wouldn't hold my breath waiting for any sort of change to the way the refdesk works. I tried to talk about changing it in 2013, see Wikipedia:Reference desk/Refdesk reform RFC. The overwhelming response from those that are regulars there could be best summed up as "if it ain't broke don't fix it". They didn't even want a notice on the page clarifying that it isn't really part of the encyclopedia and apparently not subject to the same rules as every other part of WP. Some people like that it is often a free-for-all that bears little to no resemblance to an actual library reference desk, in that librarians will refer you to the relevant material to answer your question instead of just making stuff up or taking wild guesses at what the answer might be. Beeblebrox (talk) 01:48, 21 January 2015 (UTC)
I hear you. But I think this is worth doing even if it has no effect at all on RD. Any improvement to RD would be gravy. At the very least, one would have a new option when a thread degenerated into nothing but banter - Take it to Happy hour!. Anyway my main motivation here is not to reform RD. That's an important issue, but a separate one. ―Mandruss ☎ 02:04, 21 January 2015 (UTC)

RfC: Simple easing of RfA

There is clear consensus against this proposal. Non-admin closure. Oiyarbepsy (talk) 00:04, 22 January 2015 (UTC)

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

Various proposals for major RfA reform have failed. I propose a simple easing of existing guidelines. The RfA page currently says "Consensus at RfA is not determined by surpassing a numerical threshold, but by the strength of rationales presented. As a rule of thumb, most of those above 80% approval pass; most of those below 70% fail; the judgment of passing is subject to bureaucratic discretion (and in some cases further discussion)". I propose simply lowering the guidelines by 5%. This would not alter the fact that RfA's are closed primarily based upon the strength of rationales presented. This change would reflect the fact that we have plentiful votes to block inappropriate candidates, and it would encourage a slight easing of when a close should consider applying default-pass or default-fail. Alsee (talk) 14:45, 9 December 2014 (UTC)

Discussion (easing RFA)

What fraction of past RfAs would fall into this newly-broadened range? How many RfAs – from, let's say, the last couple of years – would have landed in the new 65-70% window?

And of those, how many of those RfAs did not present legitimate concerns that might incline a 'crat to reject the candidate anyway? If the intent is to extend the window over which 'crats can exercise discretion (practically speaking, to allow 'crats to exercise significant discretion which they were strongly discouraged from doing before) how many candidates would actually have been 'saved'? TenOfAllTrades(talk) 16:02, 9 December 2014 (UTC)

Can you clarify how this would change anything? The current wording states that bureaucrats typically pass users with above 80% approval, not that they always approve candidates above 80.00% approval regardless of anything else. Changing this by 5% would appear to just be misrepresenting what actually happens. Sam Walton (talk) 23:21, 9 December 2014 (UTC)

The idea is that closers still apply the same evaluation of arguments and weighing of merits (with the ability to reject based on a single powerful argument), but that when numbers inevitably do get looked at it would gently shift the thought process on what did or did not constitute a borderline case. Alsee (talk) 08:55, 11 December 2014 (UTC)

This would hardly make any difference in numbers passing. Graeme Bartlett (talk) 03:51, 10 December 2014 (UTC)

The proposal is deliberately small, intended to be as unobjectionable as possible. And my thinking was that an increase in the number of applicants might be more significant than any direct effect from the pass-rate itself. Alsee (talk) 09:13, 11 December 2014 (UTC)

Goodness. In the real world, some elections for much more important, influential positions than Wikipedia admin are decided by a simple majority vote. I've always felt that 80% is much too high for a rather minor position on the broader scheme of things. --Biblioworm 23:00, 24 December 2014 (UTC)

Plenty of people pass below 80%. It is a rule of thumb. Chillum 23:09, 24 December 2014 (UTC)

Support (easing RFA)

  • Contrary to what is suggested below, the appointment of five new admins in November might be a statistical blip. The overall number of admins appointed this year is still down more than 35% on last year, with less than 19 days to go. November was preceded by an unprecedented two month period during which no admins were appointed. Unless another six admins are appointed in the next 18 days (plus a number of hours), we will have a worse performance than 2012, our previous nadir. To say there has been a miraculous recovery may be premature. James500 (talk) 07:35, 13 December 2014 (UTC)

Oppose (easing RFA)

  • Oppose – Ideally, we'd move completely away from this idea of numerical approval numbers. These should be like any other Wikipedia discussion, not determined by percentage, but by the strength of what people say. The idea of "reducing the threshold" implies we should have a numerical threshold at all, and I'm opposed to that. RGloucester — ☎ 23:20, 9 December 2014 (UTC)
  • Oppose per RGloucester. — {{U|Technical 13}} (e • t • c) 23:48, 9 December 2014 (UTC)
  • Oppose. I agree with Samwalton9 and RGloucester. This proposal appears to be based on a misunderstanding of the numbers' significance (which the suggested change would promote). —David Levy 23:58, 9 December 2014 (UTC)
  • Oppose A rule of thumb should not be made authoritative which while not perhaps the intent of this proposal, would unfortunately be it's impact. I've seen an RfA with 69% go to bureaucratic discussion not that long ago, there is some flexibility in the system. PaleAqua (talk) 00:10, 10 December 2014 (UTC)
  • Oppose per RGloucester. Steel1943 (talk) 03:53, 10 December 2014 (UTC)
  • Oppose - I think RfA is currently doing a grand job and that the bar is not too high. A lot of people claim that the worst admins were those who were appointed pre-2007, the watershed year. Therefore, if the criteria have got tougher since then, those who regularly complain so loudly, bitterly, and oft uncivilly about admins in general should be content. Even with the higher post-2007 criteria, some unsuitable editors scrape through the process and then have to be relieved of their tools again later; even those who have aspired to Arbcom membership or who are WMF employees. The thing that people fear most is the discipline at RfA which for many years was regarded by the community as a place where one could be as nasty as possible, Ignoring All Rules of common decency with impunity. Reaching its peak around 2010-2011, the polution has slowly but surely abated with November 2014 showing a bumper crop of new admins - almost a miraculous recovery. No, I don't think for a moment that we need to lower the bar. --Kudpung กุดผึ้ง (talk) 11:32, 11 December 2014 (UTC)
  • Oppose There is nothing wrong with the current process, as witnessed by the five successful RfAs in the last month.  Philg88 ♦talk 08:59, 13 December 2014 (UTC)
    • That's five out of six, and the sixth editor stopped editing entirely after being subjected to RFA. I'm not happy about a process that has lost us yet another experienced editor (this one with 25,000+ edits). Are you happy about that outcome? (Oh, wait, now that I've read your own comment at that RFA, maybe you actually are happy that we've lost another long-time editor.) WhatamIdoing (talk) 02:48, 16 December 2014 (UTC)
      • Admins need to be open to criticism. If someone leaves the project because they failed RfA then the community made the right decision. I failed my first RfA, badly. I took it okay. A few months later I was accepted. Chillum 22:57, 24 December 2014 (UTC)
    • This is just what I expected. There was a lot of talk about RfA inactivity and that led to a flurry of activity. Well, that flurry is over now. There are problems with the current process, as witnessed by the fact that periods of activity are brief. Mellowed Fillmore (talk) 16:03, 16 December 2014 (UTC)
  • Oppose especially in the absence of an easier de-sysopping process. Bureaucrats can already make someone an admin even if the overall support percent is lower than the minimum. Ca2james (talk) 16:39, 16 December 2014 (UTC)
  • Oppose I think that the current numbers, with the key point of bureaucratic discretion in making the ultimate decision, is a good standard. I support keeping it that way.--Slon02 (talk) 22:37, 24 December 2014 (UTC)
  • Oppose The current bar is reasonable. I think that closers of RfAs should consider the quality and basis in policy in each argument just like closers at AfDs do, the numbers would be far different. This is done to some degree but I would like to see "votes" be based in policy and defended if needed before counted. Chillum 22:50, 24 December 2014 (UTC)
  • Oppose Admins cannot be easily removed, so they should not be easily appointed. Townlake (talk) 00:15, 25 December 2014 (UTC)
  • Oppose The standards to be an admin need to stay high. To much can go wrong if the wrong person is given the responsibility. It is very hard to take away admin powers so the standards need to be high. AlbinoFerret 21:22, 26 December 2014 (UTC)
  • Oppose I'm unconvinced that lowering the % bar would produce a better outcome. First of all, I don't think the number is all that relevant. Bureaucrats have historically been granted ample discretion in promoting users with lower % than the usual based on their own judgements. That's why we don't have bots closing RfAs... Second, I think it is important that new sysops are promoted with ample community consensus. While we absolutely need more administrators, new administrators should still have to obtain ample support from the voters to be granted the bits. If we as a community decide we're being too picky with admins and need to lower the bar in some way, we should do so by being more forgiving to candidates in our voting, rather than lower the bar. Simply put, if the community doesn't fully trust a user to be a good admin, as determined by 'crats after a RfA, the user should not be promoted, period. If we're being too harsh, we should just stop doing so. Snowolf How can I help? 17:04, 27 December 2014 (UTC)
  • Oppose – I also believe that there is nothing wrong with the current passing standards. We can't make it too easy. United States Man (talk) 17:28, 1 January 2015 (UTC)
  • Oppose per Townlake: We need to make it hard to grant adminship to avert administrator corruption. --Mr. Guye (talk) 23:48, 7 January 2015 (UTC)
  • Oppose - RfA is flawed, yes, but the solution is most certainly not lowering the bar to entry. That would be putting lipstick on a pig in order to make things appear marginally better. Lukeno94 (tell Luke off here) 19:50, 14 January 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia:Lock down (WP:LD) and Wikipedia:Deadline (WP:DL) proposals

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The result of this discussion was NO SUPPORT... Closing per WP:SNOW Mlpearc (open channel) 22:22, 23 January 2015 (UTC)

Please place this proposal on the appropriate page if this page is not the right one for it or merge it with another discussion if there is one for this (not that I could find one).

Wikipedia:Lock down (WP:LD)

Seeing many pages and topics on wiki that need no further editing; especially topics on things and people that are outdated and/or diseased, the article just sits there in it's complete form without being needed to be edited any further. The only editing it would need is reverting vandalism or the removal of false information/nonsense which is really just another form of vandalism. All this is time consuming for editors who could be doing something else to improve Wikipedia.

Articles/pages like these in my opinion need to be permanently protected and saved. I am proposing this because let's face it: We can't rely on bots to always revert vandalism. Bots don't have the same capacity as a humans common sense to keep or remove content in an article.

I am also proposing this because when I leave Wikipedia for good, I don't want the risk of my work being destroyed. I put in a lot of time to Wikipedia creating and updating pages and dread the idea that it's prone to being destroyed. I'd have wasted my time and the same is true for many, many other editors.

But at the same time I (and most certainly the rest of the community) want to be very careful in going about this procedure. Suddenly locking an article when there are dozens out there with the intend of updating/improving it are denied it.

So this is how I'd propose a procedure to permanently save an article or any other page that no longer needs updating. For example an article about a film produced in say 1950. All there is that needed to be known about the film is there, including cast and crew, presumably retired or diseased and there is absolutely nothing more to add to (or remove from) the article. The article has had no activity for months or years besides vandalism and/or trolling. No discussion on the talk page has been made in months or years. The article has a history of having been given nothing but positive reviews for it's quality of info (not necessary, but highly recommended). A user seeing it in it's most complete form places a WP:LD tag, similar to a WP:AFD tag and proposes it be to be locked. A discussion in the proposal entry follows and if there is absolutely no objection from any party, then it should be locked. A user opposing an article or page's lock should give reasoning as to why he/she believes it will need updating in the future. This one opposition, if legitimate, should be sufficient to block any upcoming lock.

Similar to a protected or semi-protected article, there should be an icon on a page that has been locked after meeting the lock down criteria, so anyone wondering why it's not editable will see any discussion that followed and how to request a temporary unlock. If an article gets too many unlock requests in a short time span, say a few times every few months (for any legitimate edits keep in mind), a discussion should be started and the article proposed to be unlocked. This is in case an article has been mistaken to meet the lock down criteria. It's a mistake we can reverse.

Overall, locking article should become part of Wikipedia's greater lock down procedure. Because if an encyclopedia has met it's goal to keep the most reliable and best quality information, I see no reason to it being senselessly prone to vandalism or being open to edits; especially if people are too busy to guard it.

I don't edit wikipedia as often as I used to when i was here previously, so I won't be able to participate in this discussion very often but hope to see some contributions when i return here. --Nadirali نادرالی (talk) 20:27, 23 January 2015 (UTC)

  • Strong oppose - This is the same as full protection which is used sparingly and with a time limit. Articles are never finished. Just because you're done does not mean a brand new editor can't improve the article a couple years from now. There should be no barrier preventing this. --NeilN talk to me 20:58, 23 January 2015 (UTC)
  • Totally oppose. I can't envisage any article that couldn't potentially be improved, and I challenge you to think of one. Your existing example, of a 1950s film, would need to be updated every time someone wrote a book about 1950s movies, for instance. I can see a case for preserving "last clean version" links (which is already done for FAs and GAs - on the talkpage of each you'll find a link to the version that passed FA/GA), but certainly not to prevent anyone making changes. Your idea that there are articles that lie untouched for years is just not true - a very few articles have been untouched since 2008, but they're a tiny minority, and you won't find a single example on that list that doesn't need improving. Mogism (talk) 21:00, 23 January 2015 (UTC)
  • Again this is with regards to pages that need no further editing. It's not to prevent anyone from contributing, but for protective purposes. Besides the decision can always be reversed as proposed above. Besides who's going to look after so many things at once? Don't forget to comment on the second proposal. Thanks.--Nadirali نادرالی (talk) 21:05, 23 January 2015 (UTC)
  • Oppose: Re "pages that need no further editing", that can never be determined in any objective way. It's utterly impossible to foresee what good ideas for change people might have in the future, what things we think we know now might turn out to be wrong, or what further developments might happen that are relevant to what we might think today is "finished". Squinge (talk) 21:16, 23 January 2015 (UTC)
  • Absolutely not. Townlake (talk) 21:17, 23 January 2015 (UTC)
  • Oppose - However. In my less-than-vast experience, a typical article goes through a hot development phase, with multiple experienced editors massaging, refining, hammering out the tiniest of details. The article is polished. Then they move on, and I've yet to see an article see a net improvement from that point. Instead it's almost all casual drive-bys who prefer nice quiet articles where their chances of being reverted are far smaller. They "improve" a phrase that the experienced guys spent three days honing to a sharp edge, and the result is decidedly not an improvement. Even if I'm still watching the page, do I want to revert when I know I have no support around? When there's a real good chance I'll have to template the person two or three times and then take them to ANEW? No thanks, I'm busy doing something else and the cost/benefit just isn't there. So why should the experienced guys bother working so hard on it in the first place? This needs some kind of a solution if not this one. End rant. ―Mandruss ☎ 21:42, 23 January 2015 (UTC)
  • Oppose To echo the above, we already have an equivalent procedure in place, which is protection (semi- or full protection), and also something new may come up related to an article that is outdated. I'll give an example, an building structure related article has been abandoned because it is determined that nothing has happened with the building that the article was referring to, but suddenly, the structure has been given a new upgrade along with the rest of the city. Then the "abandoned" article is updated o finally reflect the new changes to that building. Not sure if this is the best example I've got, but I think you'll understand where I'm coming with this. Again, this is a work in progress because lots of things happen that would require updates to this particular site. Thanks. Sam.gov (talk) 21:50, 23 January 2015 (UTC)
  • Oppose I, too, would love to know which articles you consider "finished", and no longer in need of editing. Because I have yet to run across one. DoctorJoeE review transgressions/talk to me! 22:01, 23 January 2015 (UTC)
  • Strong oppose - a noble proposal, but misguided. The encyclopedia is never complete; articles are never finished. It would be frankly arrogant of us to say that we have all of the knowledge on a particular subject and can never conceivably improve it further. Ivanvector (talk) 22:07, 23 January 2015 (UTC)
  • (edit conflict × 2) Strong Oppose. An article can always be improved. This would just add extra complication to the process of making a few tweaks to a "locked" article. If this were to be implemented, we should change our "The free encyclopedia that anyone can edit" slogan to "The free encyclopedia that admins can edit". This reminds me of the "approved articles" over on Citizendium (which are supposedly "finished"), and although I'm sure Sanger set it up with good intentions, that project has been a relative failure in comparison to Wikipedia, probably because of the numerous restrictions and expert approval system. (See, for example, Citizendium's article on Italy, and compare it to our's.) Although this is not exactly the same thing, I feel that making editing more difficult would have similar results. (By the way, I suggest that this proposal be closed/withdrawn per WP:SNOW. I think this will probably go the same route as my "no oppose section RfAs" proposal turned out.) --Biblioworm 22:08, 23 January 2015 (UTC)
  • Oppose - We have WP:RFPP so not really seeing any need for this at all. –Davey2010Talk 22:11, 23 January 2015 (UTC)

Wikipedia Deadline (WP:DL)

Knowing that a lot of discussions/proposals on articles to be moved or POV/accuracy templates etc. don't get as many responses as they used to or the person placing these tags don't bring it up on the discussion page, I propose a deadline template be placed so people will know that proposals don't have forever. So say a person places a proposal tag to merge an article or rename it, he/she can also place a deadline timer with it that is no longer than three months long. Which means in three months if there is no response that user may go ahead with his/her proposal. This will help speed up thing on wikipedia. The deadline timer template on each day will tell how much time is left to oppose/endorse the proposal. Once a discussion is in progress, the timer may be switched off. And if the opposing party or parties ended the discussion without providing any sufficient reasons, then the timer can be re-instated.--Nadirali نادرالی (talk) 20:46, 23 January 2015 (UTC)

This is basically WP:BOLD with added unnecessary processes. Sam Walton (talk) 21:27, 23 January 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Search everything - including time search

Search "everything" does not yet include the possibility to include older versions of articles into the search. The search "everything" should allow this IMO (i.e. query the entire database). 67.83.63.86 (talk) 05:04, 23 January 2015 (UTC)

Well, I have some concerns about this. This would, for example, make copyright violations and spam searchable. Some of the stuff removed from articles and other pages was removed for good reason. Oiyarbepsy (talk) 04:07, 24 January 2015 (UTC)
Would probably also make search times insanely long. ansh666 07:00, 24 January 2015 (UTC)

You know, something like this might make sense as a script, or something that isn't inherently part of Mediawiki. Not needed most of the time, and I think Ansh is right about excessive search times, but there are certainly cases where it could be useful. Oiyarbepsy (talk) 07:09, 24 January 2015 (UTC)

Your concerns are all well taken. I was thinking about when people delete entire section (for various reasons such as censorship, by accident while editing the article, or else) in many articles (and for some important articles this happens more than you might think because not enough editors are watching or paying attention!? - I know first hand.) Cheers! 67.83.63.86 (talk) 01:19, 26 January 2015 (UTC)
There is a consensus for including a link to the Wikipedia Adventure in the welcome template. Some editors have expressed the opinion that a welcome template without such a link should remain available and I see no reason why that couldn't be so. Sam Walton (talk) 21:05, 29 January 2015 (UTC)

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

After a short discussion at Template_talk:Welcome, I think it's time to formally put this forward. While you can see some of my reasoning there, let me also explain it here.

The Wikipedia Adventure is an interactive tour designed to help new users learn the basics of editing Wikipedia "in under an hour". Although I have never taken it myself, since I'm a mostly self-learned editor (with the exception of my CVUA course), I gather that many new editors think that the adventure is good. Therefore, I think we should add a link to it in the Welcome template. Assuming that it is used, putting a link to this in such a widely used template will hopefully help new users settle in to Wikipedia faster. What does everyone think? (A proposed version of the new template can be seen here. --Biblioworm 21:07, 24 December 2014 (UTC)

Discussion (TWA)

That welcome message with all those links is a bit of a mess - does anyone know how many "tutorials" there are? (Just click on intro and getting started) - Perhaps some person or people can be bold in this regard and reverse a bit of the years of encrustation or rationalize organization. Alanscottwalker (talk) 21:29, 24 December 2014 (UTC)

One thing to consider when implementing this would be that there are many different welcome templates; see Wikipedia:Welcoming committee/Welcome templates for example. It would need to be decided which templates TWA should be added to. BethNaught (talk) 16:26, 26 December 2014 (UTC)

Doesn't TWA leave breadcrumbs on the user's account showing that they used it? If so, I'd argue that renders TWA more than a mere tutorial, and I'd be skeptical about pushing users toward it in the template without more disclosure about the record of its use that it leaves. (I'm refraining from opposing Biblio's idea wholesale because I have no problem with TWA itself; it looks useful on some level, though I would at least want a choice about being permanently labeled as a "TWA user" before jumping in.) Townlake (talk) 16:59, 26 December 2014 (UTC)

When you begin TWA, it warns you that it makes automated edits on your behalf, though indeed it does not specifically warn you that it will place badges on your user page. I don't think it's a problem, because the badges can be removed as with any other template. However, it may be worthwhile asking the TWA maintainers to modify it, say, such that you get a choice each time like: "Add badge to my user page" / "No thanks". BethNaught (talk) 17:07, 26 December 2014 (UTC)
Thanks for that. If the automated edits stay in the rookie's "User contributions" list, of course, they cannot be removed from there. That could be objectionable for some. Townlake (talk) 17:10, 26 December 2014 (UTC)
That's true, of course; they do stay in the contributions log. (See for example Special:Contributions/BethOne, where I did a test run. The whole process takes about 50 edits.) It does warn you that it makes edits before beginning, as I say. I don't think I would judge any TWA player adversely if their subsequent contributions were good (and I don't see why anyone should), but I can understand why you say what you do. BethNaught (talk) 17:15, 26 December 2014 (UTC)
Right, thanks for verifying. I wouldn't judge adversely either, but a real new user won't fully understand that warning and would wind up with a permanent "n00b Badge" in their contributions. In some corners of this project, wrongly or wrongly, that could cause the new user to be treated with kid gloves and pats on the head. Townlake (talk) 17:58, 26 December 2014 (UTC)
You have a good point, Townlake. That's actually one reason why I've never used it myself, since I don't want to be labeled as "the user who took that childish TWA when he was a newb". When I read Wolfowitz's MFD, I actually understood his point a little bit, namely the part about not wanting to attract immature children to this site. Despite the fact that there are some exceptionally mature ones, I've seen enough of them in my relatively short time here to know that it would not be in the best interests of the site to mass attract them and make them think this is some utopian MMORPG. --Biblioworm 18:08, 26 December 2014 (UTC)
Yes, Biblio, we're on the same page. To be clear, I like your proposal, and I don't want to overblow my concern here (honestly the "n00b Badge" would not be that big a deal), but I don't want there to be whiplash if the proposal is implemented and then new users are surprised. It only takes one or two malcontents to waste a lot of editors' volunteer time here. Townlake (talk) 18:13, 26 December 2014 (UTC)

Support (TWA)

  • Support: I have tested TWA myself. While I have reservations about the extent of gamification, presenting it as one of a set of ways to learn about Wikipedia is appropriate because it allows people to choose the style of tutorial they like. I think it provides an adequate primer to the key skills for Wikipedia. BethNaught (talk) 16:26, 26 December 2014 (UTC)
  • Support: I've used TWA on several new editors for the purposes of training, and I only see it doing good for new editors to get started with syntax, article work, and productive communication with other editors. It seems very appropriate to include on then Welcome template. I, JethroBT drop me a line 09:14, 10 January 2015 (UTC)
  • Support Pretty good idea, it would generally help with helping users learn the "Ropes" of sorts of Editing. And if they did it would show that they generally had a motive to edit constructively LorTalk 09:24, 10 January 2015 (UTC)
  • Support Good idea Doc James (talk · contribs · email) 02:26, 14 January 2015 (UTC)
  • Support I like the approach, there are certainly some new editors who will benefit from this --Kim D. Petersen 01:28, 16 January 2015 (UTC)
  • Support I see no problems. Definitely a good idea IMO. Cheers, --ceradon (talk • contribs) 01:35, 16 January 2015 (UTC)
  • Support. This is a helpful, entertaining, and fun way to introduce the project to new users who want to jump-start their learning curve right out of the gate. GenQuest "Talk to Me" 07:07, 16 January 2015 (UTC)
  • Support A link is a good idea. It may prove useful to new users and will make them aware that TWA exists. Sometimes it hard for new users to find what can help them and where things are. AlbinoFerret 14:30, 17 January 2015 (UTC)
  • Support I don't see any problems. The link would be useful because Wikipedia Adventure is a program that could teach editors how to edit and other things. I believe it could fit perfectly in the template because it would be beneficial for editors who never worked on Wikipedia before. I see that some opposing view points realized that registration may be required, but a link from the template would take editors directly there. Sam.gov (talk) 21:10, 20 January 2015 (UTC)
  • Support Wikipedia Adventure is probably one of the best editing tutorials out there, would love to see this, and it would prevent mistakes from new editors. ~HackedBotato Chat with me ♽ Contribs 18:47, 26 January 2015 (UTC)

Oppose (TWA)

  • Oppose because it requires users to register or login. 67.247.21.108 (talk) 23:55, 29 December 2014 (UTC)
  • Oppose unless and until it is converted to use the wikitext editor. There's no reason to encourage newcomers to use an inadequate tool.—Kww(talk) 02:48, 30 December 2014 (UTC)Apparently my conditions have already been met while I wasn't looking.—Kww(talk) 14:53, 31 December 2014 (UTC)
    • Kww, I don't understand this complaint. How do you think that edits like this and this happened, if not with the wikitext editor? WhatamIdoing (talk) 19:18, 30 December 2014 (UTC)
    • I'll confirm that all the editing took place through the standard wikitext editor. BethNaught (talk) 19:23, 30 December 2014 (UTC)
      • It might submit things through the API, so maybe that's what he meant. WhatamIdoing (talk) 20:27, 30 December 2014 (UTC)
        • The last time I played with TWA, it only demonstrated the use of Visual Editor, even though all edits it made were simulated and included edits that were impossible to accomplish using the actual Visual Editor. It even ran under Internet Explorer when VE couldn't execute under Internet Explorer. If that's changed, let me know, and I will withdraw my opposition.—Kww(talk) 22:11, 30 December 2014 (UTC)
          • I just tried it yesterday for the first time. If I remember rightly, it had me do a bunch of editing in the non-VE normal edit page (and didn't mention VE) — I'm running IE and have disabled VE, and nothing seemed unusual as far as I remember. I think the situation has changed. Nyttend (talk) 05:57, 31 December 2014 (UTC)
          • I believe that different projects have requested different default settings. I don't see anything in the non-talk-page edits that can't be done in VisualEditor, however. They're really quite basic. WhatamIdoing (talk) 00:42, 1 January 2015 (UTC)
            • Which isn't my point. VE is certainly capable of performing trivial edits, and can even do some moderately complex editing these days. Until it's complete, it shouldn't be taught to newcomers as the normal way to edit.—Kww(talk) 00:48, 1 January 2015 (UTC)
  • Oppose this is the only welcome template I use because I find it succinct and not terribly overloaded with links like almost all the others. It's short and to the point and currently doesn't include anything frivolous. Could we please keep it that way and add links to silly stuff like this to one of the other welcome templates instead? Beeblebrox (talk) 22:47, 24 January 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Suggestion for improving inter language pages: template for standard section names

[transferred from Help desk] ―Mandruss ☎ 17:13, 29 January 2015 (UTC)

I've been translating articles from the english Wikipedia and I noticed that there are no templates for creating the standard sections names, such as See also, References and External links. We must write ourselves those names in our own languages (eg: in portuguese they're called "Ver também", "Referências" and "Ligações externas"). It would be much better for the whole community if we could use a template like "{seealso}" (or an abbreviated one) in all the interwikis, so each section name would be translated automatically by the Wikipedia engine to the appropriated language. It would be similar to the Template:lang, but in the case of the section name it would need to write "{seealso}" without informing any parameters. It only brings advantages: revisors will not waste more time fixing errors on those lines, the translators don't need to worry about writing those lines in the correct form for each language, and it makes the inter language pages more compatible. That's my suggestion.Faltur (talk) 17:06, 29 January 2015 (UTC)

That seems fairly easily doable, except that all of the various language Wikipedias would have to agree on a standard title for the template. For example, to get "Ver também", do you type {{seealso|pt}}? And is it possible to host all the templates in one place, like on MediaWiki, or would they have to be recreated on all of the individual wikis? (I don't know the answer - this is out of my realm of experience) I guess it's a question of whether it's worth the effort, if you already know what the headers should be in your language and can just type them in? Ivanvector (talk) 17:20, 29 January 2015 (UTC)
Ivanvector, we will only need to type {{seealso}} without any arguments. This will create the See also section in the portuguese Wikipedia as Ver também, or in the english as See also, and so on. The section will be created where the person wrote it, the same way as {{reflist}}. There is another template which serves as an excellent example. When we translate tables containing a list of countries, we can use the ISO 3166-1 alpha-3 codes templates (eg: {{USA}} that returns  United States written in the language of the current Wikipedia). This template exists in all the Wikipedias and it facilitates a lot the translation of ranking tables. We can conclude that this template is portable between the languages, and it only brings advantages for the translators.Faltur (talk) 21:45, 29 January 2015 (UTC)


I see two issues: We have no standard names. The references section could be names References, Notes, Notes and References, Bibiliography and so on; see Wikipedia:Manual of Style/Layout. If a translator has issue translating "References" and "See also" then I would have to question competency. And yes, templates are per wiki, --  Gadget850 talk 17:26, 29 January 2015 (UTC)
Commons does this, for example c:MediaWiki:filedesc and c:MediaWiki:license-header that are used in section headings as e.g. == {{int:filedesc}} == However, as Gadget850 observes, we don't have standard headings, and this is noted at MOS:APPENDIX, and is the subject of recent discussion on its talk page, e.g. Wikipedia talk:Manual of Style/Layout#Works cited and Wikipedia talk:Manual of Style/Layout#Further reading. --Redrose64 (talk) 17:45, 29 January 2015 (UTC)
Gadget850, using the ISO 3166-1 alpha-3 codes templates as example, there are still many english tables which use {{flag|United States}} even if there is the portable version {{USA}} available! You are not going to be suppressed to give whatever name you choose for the section, simply because you will be free to do that. And, come!, everyone knows there are standard names for the pages (See also, External links, References) but they're not imposed by rules. Well, it's not true in my case, because one of the revisors have changed my "External links" (which was written as Portuguese: "Links externos") to the "standard" name (Portuguese: "Ligações externas", used in the featured articles). And this is what motivated me to make this topic. Faltur (talk) 21:45, 29 January 2015 (UTC)

Get rid of jpeg progressive load

hurts eyes, please ! I can see it or I can't , progressive its just a placebo no new/relevant information is there while loading an image — Preceding unsigned comment added by 190.178.84.72 (talk) 23:52, 19 January 2015 (UTC)

I believe that's down to the file being uploaded; is the thumbnail progressive? Or am I missing something? Adam Cuerden (talk) 11:05, 20 January 2015 (UTC)
Have you tested this with GPRS speed for a "mobile broadband" plan at modem speed after, say, 5GB/month are eaten up? –Be..anyone (talk) 11:44, 20 January 2015 (UTC)
I believe that progressive loading is used in Media Viewer. It does not seem to be an especially popular feature.
Media Viewer does not exist on the mobile website (en.m.wikipedia), only on the desktop site (en.wikipedia). Whatamidoing (WMF) (talk) 18:45, 23 January 2015 (UTC)
My laptop is connected to the Internet over "mobile broadband" (UMTS), I just got the "you are at 95% of 5GB" SMS (one week at commons, the next three weeks at GPRS speed.) But if the issue discussed here affects only the media viewer I'm off topic, sorry. –Be..anyone (talk) 19:20, 23 January 2015 (UTC)
You would presumably be getting the desktop website, if you're using your laptop. You can tell by looking at the URL. If there's a ".m." in the middle, then it's the mobile site. I've heard that there are a lot of readers who have switched to the mobile website for reading, even on their desktop/laptop machines, because they find it easier to read, and the preference is "sticky", so the only want to find out it to check your own system. (A link to either Mobile or Desktop view is at the very bottom of the page, if you ever want to see what the other looks like.) Whatamidoing (WMF) (talk) 23:40, 23 January 2015 (UTC)

Low resolution images would be better than low quality images. --NaBUru38 (talk) 15:44, 30 January 2015 (UTC)

Table editor with support for adding list of strings

This idea is for the official table editor.
Description: Users will be able to add a list of strings that will fit a specified column automatically. Example: I create an empty table, and now I want to add a list of numbers in a specified column. These numbers will fit each row automatically. If I added 10 numbers, starting from 1, then the table will have 1 column containing 10 rows with numbers from 1 to 10. Then I create a new column and select it, and I'll add a list of countries names, the same way as the numbers. And so on.
Note: the editor must support a list of templates too, because list of countries names may be added using ISO_3166-1_alpha-3 templates, such as {{USA}}, {{NZE}}, {{AFG}}. These templates are portable between all Wikipedia languages, so it's preferable to use them instead of {{flag|United States}}.
Advantages: This will make the process of creating and updating tables from multiple sources a lot easier and faster! Faltur (talk) 01:34, 1 February 2015 (UTC)

Proposal to auto-transclude /doc subpages

Most of those involved in the discussion seem to support the proposal. However, the issue I'm noticing in closing this is that the proposal calls for non-trivial and not-already-done development work (in contrast to e.g., pending changes, where the extension was already done by the time a proposal to activate it was raised). So, while I can say as a closer, "yeah, people seem to largely support the rough-draft idea," I can't really say anything beyond that.

The proposal calls for non-trivial extension and bot development, which would need to be undertaken either by volunteer developers or developers at the foundation. The latter (bot development) would also need to pass WP:BRFA. Therefore, while the proposal is supported as an idea, I can't positively affirm that the features or prescriptions proposed have final agreement for activation (that'd be putting cart before the horse).

A separate proposal/RFC once blocking development work (i.e., the extension) is done, tested, and ready for production use would likely be the best route to avoid any surprises. --slakr\ talk / 16:52, 3 March 2015 (UTC)

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

There are two fundamental components of a Wikipedia article:

  • content page, and a
  • talk page for discussion.

This pattern applies to most namespaces. But for a Wikipedia template, there are instead three (sometimes five) fundamental components:

  • template code, which is the actual wikitext and parameters, etc, to be transcluded into any number of articles
  • template documentation, which describes the template, why it's needed, how to use it
  • the talk page for discussion
  • occasionally, sandbox and testcases pages, the location of which I do not object to

Somewhere in the development of this encyclopedia, these three unique components have been squished into space for two components: the code-and-documentation, and the talk page. The template documentation is not given much of any actual accomodation in the Mediawiki software, instead being treated as just another template (a template that in reality will be transcluded into exactly one page). To accomodate this double function of the Template: namespace, we use lots and lots of nasty include rules: noinclude, onlyinclude, includeonly. This category applies to the host page, this category to the template itself. Virtually every major template has documentation, but still we don't think it's ubiquitous enough for an implementation more universal than pasting {{Documentation}} and include rules on every template page.

I want to propose that we automatically transclude /doc subpages. That is, make {{Documentation}} obsolete: it's used on pretty much every major template anyway, ubiquitous enough that it ought to be automatic. This would legitimize template documentation and also, I feel, encourage the composition of template documentation.

I don't know anything about Mediawiki on the software level, but implementing this seems like it should be easy enough:

  1. A knowledgable programmer makes an extension that inserts the contents of the /doc page at the bottom of the template page
  2. The extension is installed on Wikipedia AND at the same time, the {{Documentation}} template is blanked to remove redundancy
  3. A bot can remove all the calls for {{Documentation}} over time; this can be done at a leisurely pace because the calls are now nonfunctional

Moving forward

I would fancy that this move would occur as part of a larger change in Wikipedia's templates. I believe that the current squished two-namespace system is not the natural one. I believe that it involves unnecessary code, for implementing documentation, categories, and the like. I believe we should move toward a three-namespace solution, or at least some sort of Mediawiki software acknowledgement of a template documentation as something other than just another template. This could greatly simplify the code. Maybe some day, if we plan it right, some of the biggest and best templates, fully documented, with categories transcluded and non-transcluded, could have zero include rules.

I have pursued this movement in the past, culminating in a Village Pump proposal about a year ago which did not reach a positive consensus: maybe it was too much too soon, and not enough time to develop the idea before sending it out for approval. Here are a few relevant links:

I suggested "Template documentation:" as the name for a new namespace, but not everyone agreed that would be the way to go. Here were a few layouts suggested:

  • Template:Foo/doc (unchanged, ofc)
  • Template documentation:Foo
  • Documentation:Template:Foo
  • Help:Template:Foo
  • Template code:Foo (move the code here; the documentation would remain at Template:Foo)

The single measure I have proposed today (for which I can credit User:Anomie in the last proposal) would be a single step toward a three-namespace solution, however much discussion is needed as to if or how that solution would be implemented. But still, I believe what I have proposed today would be a beneficial move, even if no further changes are made. I ask that you vote on whether this single measure would be beneficial or not, and also give your opinion on whether we should start talking about reorganizing the documentation system as a whole.

Support (documentation)

  1. As proposer: − Thisismyrofl (talk) 06:29, 15 December 2014 (UTC)
  2. Support. The current system is unnecessarily clunky. —Swpbtalk 14:49, 16 December 2014 (UTC)
  3. Support Cleans up template code to do what everyone template should do anyway. Oiyarbepsy (talk) 05:58, 18 December 2014 (UTC)
  4. Support Though prefer a slightly different implementation. I'd rather see a system which in namespaces where it was enable would when generating the page for the templates would automatically include the contents of the document subpage if it exists and wasn't already transcluded. This means that other places that used the documentation template wouldn't break and if documentation needed to included a special way it still could. The existing documentation template wouldn't even need to change, just be removed over time from places it was no longer needed. If the automatically included contents had a CSS style applied it would be easy for editors that didn't want to see the documentation to hide it. Likewise some sort of magic word that disables automatic inclusion would be nice. This would make documentation very much like <reflist>. It in theory should also speed of transclusions of templates because the noninclude stuff for documentation wouldn't need to be parsed; granted it should be only a small amount of memory / time — but when considered with highly used templates probably adds up. I'd also actually like if an add/edit documentation button appeared in any namespace where an auto-include-documention feature was enabled. PaleAqua (talk) 18:30, 18 December 2014 (UTC)
    Technical 13 pointed out to me use of the Documentation template outside of Template and Module namesapces. I suppose now you're right that we can't "kill" the template entirely, as we have to keep it for those purposes, but couldn't we gracefully blank the template only in the namespaces we're modifying? Through wikicode namespace checks, or CSS if nothing else? Then we could delete all the calls for the template in those namespaces, and at a leisurely pace, to work toward the goal of less crap code. − Thisismyrofl (talk) 20:52, 18 December 2014 (UTC)
    It's one of the reasons I suggested a different approach. I don't know that modifying Template:Documentation would be necessary to stage out. As it is currently transcluded by a large number of templates not sure what churn that would cause, when it would be simplier just to slowly remove based on whatlinkshere etc. existing templates, preferable when other changes are made to the template. By using the approach I suggested there is no rush to switch everything all at once; if the document template is used there won't be duplicated docs as the automatic inclusion wouldn't trigger. PaleAqua (talk) 21:05, 18 December 2014 (UTC)
    You might be right. That's probably for the best. The documentation template has a few parameters that must be used at least some of the time. Best not to chuck it all at once. − Thisismyrofl (talk) 08:42, 20 December 2014 (UTC)
  5. Support a system that automatically transcludes /doc subpages in Template namespace, similar to what is already done for the Module namespace, but adding a check for existence of the /doc page in both namespaces. Weak oppose moving documentation pages to a separate namespace, as you propose in your user subpage. SiBr4 (talk) 18:40, 18 December 2014 (UTC)
  6. Support the general concept; but with the implementation more along the lines PaleAqua suggests - Evad37 [talk] 14:52, 20 December 2014 (UTC)
  7. Support the general principle. Templates as they are now are crammed and confusing. Gizza (t)(c) 07:21, 21 December 2014 (UTC)
  8. Support. This progresses Wikipedia as an encyclopedia. --Mr. Guye (talk) 23:53, 7 January 2015 (UTC)
  9. Support. Should have been done already; great idea. APerson (talk!) 14:41, 20 January 2015 (UTC)
  10. Support The number of templates that have no documentation is startling, so having it automatically transcluded would go a long way to improving this. --Ahecht (TALK
    PAGE    ) 15:02, 20 January 2015 (UTC)
  11. Support. --L235 (talk) Ping when replying 21:50, 30 January 2015 (UTC)
  12. Support – The idea seems to have some merit; I don't think I like the idea of a "template code" namespace or putting it as "Help:Template:" (those were two of the possible implementations), but the rest of the idea looks good to me. Dustin (talk) 22:15, 30 January 2015 (UTC)
  13. Support--GZWDer (talk) 16:00, 4 February 2015 (UTC)

Oppose (documentation)

  1. Oppose adding this directly to core; Oppose adding it as an extension; Support a gradual process resulting in an on-by-default gadget. — {{U|Technical 13}} (e • t • c) 20:04, 15 December 2014 (UTC)
    Oppose making display of content (any content) rely on JavaScript. Pathore (talk) 22:39, 24 January 2015 (UTC)
  2. Oppose, that suggestion should be vetted on a project where folks are supposed to grok /layout, /langs, /en, /ru, /he, /ar, /doc, etc., with a /doc managing its own zoo of translated documentations. Plus /sandbox and /testcases for hopeless imports from w:en: (red links, of course.) –Be..anyone (talk) 16:37, 31 December 2014 (UTC)
    @Be..anyone: I genuinely don't understand your statement in the slightest. Oiyarbepsy (talk) 00:52, 1 January 2015 (UTC)
    These are common template subpages on commons (partially also on meta), lots of languages, with a shared layout, a doc subpage as here, but also with lots of languages, and only rarely a sandbox + testcases (but working demos in the doc.) It gets rather bizarre, when the template data for the visual editor is also translated. Brion wrote that we are mostly not more using templates in 2017, so maybe this suggestion here isn't necessary for less than two years with templates... –Be..anyone (talk) 01:28, 1 January 2015 (UTC)
    We're not talking about doing it on Commons at the moment, just here. And it sounds like Brion is talking about templates being different in the future, not eliminated entirely. Oiyarbepsy (talk) 19:09, 1 January 2015 (UTC)
    If it's only here, it could be a case for WP:BROKE, maybe mw:Thread:Help_talk:Subpages/Wrong_MW_defaults is also/still relevant. –Be..anyone (talk) 23:44, 1 January 2015 (UTC)
  3. Lets not make this any more complex than it needs to be --Guerillero | My Talk 03:24, 13 January 2015 (UTC)
    Guerillero, how would this increase the system's complexity? Doesn't the current system of having to insert a template just to make documentation visible seem more complex? APerson (talk!) 14:42, 20 January 2015 (UTC)

Comment (documentation)

Comment Your proposal declares information as fact that is false. There are not three fundamental pages for a template, there are five possibilities. There are:

  1. The template itself
  2. The template's talk page
  3. A sandbox for the template for making modifications to a template that aren't expanded across all Wikipedia
  4. A test cases page to see how the sandbox reacts in relation to how the "live" template reacts.
  5. A documentation page

I actually started working on a userscript that added tabs for each of these components once upon a time but it fell into my stalled projects category due to other "more important" projects and real life issues. I'm still way too busy at the moment to pick that project back up, but would happily contribute what I have and help develop further if someone else wanted to take over the project. This is not something that I think should be done in core, but I fully support a userscript (which may eventually become a gadget if people find it useful, and may eventually even be a default gadget if there are enough people to support such a thing adding the appropriate extra tabs to those pages where respective sub-pages exist. — {{U|Technical 13}} (e • t • c) 07:04, 15 December 2014 (UTC)

I am aware of /sandbox and /testcases but I don't feel that they're terrifically relevant because there is no clumsy inclusion in the main Template: page as is the case with /doc. Furthermore they are far less ubiquitous. Since you seem to take such strong issue, I will point them out in the proposal though. − Thisismyrofl (talk) 07:11, 15 December 2014 (UTC)
  • Okay, next question, what about the 650 uses in the Wikipedia: namespace? Wouldn't transluding them automatically in one namespace but not in others be confusing? What about the 740 uses in the Module: namespace?I've fixed the Wikipedia: namespace count; and made the links use 1 less than the actual count, so users can see that the number is right. עוד מישהו Od Mishehu 16:18, 15 December 2014 (UTC) Will we be forced to have to look at the documentation while editing the templates? I would be strongly opposed to that as some templates have documentation that is three pages long and having to scroll up and down through that for no reason is excessive. — {{U|Technical 13}} (e • t • c) 07:36, 15 December 2014 (UTC)
I would absolutely not seek to have documentation and template code on the same page. That's completely contrary to the general movement I am endorsing. I want for there to be less garbage code on the template code page to look at. I know very little about modules, but I am sure their documentation could be transcluded as well. You raise a good point about the Project namespace, though. Perhaps a system by which the /doc subpage is transcluded if it exists, in any namespace - however as most pages outside of Module: and Template: would not require documentation, we could have a message "This template lacks documentation. Click here to write it!" in only those most relevant namespaces. I hope that makes sense. − Thisismyrofl (talk) 16:26, 15 December 2014 (UTC)
13, this isn't the same. This is to automatically transclude documentation even if the {{documentation}} template isn't present. It wouldn't create any tabs. Oiyarbepsy (talk) 17:53, 15 December 2014 (UTC)
  • Part of the plan for the script actually. The script just adds navigation tabs to make it so the documentation transcluded can be simplified and remove those links that are not conclusive or productive. I suppose I should work on developing that script some more. I have a lot of tasks on my plate and this is finals week and I'm boarderline on passing a couple classes. So I need to focus on that (why am I even here talking about it *sigh*), but would be happy to work on that script more after. — {{U|Technical 13}} (e • t • c) 18:26, 15 December 2014 (UTC)
But that only works if people actually activate the script. The proposal here is to make this auto-transcluding universal, which is something a user script just can't do. Oiyarbepsy (talk) 19:57, 15 December 2014 (UTC)
  • It actually can do that, if it is an on-by-default gadget. The process of completing the script to do what is wanted, testing it for a bit locally amongst a small group of tech savvy editors, promoting the script to a wider group of editors, proposing it be made an off-by-default gadget, and eventually switching it to an on-by-default will ensure that it does exactly what it is suppose to and there is community support for it. — {{U|Technical 13}} (e • t • c) 20:02, 15 December 2014 (UTC)
Allow me to raise a concern with your on-by-default gadget: if it has the function of auto-transcluding /doc, then if we implement that gadget and then make use of it by removing every {{Documentation}} on every template, the gadget becomes, well, pretty coercive. If a user chooses to turn it off at that point then every template will have no visible documentation, and no visible links to documentation; the user's kinda screwed. At that point, why even make it optional? − Thisismyrofl (talk) 18:29, 16 December 2014 (UTC)
  • There may be experienced editors who don't want to be bothered with template documentation, at all, ever. It's currently forced upon them, but I'm sure they would greatly appreciate a way to turn it off. I wouldn't be opposed to being more clever about how it could be turned off in those scenarios if a problem arises where inexperienced users are accidentally turning it off. It would be adjusted to be an always on for everyone script imported from MediaWiki:Common.js (if the community so deemed it necessary) and have an optional toggle parameter that a user that really wanted it off could add to their custom.js to disable it. — {{U|Technical 13}} (e • t • c) 18:47, 16 December 2014 (UTC)
Well, you do raise a scenario where optionality would be useful, but I feel that the documentation-hating population would be tech-savvy enough to CSS div#template-documentation { display:none; }. And of course, rare enough to warrant that not-quite-one-click solution. − Thisismyrofl (talk) 19:25, 16 December 2014 (UTC) 
div#template-documentation, #documentation-meta-data{
    display:none;
}
at most there should be one id or one class that hides them both. Either way, it's still more work than unchecking a checkbox on Preferences → Gadgets or adding var hideDocs = true; to my custom.js. — {{U|Technical 13}} (e • t • c) 20:29, 16 December 2014 (UTC)
I only used "div#template-documentation" in my example CSS because that was the ID used in the current documentation template. A sort of "you know what I mean". If my proposal goes through in the form of an extension, then whoever writes the extension can code a single div ID to surround the entire documentation, with simple CSS hiding in mind. But I will maintain that people who object to seeing template documentation are probably extremely rare at best, and can accomodate themselves anyway. I don't know how one would best verify it, but can we even think of one person so inclined? − Thisismyrofl (talk) 22:36, 16 December 2014 (UTC)
  • Note that the {{documentation}} template can take documentation from any page using the first unnamed parameter (e.g. for templates with shared documentation), or the documentation can be embedded within the |content= parameter. Any deprecation would need to take this into consideration. - Evad37 [talk] 10:45, 15 December 2014 (UTC)
I am sure that could be arranged. − Thisismyrofl (talk) 16:26, 15 December 2014 (UTC)
Easy to address - create a documentation page that redirects to another documentation page. Oiyarbepsy (talk) 17:23, 15 December 2014 (UTC)

Comment If your making comparisons, I'd compare this to the recent change that {{reflist}} automatically functions on all articles, whether the template is there or not. I like the idea, but excess unneeded detail in your proposal is confusing the matter (above comments suggest that people don't understand what you're proposing) and it gives me the impression that it's not quite yet specific enough to be formally proposed. Please provide a more specific proposal without unneeded detail so I'm clear what I'm commenting on. Oiyarbepsy (talk) 17:48, 15 December 2014 (UTC)

A proposed specific proposal: Automatically transclude the documentation subpage in template and module namespaces. Oiyarbepsy (talk) 17:51, 15 December 2014 (UTC)
I don't know the extent to which I am allowed to change a proposal once it's on this page and votes have come in, but what you have written is pretty much what I'm saying for right now. Sorry for the unneeded detail ("Moving on"), I'm just ranting.
I do wish we could make a move in the direction I have described; the problem is there's a potential for a lot of changes at once and I don't have enough knowledge of the software to formulate an extremely specific plan. I just don't know how else to start a discussion on the matter. − Thisismyrofl (talk) 18:38, 16 December 2014 (UTC)
Perhaps it would be better to have a multipart discussion: First establish whether there is consensus for the core idea (automatically transclude documentation), and afterwards discuss implementation methods (subpage/namespace, extension/gadget, easy-to-hide/not-too-easy-to-hide). - Evad37 [talk] 09:08, 18 December 2014 (UTC)
Absolutely! I tried to suggest a rather complete implementation here at the Pump about a year ago, but people had too many differing ideas to vote in favor. I'm going to try to write up two complete plans at User:Thisismyrofl/Templates proposal. For the moment they aren't complete, but I'll fill it out, see which is the most logical, and maybe we can base our discussion on one of those (though if someone has a radically different and better idea that can be considered as well). I do feel, though, that any plan might take a few steps to implement, and automatically transcluding /doc and killing {{Documentation}} would probably be an uncontroversial first step to any plan. − Thisismyrofl (talk) 17:56, 18 December 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Latest revisions at Special:RecentChanges

I think there should be an option on Special:RecentChanges that lets you only view the most recent edits. Sorry I can't go into detail, but I need to go somewhere now. CamelCase (talk | contribs) 02:11, 3 February 2015 (UTC)

Sorry, what I meant was that you can only view latest page revisions, like in User Contributions. Like I said, I'm in a hurry. CamelCase (talk | contribs) 02:16, 3 February 2015 (UTC)

This would be an update to the software - see Wikipedia:Bug reports and feature requests for details. עוד מישהו Od Mishehu 06:41, 4 February 2015 (UTC)
Whenever you have some time, you might consider changing the heading to something that says something about the topic. ―Mandruss ☎ 07:04, 4 February 2015 (UTC)
This VP page rarely gets those, they tend to go to WP:VPT - where the header does mention that. עוד מישהו Od Mishehu 07:40, 4 February 2015 (UTC)
I was referring to the heading of this section, and speaking to the OP (as indicated by my indent level). ―Mandruss ☎ 07:49, 4 February 2015 (UTC)
I've changed the title. CamelCase (talk | contribs) 22:23, 4 February 2015 (UTC)

Article alert for copyvio blanking?

This isn't a proposal, but a question that might or might not lead to one. I don't know how article alerts for RfCs, move requests, AfD etc are generated, but I'm guessing it's linked to the templates for those actions. The question: would it (a) technically possible, and (b) even remotely desirable, to add the {{Copyvio}} template to the list of those that do this? I ask because WP:Copyright problems is mostly over-loaded and under-manned, and some WikiProject involvement might help with that; and because copyright clean-up sometimes results in quite drastic changes that people might like to have been warned about. Justlettersandnumbers (talk) 00:50, 6 February 2015 (UTC)

The feature requests page is at Wikipedia talk:Article alerts/Feature requests. – Philosopher Let us reason together. 02:27, 6 February 2015 (UTC)

Marking Wikipedia:Highly Active Users as historical

This is likely to be very uncontroversial, but I'm sure collecting some opinions rather than being (possibly) too bold wouldn't hurt. These pages haven't been actively used in years. Recently I saw one editor updating his status on the North America subpage, so I looked through and see that none of the pages have been even remotely actively updated in far too long. The list is inaccurate and outdated, so it's probably best we mark it historical. Gloss 00:22, 2 February 2015 (UTC)

Hm, I'm surprised. I thought it was bot-maintained, i.e. once you sign yourself up for the page, the bot tracks your usage stats and updates things accordingly. As this isn't the case, I think you're right. Nyttend (talk) 02:43, 2 February 2015 (UTC)
Given the lack of replies and as I said this is likely uncontroversial, I'll go ahead and do this soon unless anybody has an objection. Gloss 04:41, 5 February 2015 (UTC)

Agree with marking historical - but if someone wants to write a bot that ensures its accuracy, it might make sense to revive it. Oiyarbepsy (talk) 05:54, 5 February 2015 (UTC)

Agree on both counts. – Philosopher Let us reason together. 02:29, 6 February 2015 (UTC)
  • The only reason I can see that this isn't currently being maintained is that the person running the bot that maintained this doesn't want to, doesn't have the time to, or doesn't care enough to make any changes needed to migrate to labs. Let me see if I can dig up the old bot code and figure out what changes need to be made to get it running again on labs. I'm assuming there is no big hurry on marking this as historical, so it may take me a few weeks as RL has limited my available time a bit. — {{U|Technical 13}} (e • t • c) 03:44, 6 February 2015 (UTC)
  • as of now, we can easily look at current folks listed and remove any that are inactive and see if any are still on the list. Someone could ask folks that are still active and listed for an update and maybe removed anyone who has not edited in 12 months as a starter. My initial thought was to mark it historical, but it strikes me as a nice support network to have to promoted teh community if at all possible. Cas Liber (talk · contribs) 03:52, 6 February 2015 (UTC)
  • I've done a little digging and apparently my impression there was a bot updating this at one time was wrong. Feel free to mark it as historical and when I have time to start from scratch, I'll create a bot and a new system for this. — {{U|Technical 13}} (e • t • c) 04:05, 6 February 2015 (UTC)

If someone does a re-boot, I'd say the approach here is totally wrong. The region of the world isn't that important, what matters is who's active. Maybe have a bot update every hour based on who's been making edits? But, that would require some kind of opt-out. Best to mark historical now, since re-booting will take a lot of time and thought to get it right. Oiyarbepsy (talk) 08:02, 7 February 2015 (UTC)

Delay publication to anon/mobile to allow time for review

I propose delaying the publication of edits to anonymous users with no editing session (including readers of mobile web and mobile apps) by a few minutes, to allow time for review. An anonymous page view at any given time would check the last few minutes of editing history. Reverts would be detected by content hash. A revision would be selected for display which stood unreverted for longer than the review period. If no such revision can be found within some limit of revision count and time, the newest revision would be shown. This simple heuristic is designed to be efficient to implement. Technical details would be similar to FlaggedRevs (WP:PC) -- there would be a single linear history, and clicking "edit" would show the newest revision.

The motivation is Reid Priedhorsky's 2007 paper which stated that despite revert time being short, popular pages commonly had hundreds or thousands of page views of the vandalised version. -- Tim Starling (WMF) (talk) 19:25, 29 January 2015 (UTC)

  • Groan. I mean, I get it, but surely you are aware of what an epic struggle it was to get us where we are with PC. It literally took five years and several massive, contentious RFCs. You're not going to get a change like this through by just posting about it here. I'm also wondering if this is just you or if the foundation actually wants this. Beeblebrox (talk) 19:33, 29 January 2015 (UTC)
  • I would support this for BLP's only (I'm undecided about the broader implementation) Would such a thing be technically feasible? Martijn Hoekstra (talk) 19:39, 29 January 2015 (UTC)
    • Yes, it is technically feasible, assuming BLP pages are or can be tagged somehow. It would probably add a couple of days of development time. -- Tim Starling (WMF) (talk) 19:55, 29 January 2015 (UTC)
      • Category:Living people? Sam Walton (talk) 19:57, 29 January 2015 (UTC)
        • Yes, it would possibly work, although a page will drop out of that category if it is blanked. You would need a more stable view of category membership. Maybe a couple of days was overly optimistic. I would be interested if Martijn Hoekstra could explain the rationale for limiting it to BLPs. Is the idea that vandalism of BLPs is more impactful? What is the tradeoff which prevents it from being deployed on pages where vandalism is less impactful? Personally, I care about quality, and reader perceptions of quality, on all pages of Wikipedia, not just on BLPs. -- Tim Starling (WMF) (talk) 20:11, 29 January 2015 (UTC)
          • Yes, I could. I assume I have the minority POV that it's not so much of a problem to have the occasional vandalism shown to visitors. It re-enforces the idea that anyone can edit, and that this is something you can do right now, analogous to the 17th century Wikipedia principle of always leave something unfinished. This off course completely breaks down in the face of BLP violations, which weigh heavier than recruitment efforts of our encyclopedia project. In that light yes, I do feel that vandalism of BLPs is more impactful than other vandalism. I'm undecided (not opposed per se)about whether or not presenting users with a possible inferior product - which would be the case only if the part of Wikipedia that has changed in the past few minutes of review time is inferior to Wikipedia five minutes ago, which gives rise to some interesting implications if we accept that as true, and I'm not 100% sure of - outweighs that public reminder and recruitment tool. But before bursting in to that discussion I first wanted to know whether or not it was feasible or not. Martijn Hoekstra (talk) 20:26, 29 January 2015 (UTC)
            • I slept on this, and came to the following conclusions. The first conclusion is I forgot to thank you for the proposal. Thank you, we need to keep looking out for changes to improve the project, proposals like these are important. The second conclusion is that the feature would increase the utility of Wikipedia to the reader at each momement iff the utility of the sum of all edits that are not reverts within the delay period is negative. That's fairly subjective even if we had complete data, which we don't. So it comes to a gut feeling-enhanced educated guess. And my guess is that that's not the case for the proposal as written. But I think we can do better; for some edits, we know they are likelier to be damaging than others. If we hook in to those mechanisms to trigger the delay, it is more likely that this feature has a positive impact. There is talk of the grand AI in the sky, but waiting for that would be unnecessary; we already have the edit filter. Currently the edit filter can log, warn and disallow. If we could add delay to that set (is that technically feasible?), I would certainly support it. Martijn Hoekstra (talk) 09:43, 30 January 2015 (UTC)
  • Question: is this basically setting automatic WP:PC for all members of Category:Living people? It goes against our protection policy (and Wikipedia's mission) to preemptively protect pages, but I think I can see the benefit of preventing anonymous drive-by BLP vandalism and would support per WP:IAR. I think there's a lot of details to work out. Technical question to Tim's point above: if protection were applied to members of the category (assuming that is technically feasible) then that protection should prevent the page from being blanked by an anon, yes? Ivanvector (talk) 20:18, 29 January 2015 (UTC)
    • No, as I read this proposal it's not about protection, it's about delaying new edits; if the edits stood uncontested for more than a few minutes it's assumed sufficiently good for public display. Also, the BLP issue is not part of the original proposal, it's just a ball I threw in the air as a question. Martijn Hoekstra (talk) 20:33, 29 January 2015 (UTC)
  • A technical question: Anonymous views are by far our largest volume, and as far as I know they are effectively served via static proxies. Have you already considered the load implications of this proposal? It could add orders of magnitude of load on the actual DB servers (which may or may not be a problem, but should be considered). --Stephan Schulz (talk) 20:41, 29 January 2015 (UTC)
    • I think Tim might know one or two things about the infrastructure, and if he explicitly notes it would be efficient to implement, it's likely true. Martijn Hoekstra (talk) 20:50, 29 January 2015 (UTC)
      • Well, the algorithm he describes above is certainly not highly complex, but it does seem to move from a static request to a dynamic request, and indeed one with multiple data base accesses (get the history, get the proper revision). I can imagine some clever ways to improve performance, but a straightforward implementation is a potentially serious performance issue. So I am interested in a statement, especially by someone who knows the infrastructure. --Stephan Schulz (talk) 22:14, 29 January 2015 (UTC)
        • Depending on the implementation, this could actually reduce load on the main servers, since the caches would not need to recheck their copies at all until the delay expires. If there is no delayed edit pending, then the page served to anonymous users cannot change until after (1) an edit is made, and (2) the delay expires. This would mean that the caches would not need to contact the main servers at all until the delay expires. Which leads to the question: Would an anonymous user still immediately see their own edits? Pathore (talk) 22:31, 29 January 2015 (UTC)
        • Here is my idea for implementation: since no change is possible until the review period expires, we can just delay the HTCP CLR requests using a queue, instead of doing them on save. That takes care of most of the feature, with no increase in backend traffic. In fact, it could reduce server load because it makes it possible to send an Expires header to clients. Continuous high-frequency editing would work as long as duplicate entries are not removed from the HTCP CLR queue. If a backend request is received during the review time despite the delayed HTCP CLR message, send the old revision with a short Cache-Control: smaxage. Then Varnish will send a second backend request with an If-Modified-Since header after the review time expires. If there was no revert, MediaWiki can respond with a 304, which is fairly cheap since it doesn't require loading i18n etc. An anonymous user would immediately see their own edits, because editing causes a cache-suppressing session cookie to be sent, and MW would send the current revision to users with a session cookie. -- Tim Starling (WMF) (talk) 23:07, 29 January 2015 (UTC)
  • I'm still processing this idea, but my initial reaction is: wiki means fast. Intentionally adding a delay seems to be a direct contradiction of this fundamental principle. If we implemented this proposal and anonymous user A vandalized the page, anonymous user A would see the vandalism, but other anonymous users would not, as I understand it. What would happen when anonymous user B goes to edit the page? Wouldn't there immediately be a disconnect between what's shown on the page and the (uncached) edit view?

    Broadly, we currently have the purge action (hack) in place because we're so bad about keeping content up to date. Our *links tracking database tables are a mess and contain plenty of bad entries, refresh jobs can get dropped or forgotten resulting in indefinitely stale content, etc. Given that we already struggle to show current content and that cache invalidation is a notoriously hard problem, I'm hesitant to add another caching layer that could make the situation worse. --MZMcBride (talk) 23:42, 29 January 2015 (UTC)

  • No worse than the disconnect that occurs when someone edits a page between when you load the page and when you click the "Edit" link, which happens occasionally. --Ahecht (TALK
    PAGE    ) 19:10, 30 January 2015 (UTC)
  • I've thought about this a bit and I see two ways of looking at it. The idea of letting the caches lag in a controlled manner to reduce server load for heavily accessed and frequently edited pages, while simultaneously denying recognition to vandals and edit warriors, could be an improvement that I could support. In this view, it is a sort of "Pending Changes 0" applied automatically to heavily edited pages, and there should be a list somewhere of pages where the currently shown revision is more than X minutes out of date (because no revision since then has stood for the delay period) and any autoconfirmed user should be able to endorse another user's existing revision ("looks good to me") with immediate effect.
We need to be very careful with this: in the other view, "you see your edits, but others don't" is more-or-less the basic concept of a shadowban. Doing that to all anonymous users with no assumption of good faith at all, is just not the Wikipedia way and I would vehemently oppose such a proposal. Note that both of these are technically almost the exact same thing, the only difference is the motivation behind them. Pathore (talk) 01:49, 30 January 2015 (UTC)
  • I'll sign up as one of the closers if this turns into an RfC. There's nothing wrong with throwing this out for discussion, and it looks like you're getting some good feedback, but be aware that if it looks like there are still a lot of unresearched questions when the RfC starts, any perceived lack of preparation is likely to generate some opposition. I'll be happy to supply links to previous related discussions if you want them. Could you summarize the results of the 2007 paper for us? - Dank (push to talk) 02:45, 30 January 2015 (UTC)
    • I would definitely be interested in reading previous related discussions, thanks for the offer. Here's a relevant quote from the paper: "42% of damage incidents are repaired essentially immediately (i.e., within one estimated view). This result is roughly consistent with the work of Viegas et al., which showed that the median persistence of certain types of damage was 2.8 minutes. However, 11% of incidents persist beyond 100 views, 0.75% – 15,756 incidents – beyond 1000 views, and 0.06% – 1,260 incidents – beyond 10,000 views." The paper is reference 14 in the article Reliability of Wikipedia. My proposal here is not discussed in the paper -- instead, the authors suggest improving tools for human review. -- Tim Starling (WMF) (talk) 04:31, 30 January 2015 (UTC)

Thanks for your comments, everyone. It sounds like this would likely be rejected if I took it to an RFC, so I'm going to drop it as originally proposed. Martijn's idea of making publication delay be an AbuseFilter action is interesting, I'll make a note of that for further analysis. Making it a selectable PC protection level would also be technically feasible, but it sounds like it would be a lot more trouble on the community side due to strongly held views about PC. -- Tim Starling (WMF) (talk) 23:19, 30 January 2015 (UTC)

(I think you're referring to my comment.) I just want to clarify that I was not suggesting making delay a selectable pending changes level. Since the infrastructure for delay would be shared with pending changes in your proposal, I was loosely calling the delay "PC0", but I meant to suggest that the software would apply it automatically to pages with more than X requests/sec to lessen the load on the main servers. Reducing the visibility of vandalism would be a beneficial side-effect, but the main goal is to make better use of the caches. Pathore (talk) 01:46, 31 January 2015 (UTC)
  • @Tim Starling (WMF): Delaying the visibility of all edits indiscriminately would almost certainly be rejected, even if only for a subset of articles. But if only edits automatically assessed as 'suspicious' are delayed, then this would likely be accepted. In fact, I'm working on such a proposal at Wikipedia:Deferred changes. The abuse filter or bots would defer suspicious edits, marking them for review by pending changes reviewers. (This is an improvement on the old Wikipedia:Deferred revisions, see also the request at phab:T51770.) This also allows a mild form of blocking called 'moderation'. I haven't made a formal proposal yet but I may go ahead shortly, especially if there is interest among developers to work on such a feature. Cenarium (talk) 17:27, 31 January 2015 (UTC)
    • The FlaggedRevs UI is quite tightly coupled to its DB schema, which makes schema changes to support new features like that potentially touch a lot of code. I don't think there is much developer interest in digging deep into the guts of FlaggedRevs at the moment. -- Tim Starling (WMF) (talk) 04:22, 1 February 2015 (UTC)
      • @Tim Starling (WMF): The bare minimum is a userright that allows to apply and remove pending changes protection without leaving an edit. Everything else can be done by bots : the bot checks for edits that require being deferred, when it detects one it enables pending changes protection (without leaving an edit), accepts the latest revision before the last user edited, then the edits appear automatically at Special:PendingChanges. When a new revision is accepted, either due to a revert or a manual review, the bot removes the pending changes protection (without leaving an edit). It would be better, but not necessary, if this were another flaggedrevs level, so that it appears differently at Special:StablePages (and to get specific mediawiki messages), and that it automatically accepts the revision preceding the last user, and automatically removes itself when a new revision gets accepted (to avoid unnecessary logged bot actions). Then we can think of having abusefilter defer directly instead of using bots as intermediaries, which would be faster, but it's not the crucial point. Cenarium (talk) 03:09, 3 February 2015 (UTC)
  • I've put some thought into this and I don't think I can support it. We already have legions of vandal fighters racing to revert vandalism faster than ClueBot can detect it. Blatant vandalism is a problem, but it is usually dealt with very quickly. Delaying all edits by IP users doesn't seem tome like it would be a very effective tool in the ongoing struggle against vandals, and it completely ignores the fact that a lot of vandal edits ctually come from newly-registered users. I floated a different idea regarding them a few years ago and maybe it's tiome to revist that: New accounts are often created by vandals in order to grant them the ability to instantly create new articles. Anyone with experience in vandal fighting knows this. They create attack pages, nonsense pages, pages about their exploits on the playground or the xbox, etc. If we restricted article creation to WP:AUTOCONFIRMed users they would have to wait four days and make ten good edits befroe they could create whole new articles that need to be deleted. For the vast majority of vandals, i.e. teenage schoolboys goofing off, the reward would not be worth the effort and they don't have the patience to begin with. I'd much rather see that change than the one proposed here. Beeblebrox (talk) 18:57, 31 January 2015 (UTC)
    We already restrict file uploads to autoconfirmed users, maybe similar reasoning can support limiting the creation of articles in mainspace. Can you point to the discussion that led to the restriction on file uploads? I'd like to read it, but the closest I've been able to find was this, from December 2009, that mentions autoconfirmed status already being required to upload files. The archives for Wikipedia talk:Upload don't seem to mention it. Pathore (talk) 22:14, 31 January 2015 (UTC)
    There was Wikipedia:Autoconfirmed article creation trial but it wasn't implemented, apparently restricting page creation beyond registration is a no go for the WMF. Even then, since then, NPP has been more streamlined and AFC has taken over a substantial portion of page creations, actual or potential, so it's less of a problem that it was back then in my opinion. (FYI, in my proposal I suggested that deferred page creations be noindexed.) Cenarium (talk) 00:29, 1 February 2015 (UTC)
    @Beeblebrox: I didn't say anything about edits by IP users, I think you're the first person to bring up that idea. I was talking about delaying all edits. -- Tim Starling (WMF) (talk) 04:22, 1 February 2015 (UTC)
    I think the first sentence is tripping people up. ("I propose delaying the publication of edits to anonymous users with no editing session (including readers of mobile web and mobile apps) by a few minutes, to allow time for review.") "Anonymous users" is often used interchangeably with "IP editors," which is actually how I read this thread until just now. I thought we were discussing only delaying edits by "drive-by IPs" (people not logged in with no editing experience). That's how I interpreted "no editing session." I'm not sure if I'm alone in this confusion. --MZMcBride (talk) 05:25, 2 February 2015 (UTC)
The language could certainly be more clear as it does seem I misread some aspects of it. Beeblebrox (talk) 03:07, 4 February 2015 (UTC)
  • I might be missing something, but isn't this more or less the original "pending changes" system from 2008 or so, as used on dewiki & elsewhere, before we ended up writing an enwiki-specific version? It's not a bad method, but it doesn't look like it's become any more popular... Andrew Gray (talk) 20:12, 31 January 2015 (UTC)
    • It doesn't seem similar to me. -- Tim Starling (WMF) (talk) 04:22, 1 February 2015 (UTC)
    • My understanding of FlaggedRevs is that the idea was to have humans pick a good state of an article and then typically manually review untrusted edits to the article before establishing a newer good state. This proposal seems to be suggesting a similar idea, but without needing manual review (to establish a newer good state of the article) and instead using an automatic timer. Under this automatic timer, there would be an intentional delay placed at the HTML cache layer to not purge the page for an unspecified(?) amount of time during which patrollers would have a grace period to catch the edits before the article is purged.

      My reading of this discussion is that it needs clarification of the time period (review time/delay until live) we're talking about (30 seconds? 10 minutes?) and it needs clarification of what kind of edits would be delayed from purging the HTML cache. That is, what does "no editing session" mean? --MZMcBride (talk) 05:33, 2 February 2015 (UTC)

If I've understod this correctly (Tim can complain if I'm wrong), this proposal means the following:

  • All of us logged-in editors will see exactly what we see right now. For the purpose of this proposal, this group is called "editors".
  • People who are editing while logged out will see exactly what they see right now. We'll call this group "editors", too.
  • This proposal only affects people who are both logged out and have not edited recently ("no editing session"). We'll call this group "readers".
    • According to unrelated research, an editing session can generally be assumed to have ended if you haven't made any edits in the last ~30 minutes.
  • This proposal requires zero extra effort. Unlike FlaggedRevisions/PendingChanges, there is no manual review needed. No intervention by editors. Zero increase in our workload. It's all automatic.
  • This proposal says (only for the one affected group, "readers") that if and only if
    1. an article has been edited very recently and
    2. that last edit was not a revert,[1]
  • then the reader will not see the very latest (potentially vandalized) version. Instead, the reader will see the latest "stable" version, meaning the latest version that wasn't still being evaluated by ClueBot and/or RecentChanges patrollers.
  • "Very recently" means a short period of time, probably in the range of 30 seconds to three minutes.[2]
  1. ^ Tim's proposal is actually slightly more elegant, because he's taken into account the possibility of high-speed edit wars, which I'm glossing over.
  2. ^ Actual proposal is slightly more complex and takes the number of revisions into account, due to the possibility of a high-speed edit war.

Consequently the question is basically this: Would you rather that "readers" (i.e., people who are not you) saw the absoultely latest and sometimes vandalized versions of all articles, or would you rather that readers saw (very) slightly older, and noticeably less vandalized, versions of articles? Whatamidoing (WMF) (talk) 01:58, 3 February 2015 (UTC)

FWIW, the "no edits in the last 30 minutes" is a proposal I haven't seen before, and I don't know how RfC voters would react. - Dank (push to talk) 02:08, 3 February 2015 (UTC)
That particular measurement need not be the one used (I'd have assumed 24 hours as a more natural one), but there has been some good research in how long people spend editing and how to predict whether they're done, and 30 minutes of inactivity is apparently a very good predictor. Therefore, any delay in excess of that very short time will very likely be sufficient. Whatamidoing (WMF) (talk) 07:51, 3 February 2015 (UTC)
The problem is that those high visibility articles, often related to current events, tend to be edited heavily, with some having one or more IP edits every minute. So if we put a relatively long delay, such as two minutes, it effectively means that those articles would be un-editable for IPs, while if we put a relatively short delay to counter this, say 15 seconds, the efficacy of the delay to prevent display of vandalism would be severely limited. In my opinion, it's much better to automatically identify actually suspicious edits and defer them for manual review. And then the server overhead is on the edit (or defer action if a bot does it), not the page views. Cenarium (talk) 02:41, 3 February 2015 (UTC)
There is nothing in Tim's proposal that would stop an IP from editing. Tim's proposal is only about what people see when they read the page. The edit button would still be present, the contents of the edit box would still be exactly what you and I see, and the only 'difference' is that what the IP would find in the edit box would (sometimes) be different from what the IP read on the page. (In other words, the IP would experience exactly what all editors routinely experience on rapidly edited articles.)
However, the particular edge case you mention was directly addressed in the original message: "If no such revision can be found within some limit of revision count and time, the newest revision would be shown." That means something like, "If an article is being edited very rapidly, then we'll just show the latest (possibly vandalized) version, exactly like we do right now". Nobody would ever read a version that is very outdated. Whatamidoing (WMF) (talk) 07:51, 3 February 2015 (UTC)
I didn't mean that IPs would be technically prevented from editing, but that it would be very difficult to make edits in those circumstances due to the systematic delay and resulting discrepancy, much more so than for registered users, since they could not know which version is live. (Even on rapidly edited articles, we have windows of opportunity of several seconds at least, with rare exceptions.) It should be considered that merely trying to edit would not make you in an 'editing session' subsequently, so you would still get the delay after a failed edit attempt. If the server would check for edit attempts (loading a action=edit url), it would remove this problem after a first failed attempt, but it may be tricky to accomplish server side. The extract from the original message that you quote concerns high speed edit wars, as you mentioned earlier, which is only a small subset of rapidly edited articles. Cenarium (talk) 16:07, 3 February 2015 (UTC)
This is why I suggested allowing any autoconfirmed user (or even any registered user) to endorse an existing pending revision of any such delayed article, with immediate effect. How many vandals bother to make autoconfirmed sockpuppets? Pathore (talk) 01:23, 6 February 2015 (UTC)
I generally endorse Cenarium's concern. However, if the delay is kept down o around 30 seconds (or any other "less than one minute") time, I don't think the burden on "readers" who are switching their status to "editors" would be too great. – Philosopher Let us reason together. 18:51, 6 February 2015 (UTC)

I'm probably coming to this thread late, & after everyone has moved on to other threads. However, this proposal illustrates an important -- & potentially fatal -- contradiction: which is primary, letting anyone edit, or proving the most accurate information possible. If it is to let anyone edit, then this proposal should not be implemented. If it is to provide the most accurate information possible, then it needs to be implemented. In the past, the en.wikipedia community has tried to prioritize accuracy (e.g., various proposals for dealing with new page creation), only to see the WMF quash community consensus. On the other hand, WMF has taken actions favoring accuracy (e.g. its support for WP:BLP policy). I have the impression that the Foundation wants it both ways, & penalizes the community whenever it prioritizes one of these -- letting "anybody" edit vs. accuracy -- over the other. In my comment above I am not accusing Tim Starling as contributing to this contradiction; as he remarked, his posting from a WMF foundation was forced upon him. And besides, unlike other Foundation employees he came to the community first with his idea, & did not impose them upon us as other innovations have. -- llywrch (talk) 00:46, 10 February 2015 (UTC)

Proposal regarding flag icons in infoboxes

Okay, this is my first attempt at a proposal, so be gentle. I attempted to ascertain if there was a particular format (as per IJBalls suggestion, but failed to determine if there was one (perhaps I simply did not look in the right place). Anyway, here goes.

WP:ICONDECORATION states that "Icons should serve an encyclopaedic purpose and not merely be decorative. They should provide additional useful information on the article subject, serve as visual cues that aid the reader's comprehension, or improve navigation." In the first instance, the inclusion of a flag icon, directly next to the name of the administrative unit, is redundant, and solely for decorative purposes. Since the name of the country/state/province is already included, it provides no additional useful information. While it does serve as a visual clue, it is questionable as to whether or not it aids the reader’s comprehension, since a reader would have to know the flag of the geographic area in order for that to be the case. And it does not improve navigation, since the geographic name already provides the link.

WP:WORDPRECEDENCE states that "Words as the primary means of communication should be given greater precedence over flags ..." This is pretty explicit.

MOS:INFOBOXFLAG begins with "Generally, flag icons should not be used in infoboxes, even when there is a "country", "nationality" or equivalent field: they are unnecessarily distracting and give undue prominence to one field among many ..." It goes on to say, "Flag icons should only be inserted in infoboxes in those cases where they convey information in addition to the text. Flag icons are visually distracting in infoboxes and lead to unnecessary disputes when over-used."

However, after these pretty specific guidelines, it goes on to muddy the waters by saying “Human geographic articles – for example settlements and administrative subdivisions – may have flags of the country and first-level administrative subdivision in infoboxes ..." It becomes even more confusing when it goes on to say, "Where a single article covers both human and physical geographic subjects (e.g. Manhattan), or where the status of the territory is subject to a political dispute, the consensus of editors at that article will determine whether flag use in the infobox is preferred or not."

This has been discussed, and there has never been a consensus reached, but neither have either of the two guidelines I mention above been brought into the discussion.

What I propose is to make it more clear when flag icons should or should not be used in geographic infoboxes. When you factor in all three of the above guidelines, the first two would seem to indicate a preference to not including them in infoboxes. When you look at the third, it begins by agreeing with them not being included in infoboxes, but then goes on to contradict the other two guidelines, and the earlier paragraphs within its own guideline. And it does so without giving any reason whatsoever. I propose that we change the guideline to read that flag icons should not be used in infoboxes for ANY geographic articles, either physical or natural. I think this would make the standard consistent. Onel5969 (talk) 04:32, 1 February 2015 (UTC)

Discussion (MOS:INFOBOXFLAG)

Comment – I agree with this proposal, but am wondering if it is in the "correct format" for proposals. So I'd appreciate any comment from knowledgeable editors on that aspect of this... --IJBall (talk) 16:46, 1 February 2015 (UTC)
  • Support This has been a long time coming. This particular guideline is one of the most debated and ignored guidelines on wikipedia. In My Opinion, Flag icons would not be used in any infobox at all. They are 100% useless in infoboxes 100% of the time. A slim, but vocal, minority of editors have been able to successfully "protect" their sphere of articles from the removal of infobox flag icons for several years now. The most notable would articles pertaining to Tennis, Golf, and Formula One racing. The most common argument that these few editors use to keep their icons are that these sports use flags in their internal media. Whatever! The point is that there are some very vocal editors out there who might see this proposal as an attack on their pet projects. In respect to geographic articles, I think that they are useless there too. Yet the vocal minority is notably absent from these articles as there are many articles that do not contain flag icons and for some reason the world continues to turn without them. Some articles do contain flag icons and usually these have been added, or removed, and even debated on a case-by-case basis. And everything I just said, goes the same for military articles as well. They are useless.--JOJ Hutton 17:33, 1 February 2015 (UTC)
I do not understand why flag icons would be appropriate in the articles you mention, because the competitors in those events are almost never competing for their countries, except in very specific matches (where they would be named as part of a team). Risker (talk) 23:48, 7 February 2015 (UTC)
And are totally unnecessary... --IJBall (talk) 17:57, 1 February 2015 (UTC)
So you say. Others say it's a Good article. There is no reason to WP:CREEP over such a thing. Alanscottwalker (talk) 18:10, 1 February 2015 (UTC)
"Good article" status is about the words in the article. That has absolutely nothing to do with Flag Icons in the Infobox. Removing the Flag Icons doesn't suddenly mean that Manhattan will lose "Good Article" status. And none of that has anything to do with whether using the Flag Icons in Infoboxes is properly "germane" or not. --IJBall (talk) 18:23, 1 February 2015 (UTC)
Obviously, the editors of the article found them germane. But the need to micromanage them and turn them off (because of an 'i don't like' position over "true" germaness) is apparently strong in some. Alanscottwalker (talk) 18:29, 1 February 2015 (UTC)
FTR, I don't agree that "they are 100% useless in infoboxes 100% of the time" – I'd put this kind of article down as example of a narrow case in which Flag Icons in Infoboxes actually serve a useful purpose (e.g. in those cases where there exists lists of things from many different nations in Infoboxes). But I would probably agree that Flag Icons are unnecessary in Infoboxes about 90% of the time, so I probably don't disagree with you all that much. I certainly agree that they are 100% unnecessary in all "city" articles, and the "human geographic, i.e. settlement, articles" carve out from MOS:INFOBOXFLAG should be eliminated. --IJBall (talk) 17:57, 1 February 2015 (UTC)
Flag icons should not be used where text can convey the same information - that typically being the nation, state, providence, etc., that the city/person is part of. (Needless to say, the obvious use of a country's flag in a country's infobox is fine, this is part of the base data for a country). --MASEM (t) 18:37, 1 February 2015 (UTC)
Why does this need to be one size fits all? And what person are you talking about? Alanscottwalker (talk) 19:11, 1 February 2015 (UTC)
  • Oppose - Most of the present language of MOS:ICON was adopted by five or six editors in October 2007 with little or no Wikipedia-wide notice and no participation from members of the sports, military, ship and other relevant WikiProjects. It is a classic example of an unadvertised "local consensus" on a talk page for a guideline that is supposed to provide project-wide guidance. Even the on-wiki talk page discussion strongly hints that the five or six editors knew what they were doing, and had adopted a controversial change without widespread notice and input, effectively gaming the concept of "consensus" (see MOS:ICON talk archive). Based on the last several years of MOS:ICON talk page debates, I have little doubt that the present MOS:ICON language could not achieve an effective consensus in support of it (see, e.g., recent RFC on point). While I do believe that the use of flag icons should be limited and appropriate, I will oppose any attempt to change MOS:ICON that does not expressly sanction the use of a single 7mm flag icon to symbolize the "sporting nationality" of Olympic athletes and other members of their country's national sports teams in biographical articles. Such limited use is entirely appropriate, and I believe that you will find that there is widespread support for that proposition. Given the checkered history of the present MOS:ICON language, I would also like to know where this proposal is being advertised on-wiki? Dirtlawyer1 (talk) 18:42, 1 February 2015 (UTC)
    Question - Why is this proposed change to MOS:ICON being at Village Pump, and not on the relevant MOS:ICON talk page? As far as I understand it, proposed changes to guidelines are usually opened and discussed on the talk page for the particular guideline. This location for this proposal strikes me as quite odd and contrary to normal process. Dirtlawyer1 (talk) 18:52, 1 February 2015 (UTC)
    Because, 1) we want to find out if it is even in the correct format for a proposal like this, and 2) (I think...) a wider audience of opinions on the draft proposal was desired. --IJBall (talk) 18:55, 1 February 2015 (UTC)
    IJBall, I am all in favor of determining the correct format for the RfC -- generally, successful RfCs ask a narrowly drawn question that can be answered "yes" or "no", followed by as much rationale as discussion participants care to add. I, too, am in favor of as much project-wide notice and participation as can be achieved for proposed changes to style formatting guidelines that offer project-wide guidance. That having been said, I am unaware of any previous proposal to change MOS provisions that has been initiated at Village Pump -- can you provide any examples? Again, this strikes me as a very odd (and inappropriate) forum to be discussing the appropriate use of flag icons in article space. Dirtlawyer1 (talk) 19:10, 1 February 2015 (UTC)
    Wikipedia talk:Manual of Style/Icons, which is the talk page for MOS:ICON, has 229 watchers. This page has 2,649. --Redrose64 (talk) 19:25, 1 February 2015 (UTC)
If we'd known the proper "procedures" for this we wouldn't have asked here.  ;) This is Onel5969's first proposal, and I've never done one before either, which is why I suggested he ask for guidance here. At this point, I guess if Onel5969's proposal is deemed to be in the "correct" format (or we're told we should do an RfD...), then it can be moved to Wikipedia talk:Manual of Style/Icons. So really, at this point, all that's desired is guidance on what needs to be done here... --IJBall (talk) 20:00, 1 February 2015 (UTC)
As IJBall pointed out, this is my first shot at a proposal. Dirtlawyer1 - I began the proposal here, because if you go to WP:PROPOSAL, it says, "The first step is to write the best initial proposal that you can. Authors can request early-stage feedback at Wikipedia's village pump for idea incubation and from any relevant WikiProjects." I had already gotten feedback from the US City project, so I felt the next step was here. Onel5969 (talk) 20:50, 1 February 2015 (UTC)
  • I'm really not sure exactly what is being proposed here. The last section starts with I propose is to make it more clear when flag icons should or should not be used in geographic infoboxes. which I Support as clarification is normally a good thing; the same section ends with I propose that we change the guideline to read that flag icons should not be used in infoboxes for ANY geographic articles, either physical or natural. which I strongly oppose as BUREAU CREEP and too restrictive. There are obviously cases where using the flags is beneficial and informative and by changing the guideline to prohibit such use will just end up with multiple cases where WP:IAR will simply be invoked as appropriate. — {{U|Technical 13}} (e • t • c) 18:48, 1 February 2015 (UTC)
Hi Technical 13. Can you provide some example where you think that Flag Icons in Infoboxes are appropriate in a "geographic" type article. I believe Onel5969's proposal is mostly directed at "city" articles, like, say, this one (see the 'Country' and 'State' fields), in which the use of Flag Icons in the Infobox seems to many of us to be totally unnecessary. So it would be useful if someone could give some examples where Flag Icons might actually be constructive... Thanks! --IJBall (talk) 18:53, 1 February 2015 (UTC)
You have a preference for that article not to have those unobtrusive flags? Take it to the article talk page and perhaps the editors who are concerned and knowledgeable on the subject might agree with you (or not). Alanscottwalker (talk) 19:00, 1 February 2015 (UTC)
Inter-article consistency on matters of style is a good thing, that's why we have MOS. There is no reason or justification for flags to be used this way in San Francisco, for example, but not in Los Angeles. So it would make zero sense to take this up on the talk page for Los Angeles. ―Mandruss ☎ 21:11, 1 February 2015 (UTC)
So now we have at least three article linked in this discussion where the editors found the icons pertinent to the infobox. So, it's backwards to now say - 'oh no, we can't even be bothered to convince you at the article, we must shackle you and your editorial discretion.' Alanscottwalker (talk) 21:25, 1 February 2015 (UTC)
Oh I have no doubt there are many more than three. We have no way to know what was in the minds of those editors, and it's more than plausible to believe they just did it because the flags are pretty (which they are), which is a clear misuse per WP:ICONDECORATION. The only defense I've read is that current MOS represents a false consensus - which has been allowed to stand for seven years according to the person making that claim. We don't get to ignore guidelines because we don't feel they are legitimate; we either follow them or work to change them. ―Mandruss ☎ 21:32, 1 February 2015 (UTC)
You've misread the current MOS, it specifically allows these editors to do their good work, without you interfering in articles you claim to not even know about, much less care about - just because you for wish to disagree with their valid choices. Alanscottwalker (talk) 21:40, 1 February 2015 (UTC)
If some other part of MOS supports such usage, then it contradicts WP:ICONDECORATION and the contradiction needs to be resolved. As I read it, that's what this thread is about. Now that you're making it personal, this ends our interaction. ―Mandruss ☎ 21:49, 1 February 2015 (UTC)
The current MOS is clear enough on this - it's allowed; that's just you disagreeing with the proviso that already exists. Alanscottwalker (talk) 21:57, 1 February 2015 (UTC)
The desire is to change the current policy on this, because several of us feel that it is bad policy, and that it contradicts both other parts of MOS:INFOBOXFLAG, as well as other policies outlined by Onel5969 and Mandruss. That's why we came here for suggestions on the draft proposal. You can disagree with the attempts to change the policy, but you can't argue that editors don't have a right to try and change it. --IJBall (talk) 22:01, 1 February 2015 (UTC)
Yes. Unlike the prior interlocutor, you are aware that current guideline (not policy, MOS is not policy) has allowed this for a long time. Moreover, the evidence from articles is that the editorial choice has made sense to them for those city articles. Alanscottwalker (talk) 22:09, 1 February 2015 (UTC)
Well, the other issue is that it's been inconsistently applied – i.e. no flags at London or Paris or Berlin, or (most, but not all) articles on Canadian cities apparently, but flags at some (though not all!) U.S. city articles (and at some random European "village" articles" I've seen). So a consistency in guidelines seems to also be strongly desirable in this instance. --IJBall (talk) 22:23, 1 February 2015 (UTC)
Different places are going to have different needs, different relationships to their various jurisdictions, and different editors - so, I ask again why one size fits all - when it is only going to impinge on editorial judgement and discretion, where there is no need to do so. (there is no wish to force London editors to do anything, but somehow LA/SF/MANHATTAN editors must conform!) Alanscottwalker (talk) 22:28, 1 February 2015 (UTC)
  • Oppose The longstanding consensus explicitly permitting the use of flag icons in settlement articles doesn't need to be changed. It does need to be clarified, as evidenced by the edit warring by editors who misunderstand the meaning of human and physical geography, which has been the underlying trigger for many of these battles. Alansohn (talk) 04:24, 2 February 2015 (UTC)
  • Comment - remember also that there is a completed and finalized RfC that specifically allows flags for international sports people to be in the infobox. No one bothered to put it in the MOS for some strange reason, but it is the defacto consensus that it is allowed. Fyunck(click) (talk) 05:13, 2 February 2015 (UTC)
    • There is no value to the community in a consensus that exists only in the minds of one or two dozen editors among hundreds of thousands, and in some well-hidden archived thread that only they know about. If it's not in MOS, it's not a legitimate consensus as far as I'm concerned. The "some strange reason" you refer to is that somebody dropped the ball. ―Mandruss ☎ 05:23, 2 February 2015 (UTC)
      That would be incorrect. RfC's are quite binding and are sourced as protocol all the time. For instance the RfC that censors all English spellings of Foreign names, regardless of the amount of sources, never made it to MOS. Yet that RfC is the law of the land at Wikipedia and as ironclad as if it was in MOS. Fyunck(click) (talk) 06:12, 2 February 2015 (UTC)
      That is a completely unworkable system for all but the most experienced editors who have the time to keep up with such developments. But I'm not going to take this thread any more off topic by debating that with you here. ―Mandruss ☎ 07:24, 2 February 2015 (UTC)
      What's funny is, I agree with you. I used to argue as you just did but was slapped down pretty hard several times in the past when these RfC closings kept being alluded to in deference to what was plopped into MOS. I also complained about things put into MOS with no discussion whatsoever... things that had slipped in. I was told by editors that since no one complained at the time they were now, in effect, a MOS Guideline. So you never know what you'll run into at Wikipedia. It's an adventure to be sure. Fyunck(click) (talk) 07:55, 2 February 2015 (UTC)
      It's not the only way Wikipedia has become designed by the experienced, for the experienced, and yet we wonder why we can't keep new editors. Duh. ―Mandruss ☎ 08:00, 2 February 2015 (UTC)

I am confused by the original proposal where it states:

"I propose that we change the guideline to read that flag icons should not be used in infoboxes for ANY geographic articles, either physical or natural."

In this context I would assume "physical geographic articles" and "natural geographic articles" to be the same thing. Did user: Onel5969 mean to say "either political or natural" or "either human or physical"? --RacerX11 Talk to meStalk me 10:34, 2 February 2015 (UTC)

Hi Racerx11 - yes, that's exactly what I should have written: "either human or physical" - as in keeping with the confused and contradictory way the guideline is currently written. Onel5969 (talk) 14:39, 2 February 2015 (UTC)
Oppose. Thanks Onel but I dont see anything wrong with guideline as it is. I have removed flag icons from over 5000 geographic infoboxes, using the guideline and referencing it in my edit summaries. To my knowledge, not a single one of those 5000+ actions have been reverted or challenged. I have done mountains, mountain ranges, passes, lakes, rivers, glaciers, deserts, and currently islands. The island articles can be hard to call. If the island itself has a flag, I tend to leave it in place because with some smaller islands, that article may be the only place on WP where we have the opportunity to show the reader that flag. For larger islands it's been fairly straightforward. Ireland and Great Britain do not get flags because those are physical geographic articles about those natural islands. At Republic of Ireland and United Kingdom, flags are welcome. It gets trickier with some of the smaller islands where their name is the same as a political subdivision. I those cases I go by the content and wording of the article. If in doubt I leave the infobox as is, with or without flag icons. --RacerX11 Talk to meStalk me 15:22, 2 February 2015 (UTC)
Request for clarification: I don't understand your position here, especially as it appears that Mandruss agrees with the OP (and myself) that the current MOS:INFOBOXFLAG policy is a mess that is in need of further clarity, especially in light of its contradiction with WP:ICONDECORATION. IOW, if you agree with Mandruss, it should seem that you should be in "support". --IJBall (talk) 16:33, 4 February 2015 (UTC)
  • Oppose. Well meaning proposal, and I appreciate it being brought here rather than a lightly watched, local page. However, I agree with others that rule creep is unnecessary in this case, and I particularly endorse Dirtlawyer's comments. Ultimately, I find much of the prohibition against flag icons is built on a foundation of little more than WP:IDONTLIKEIT. Resolute 14:49, 2 February 2015 (UTC)
So, to be clear, you actually support junking MOS:INFOBOXFLAG in its entirety? Because that's what you seem to be saying. --IJBall (talk) 23:55, 3 February 2015 (UTC)
  • Support - If for no other reason, sorting out this flag-in-the-infobox thing would cut down on a lot of edit waring. My experience with flags involves their addition to the infobox in articles about American and Canadian towns and cities. A small number of editors support them, and this has led to endless reverts, edit wars, and nowhere discussion on multiple talk pages, such as here, here, here, here, here, here, and here. Insofar as flags being added to "infobox settlement" templates, both "sides" interpret MOS:INFOBOXFLAG differently. Those that want to add flags, believe "MOS:INFOBOXFLAG" defines towns and cities as "human geographic articles", which allow flags. Those opposed to flags believe "MOS:INFOBOXFLAG" defines towns and cities as "both human and physical geographic subjects" (with the example being Manhattan), where flags can only be added after consensus has been reached. I feel MOS:INFOBOXFLAG needs to clearly define what each of these entities mean. I also feel infobox flags are cosmetic cruft. Thanks. Magnolia677 (talk) 04:40, 3 February 2015 (UTC)
    • There is no ambiguity about the use of flags in the infobox for populated places. There may be some confusion and misinterpretation, but it means what it says:
      • 1) "Human geographic articles – for example settlements and administrative subdivisions – may have flags of the country and first-level administrative subdivision in infoboxes" - Every article for a populated place is an article for a settlement / administrative subdivision, and they are "human geographic articles" because humans have defined their boundaries. So Chicago, Edmonton and Astoria, Queens are designated as appropriate places to put flags in infoboxes.
      • 2) "however, physical geographic articles – for example, mountains, valleys, rivers, lakes, and swamps – should not." So there are no flags in the infoboxes for Mount Rainier (mountain), Grand Canyon (valley), Mississippi River (river), Great Salt Lake (lake) or the Okefenokee Swamp (swamp), and it would be appropriate to remove flags from the infobox for Lake Ontario.
      • 3) "Where a single article covers both human and physical geographic subjects (e.g. Manhattan), or where the status of the territory is subject to a political dispute, the consensus of editors at that article will determine whether flag use in the infobox is preferred or not." There are no mountain cities (where a city and mountain overlap), nor is there a valley city, river city, lake city or swamp city. But there are places where a settlement / city (a "Human geographic article") overlaps an island (an example of a "physical geographic article"). While the overlap is not 100%, Manhattan is offered as the example of a case of a "single article [that] covers both human and physical geographic subjects" because it is settlement (as a borough of New York City or a county in New York) that is also an island. Note that Manhattan is chosen specifically for that reason, and not New York City, Chicago, Edmonton or Los Angeles; This exception has nothing to do with the size of the place or the scope of the article. This is the only ambiguous situation where consensus is needed, because of the overlap of human geography (may be used) and physical geography (may not be used).
    • If we read what the Wikipedia:Manual of Style/Icons guideline actually says, we would have fewer problems (and edit wars based on misreadings). Alansohn (talk) 18:18, 3 February 2015 (UTC)
This is the policy that we are trying to change. Really, the "carve out" for Flag Icons for human settlements is completely nonsensical IMO, and contrary to the spirit of MOS:INFOBOXFLAG as stated in its first 1-2 paragraphs. If that stays in, then I really think MOS:INFOBOXFLAG needs to be junked as a guideline in its entirety, as it's mishmash of mess right now. --IJBall (talk) 23:48, 3 February 2015 (UTC)
If Manhattan, as Alansohn asserts, "is chosen specifically" as an example of a city that is also a physical geographic article, simply because it is an island, then you'd think "island" would be included as one of the examples listed at MOS:INFOBOXFLAG of what a "physical geographic article" is? Instead, it specifically doesn't mention "island"; it states "physical geographic articles – for example, mountains, valleys, rivers, lakes, and swamps". Again, MOS:INFOBOXFLAG needs to be clarified. Magnolia677 (talk) 23:55, 3 February 2015 (UTC)
It seems clear that under the current MOS islands should be part of that. Is Manhattan an article primarily about a borough on an island (that's a flag icon), or is it primarily about an island with a borough on it (that's no flag icon)? Reasonable cases can be made for either. I have currently no opinion about whether that policy is good or should be changed, but that islands logically belong in the category physical geography is obvious, and arguing about that borders wikilawyering. Martijn Hoekstra (talk) 10:52, 5 February 2015 (UTC)
If a guideline is that prone to misinterpretation by intelligent people, it's a clear sign that it needs to be clarified. In many cases, possibly including this one, the guideline is actually more complex than is really needed, and some compromise could be made in the name of simplicity. The average 100-hour editor should not have to spend a lot of time studying the nuances of a guideline to apply it correctly. ―Mandruss ☎ 00:01, 4 February 2015 (UTC)
  • After many years and many, many major disputes about the use of flag icons, I do not believe that they are ever appropriate in infoboxes, under any circumstances, with the exception of the country's flag on the article about the country. Edit warring about flags has resulted in some of the most contentious and damaging disputes on this project over the years. In fact, I would like to see the flag icons severely restricted so that they aren't present in templates either; whether people realise it or not, all those flag icons in the templates at the bottom of pages costs more load time than the actual written content of the page. Risker (talk) 23:55, 7 February 2015 (UTC)
    Exactly. They may look pretty, but there is never a good use of flag icons in the infobox. These lists, even the ones in the infoboxes, need to be moved to the appropriate sections and leave the infoboxes to the bare minimum. This will happen some day, but right now there are too many people who simply want them there for no other reason than that they want them there.--JOJ Hutton 00:59, 8 February 2015 (UTC)
    Yep. Classic I just like it. ―Mandruss ☎ 01:18, 8 February 2015 (UTC)
  • Comment And some people might think they are useful when they are used in lists in the infobox, such as the examples previously mentioned, but what about This Bullshit on the Billy Casper and just about every Golf biography. This is clearly not a list and is clearly unnecessary to convey information. Unfortunately a single user has every single golf biography on his watch list and resists any and all attempts to remove these unnecessary decorations from the infobox. The user uses no other explanation other than that they are used. Huh?--JOJ Hutton 18:58, 8 February 2015 (UTC)
    • This is what happens when you leave too much to editorial judgment. To paraphrase an oldie but a goodie, if it weren't for bad editorial judgment they'd have no editorial judgment at all! ―Mandruss ☎ 19:05, 8 February 2015 (UTC)
  • Let me know when it's over I personally don't think they belong in the infoboxes of any human except heads of state or founders of nations, but others disagree. I would rather not see them in articles for geographic locations, unless it is the flag for that specific location (national flags for nations, sub-national--provincial, state, county, city, etc.--flags for those areas) but it's currently an established practice to include all national flags in sub-national regions. The way to deal with this is to change consensus, not edit wars on individual articles against established norms. Walter Görlitz (talk) 00:21, 9 February 2015 (UTC)
  • This problem has been solved! An editor went into Wikipedia:Manual of Style/Icons and arbitrarily changed the wording of the Manual of Style so it supported his own interpretation. No need for consensus anymore. Magnolia677 (talk) 23:18, 9 February 2015 (UTC)
  • Keep as is most guidelines are imperfect and subject to wikilawyers' quibblings, but what was decided was a compromise that has ended the edit wars on whether flags should or shouldn't be on certain infoboxes. Truth is, the flags are all over the place: in geographic articles, sports articles, diplomacy articles, military articles, biographies, etc. {{flag}} says it's used on 398,000 articles. So, any change will inevitably mean lots of work of doing/undoing this - and no doubt more work when Consensus changes, which would better be spent in building an encyclopedia. Carlossuarez46 (talk) 20:46, 12 February 2015 (UTC)

Display of pending changes notice when latest revision is accepted

On pending changes protected pages, there is a small notice with some information on pending changes that is automatically inserted at the top right of the page, located on the left of the traditional protection icon, see e.g. at Red Hot Chili Peppers. Note that the accepted (latest) text is not visible to unregistered users. This functionality substantially duplicates the protection icon, isn't as customizable as the later since it's hard-coded, and is useful only when the latest version has not been reviewed (since it indicates that the latest version is unreviewed). I propose to change the behavior of this notice when viewing the stable version, so that it is shown only when the latest version is unreviewed (i.e., is pending). This way, it doesn't duplicate the protection icon and its presence is a signal making it more obvious when there is a pending revision. This would only affect unregistered users (who always see the stable version) and registered users having set their preference as 'show stable version'. From what I can see, this needs a bug request. Cenarium (talk) 00:42, 5 February 2015 (UTC)

Good idea. The hard-coded icon combined with the lock icon seem especially redundant when viewing a pending-changes protected article while logged-out. (Which always shows the stable version.) Tony Tan98 · talk 02:29, 5 February 2015 (UTC)
I believe that idea should be filed under this project on Phabricator:. Whatamidoing (WMF) (talk) 00:54, 12 February 2015 (UTC)
@Whatamidoing (WMF): I've made a commit allowing such customization that awaits review. Cenarium (talk) 19:05, 16 February 2015 (UTC)

Pre-Speedy Deletion tag

I propose the creation of a Pre-speedy deletion tag. I have been on new page patrol for a while now, and one thing that continues to annoy me is people prematurely tagging articles. I feel you need to give the person at least 15 minutes to add content, and in most cases, justify its notability. I created the tag you see below and used it for about 3 days. It was very successful it letting other editors know that the article was already being watched and should not be tagged yet.

Example: {{db-pre}} Unit388 (talk) 05:39, 7 February 2015 (UTC)

  • Strongest possible oppose. You are an extreme new user here with only a few days and very few edits. You need to understand that such proposals are discussed in depth at their respective talk pages and are expected to reach a consensus long before even a test is deployed. I have already deleted your unilateral work once and you have flagrantly recreated it again. Not even I get to unilaterally make new policy on Wikipedia - we do things in collaboration here. --Kudpung กุดผึ้ง (talk) 05:46, 7 February 2015 (UTC)
Kudpung it was a constructive attempt to improve the encyclopedia. We are not a bureaucracy and we encourage editors to be bold, even new ones. I don't think the idea of a notice warning that a CSD may happen if it is not improved is a radical change. It is not as though Unit was suggesting the use of the tag to be be mandatory. The argument that some time should be given to meet standards before CSD is applied seems like a good one. Chillum 06:33, 7 February 2015 (UTC)
Ironically, Kudpung violated speedy deletion to enforce speedy deletion. Restore it, Kudpung, take it to TfD if you have a problem with it. Oiyarbepsy (talk) 07:13, 7 February 2015 (UTC)
No he did not. The deletion was consistent with WP:CSD#T2. The template did make statements that were a misrepresentation of policy. While he may have handled things better the deletion was not the problem. Chillum 07:48, 7 February 2015 (UTC)
    • I think it goes without saying that I think people should not bite and should assume good faith... --Biblioworm 15:57, 7 February 2015 (UTC)
      • AGF? sure. But BITE? Lets not kid ourselves on that point. This is a new account, but not a new user. If it is who I believe it is, I am mostly just curious to see how long it will be before they fall back into old habits. Resolute 17:39, 7 February 2015 (UTC)
        @Resolute: How can you tell this is not a new user? --User:Ceyockey (talk to me) 20:37, 7 February 2015 (UTC)
        New users don't have the system savvy this one does. They don't start out with new page patrolling - they wouldn't even know what it is. They typically don't understand how to create templates and don't form the sort of convictions that Unit388 displayed from basically their first edit. This is an account with an agenda. The proposal itself is fine and dandy, but I dislike when histories are masked. Resolute 19:31, 8 February 2015 (UTC)
        Newbies aren't always clueless. What if he's a former IP, or a legitimate clean start? We shouldn't make legitimate users play clueless when they're really not. After all, I did start with NPP (I stumbled across it somehow), so I guess that I have to be hiding my history, right? As the essay says, we should focus on improving Wikipedia rather than spend our time trying to figure out what sinister "agendas" an intelligent newbie has. --Biblioworm 13:34, 11 February 2015 (UTC)
        Also, I believe that one of the persistnt complaints about NPP is precisely that too many newbies are involved. (I don't know if it's true, or what percentage constitutes "too many", but it's been a common complaint.) WhatamIdoing (talk) 01:35, 12 February 2015 (UTC)

Where this would be useful is for re-creation speedy deletes. Non-admins can't tell if a page actually is a re-creation and need admins to review the previous version to compare. I can't say anything about the tag created here, since it was deleted. The concept described by the original poster does not obviously violate policy. Oiyarbepsy (talk) 07:13, 7 February 2015 (UTC)

The example was deleted but have a look here if you want to see what it looked like. https://en.wikipedia.org/wiki/User:Unit388/draft-speedy Unit388 (talk) 07:16, 7 February 2015 (UTC)

I think a tag like this is a good idea. But, it's incomplete. It shouldn't be the obnoxious deletion-red, and it needs to print how long ago the tag was placed in case the original placer forgets to check up on it. Also, the text size is obnoxiously large. Oiyarbepsy (talk) 07:20, 7 February 2015 (UTC)

I agree that the original implementation was not ideal but this is a wiki after all. I have read the deleted template and I think if something like this is developed we should jut start fresh. A carefully crafted tag by a group of editors could provide a much needed optional choice to give editors time to salvage their content. I have seen many times a CSD'd article been undeleted and brought up to standards, why not skip the middle part? Chillum 07:44, 7 February 2015 (UTC)


Well if we are having to start fresh, here are some things we can keep/add/remove:

  • Red backround
  • Big red cross
  • Includes the text "Marked for Pre-Speedy Deletion"
  • Includes the text "do not mark this page for speedy deletion"
  • Includes the name of the user who placed the tag
  • Includes time created stamp(or some type of countdown)
  • Includes warning not to remove the tag
  • Includes justification for placing the tag
Unit388 (talk) 09:13, 7 February 2015 (UTC)


Alright I was able to get a clock going, but its not fully operational yet.

{{User:Unit388/draft-speedy|Unit388}}

Unit388 (talk) 10:09, 7 February 2015 (UTC)

I just took the liberty of changing the formatting of your draft. The heading code was doing unpleasant things to the section headings here. —C.Fred (talk) 17:06, 7 February 2015 (UTC)
  • Support, in principle. I think it would be a good idea for patrollers to have some tag to let others know that the author should have time to work on the article. However, I think the name and design of the tag could be improved upon. --Biblioworm 15:57, 7 February 2015 (UTC) Oppose, per Fuhghettaboutit's comment. I wasn't aware of that template's existence. --Biblioworm 00:31, 8 February 2015 (UTC)
  • Could this problem be solved by informing new page patrollers to not speedy tag new articles seconds after they're created? That appears to be the crux of the issue. Sam Walton (talk) 16:59, 7 February 2015 (UTC)
IMHO, that depends on the nature of the speedy. Copyvios should get speedy-deleted on sight. Spam gets a little more leeway to see if the article can be fixed. Personally—and even though I'm an admin and have the technical capability to delete on sight—I give the creators of an article about 10 or 15 minutes if I've tagged it A7. That gives them time to provide references or explain the situation. It would be nice to have that in-between of "Oh, that new page you just created? It needs some work ASAP or it will be deleted." —C.Fred (talk) 17:08, 7 February 2015 (UTC)
If you give people 10 or 15 minutes then I don't know what's stopping anyone else from doing so too. If we did want to take some steps towards helping new users we could include some directions on how to move a page to userspace to the A7 tag, or how to contact the tagging user to inform them you're about to fix the article and to please remove the tag. This seems like a convoluted solution to a simple problem. Sam Walton (talk) 17:28, 7 February 2015 (UTC)
  • I also support the concept, in principle. I've thought about adding one particularly for A7 articles with a message along the lines of "This article, in its current state, is a candidate for speedy deletion. It was recently created, so the creator is being granted more time to expand the page. If you are the creator: Please expand the article to clearly state how the subject is notable, significant, or important, and please cite reliable sources independent of the subject that show its notability. If you are not the creator: please allow the creator of the page to improve the article. If, however, a reasonable period of time has passed and the article has not been worked on, feel free to proceed with the speedy deletion process." —C.Fred (talk) 17:02, 7 February 2015 (UTC)
  • Oppose - We have a conspicuous warning above the edit window when creating new articles. We also have draft space, user sand boxes and an article creation process. While I agree that most articles should not be tagged for speedy deletion seconds after creation, I don't think placing a four day (or even four hour) speedy deletion moratorium is helpful. I might have a different opinion if we didn't have nearly 10,000 unreviewed articles, many of which should be deleted for various reasons.- MrX 17:40, 7 February 2015 (UTC)


That 3 day countdown is an example. The intent was to have a 15 minute clock.(Turns out template coding is hard!) Unit388 (talk) 22:50, 7 February 2015 (UTC)


  • Oppose - As noted by MrX, editors should not create incomplete articles in article space, and incomplete articles in article space may be speedied. Adding the content or references is what draft space or named user space are for. Robert McClenon (talk) 17:57, 7 February 2015 (UTC)
    @Robert McClenon: "...editors should not create incomplete articles..." ← Sorry, but this is not a sensible statement. 99% of articles are incomplete, and those which are "barely there" are suitable for being tagged with {{stub}} and it's family of templates. --User:Ceyockey (talk to me) 19:40, 7 February 2015 (UTC)
    I meant, of course, that editors should not create very incomplete articles, articles that are so incomplete that they qualify on their face for speedy deletion. Robert McClenon (talk) 19:48, 7 February 2015 (UTC)
    @Robert McClenon: I'll not think "of course" when seeing a comment like you made because there have been editors who feel exactly as you stated (now I do not count you among them, as you've clarified) who feel that even the stub I created here (and subsequently expanded) should not be in article space as it is not of sufficient quality for any encyclopedia. Fortunately, that type of editor has gone nigh on extinct over the past 10 years. --User:Ceyockey (talk to me) 19:55, 7 February 2015 (UTC)
    Actually, Robert, the existing CSD policy says that you should not tag articles for speedy deletion on grounds of being incomplete (A1 and A3) during the first 10 minutes or so of their existence. The only obvious difference between what the new editor wrote and what the policy already says is that the one says "about 10 minutes" and the other says "about 15 minutes" (and generates an edit conflict when you add it, which is highly undesirable [because inexperienced editors usually lose their work—the very work you were demanding—when they encounter an edit conflict]). WhatamIdoing (talk) 01:35, 12 February 2015 (UTC)
  • Oppose—There are multiple existing options for giving editors with a desire to delete on sight pause. Among these are a) the {{stub}}—related templates I mentioned above, which signal "this article is just barely getting started; please help to build it" and b) {{In use}}, which signals that there is editing in progress and that deleting it will just interfere with improving the article. I think there are other examples to add to these. With respect to the {{In use}} template, if there is not a timer attached to this, it would be a good thing to add one. Another possibility is to auto-add either a stub or in-use template when an article is created. --User:Ceyockey (talk to me) 19:45, 7 February 2015 (UTC)
  • Oppose I can't really see the point. If an article looks like it's really got a future but is incomplete, it's better to suggest userfication. If it looks decidedly iffy, one might as well use prod. If it's a really speedy speedy case, it shouldn't be used. The template above looks more intimidating to me than the actual speedy template. I do agree that some things are being tagged too soon, but that doesn't mean they're going to get deleted that soon. Spam, attack, blatant hoax and copyvio - yes, they go asap. And total no hoper A7s like "Shaun is in year7 and he likes mrs Dobson and plays fotball"... Other things can wait for around an hour, and I for one leave them around that long. Peridon (talk) 20:19, 7 February 2015 (UTC)
  • Oppose Speedy deletion is a deliberately simple and quick process with strong community support. There is no need to addd a pointless new layer of process to it. Beeblebrox (talk) 21:22, 7 February 2015 (UTC)


I agree that it would be better if editors just waited abit, but unfortunately it doesn't work like that. It seems to have become like a race to see who places a tag first. Another thing i'v noticed is that admins don't really assess the articles creation time, if they agree with the tag they delete it.(This is a good things, it means once reviewers have done their job the deletion can take place fast). So, the area of error is the users. I think new page patrol should should become more a review process. A reviewer takes an article under their wing, they are then responsible for the follow up. Unit388 (talk) 22:46, 7 February 2015 (UTC)


Try this for size (with proper formatting):

In my view, any tag like this should be optional and only for new pages. Oiyarbepsy (talk) 21:35, 7 February 2015 (UTC)

  • Totally oppose, since the concept already exists: Articles have WP:PROD, templates and some file criteria have a 7-day waiting period, and G13 has a 6-month wait. The route for creating delayed speedy deletions would be to propose a new criterion, or propose changes to an exiting one. Not pursuing either of the paths I just mentioned and supporting this discussion's changes equate to unnecessary instruction creep. Steel1943 (talk) 22:52, 7 February 2015 (UTC)
  • Oppose perl Steel1943 Steel makes a very strong point that this is already a thing in the criteria that need it. I also agree that any template must follow a change in policy that supports it. If we choose to alter the policy so that a warning time can be given then we can create such a template or just modify an existing one. Chillum 23:01, 7 February 2015 (UTC)
  • Oppose as redundant with existing template. Er... guys and gals – what this discussion seeks already exists, and in a form that does not transgress some of the concerns raised here, and exactly tracks the consensus from many discussions that resulted in Wikipedia:Criteria for speedy deletion#cite_note-Hasty-6. I created it in 2008 and though it is used, and to good effect, obviously it needs better advertising or this conversation would have been cut short by someone bringing it up. See {{hasty}}.--Fuhghettaboutit (talk) 23:10, 7 February 2015 (UTC)
  • Yeah... shudder... possibly the most frustrating thread I've ever been involved with at Wikipedia, because most of the people responding just did not understand the template's purpose, use background or function.--Fuhghettaboutit (talk) 00:01, 8 February 2015 (UTC)
  • I'm unable to read in depth here, but multiple similar other templates already exist and integrating functionality into the Db templates to ensure the article isn't deleted as csd if it's too new and still being worked on is pending a magic word that was requested on bugzilla quite some time ago. I'm unable to look up the number right now, but will as soon as I can for anyone interested. — {{U|Technical 13}} (e • t • c) 03:08, 8 February 2015 (UTC)
  • Oppose - Personally .... I see no point in it whatsoever, We have different and imho far more helpful tags so yeah I just don't see the point. –Davey2010Talk 03:58, 8 February 2015 (UTC)
  • Oppose - Per Fuhgettaboutit: the Hasty template is sufficient for the proposed purpose. Shanata (talk) 06:40, 8 February 2015 (UTC)
  • Well, yes, but the Hasty template is only placed after the Speedy tag has gone (if there's even time to do that... these things move fast sometimes). Besides which, 15 minutes? Reallty? What's your hurry? It it's not libel or penis vandalism, there's no hurry. Relax. Don't let the "speedy" in "speedy deletion" confuse you; it really means "no-brainer deletion", speed in the sense of not requiring the man-hours of a well-populated and drawn-out discussion than speed in the clock or calendar sense -- again, aside from emergencies.
We want to avoid placing speedy templates if it is at all reasonable to do so. We do have {{Under construction}} which looks like this

Category:Pages actively undergoing construction

and which is usually placed by the editor doing the work but can be placed by anyone I suppose, and allows several days for the article to be brought up to some reasonable level of qualify. I'd recommend to the OP and anyone else who comes across an article that's no good but 1) isn't an emergency (libel etc.) and 2) has some reasonable chance of possibly becoming a marginally useful article, to apply this tag. Jesus, give the guy more than 15 minutes for chrissakes. Herostratus (talk) 14:49, 8 February 2015 (UTC)
I think that's an excellent point point. Between the under construction tag, the hang on tag, and PROD we already have this covered. All three have been in use for a very long time and are supported by the community. This pre-speedy isn't and shouldn't be. It's an overly simplistic idea that would inevitably cause more problems than it solved. Beeblebrox (talk) 19:36, 8 February 2015 (UTC)
  • Oppose - an alright idea in the spirit of not biting the newcomers but this is what WP:PROD is for. Speedy deletion is for pages that have absolutely no hope whatsoever of being accepted as articles, because they're nonsense, they make no attempt to establish notability, they're obviously made up, they are blatant attacks, they have technical issues, and so on. Pages which qualify for speedy deletion are obvious - that's why we allow bypassing the normal collaborative deletion processes (i.e. discussions). The criteria are not for articles which just need more time or more content to get better, and someone who tags such an article for speedy deletion is abusing the process. Ivanvector (talk) 15:13, 9 February 2015 (UTC)
  • Oppose Speedy Deletion is not lightning fast (though it could be), it's designed to dispose with unnecessary red tape and discussions in which there is no hope for besides deletion via our regular speed deletion processes (Prod, XfD, etc). Criteria for Speedy Deletion have been finessed and debated for a significant time and we've come to a community endorsed consensus on how to interpret the Criteria. The main complaint, as I see it, is that nascent pages are being nominated for CSD far too soon after their creation. If that's the case, creating a technical speed bump does not help with operator error. Train people using the NPP tool on how to consider things better or remove them from the activity stream (either via polite request or topic ban). Bike-shed solution in search of a problem to fix. Hasteur (talk) 18:57, 12 February 2015 (UTC)
  • Idea: modify the speedy deletion template to append a category when it is added. The category should be the current time (GMT) rounded to the nearest 10-minute mark, plus an agreed-upon Grace Period. Since speedy deletions are supposed to be speedy, a date is not required, which allows the categories to be continually reused. The Grace Period may be very short, or nonexistent, for certain deletion reasons i.e. random ranting about your neighbor complete with address and credit card number, but should be hours long for most reasons like patent nonsense or completely uncited. The template, as pasted, should indicate how long the Grace Period is. Edits by someone other than who posted the template that alter the time listed or remove it can be flagged by abusefilter for further examination. Wnt (talk) 16:52, 17 February 2015 (UTC)
Why on earth would we want to allow an hours-long grace period for patent nonsense or completely empty pages? Nothing of value is lost when they are deleted. Beeblebrox (talk) 23:34, 17 February 2015 (UTC)

Revisiting past proposal – Viewdelete userright

NO CONSENSUS
There is no consensus to implement this proposal at this time. HiDrNick! 21:08, 20 February 2015 (UTC)

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

I know that this idea has been around since the proverbial dawn of time, and a past discussion from 2008 flatly rejected this kind of userright. Almost seven years have passed, yet the reasons for opposing at the time are every bit as relevant today as they've ever been (with the caveat that RfA has become much harder to pass, a reality that I consider irrelevant to the merits of this proposal). Nevertheless, I figured it might be worth another shot – with some modifications.

Speaking as a non-admin, there have been a number of instances where I’ve wanted to review deleted material for research purposes. For instance, one time I was thinking of creating a replacement article for this one, based largely around its negative counterpart (but with stricter inclusion criteria). This has since been done, so the point is moot. At the time however, I faced a conundrum. In order for me to assess whether that was a good idea, I needed to know what the page looked like beforehand so as to develop a better understanding of why it was deleted. Having the ability to view these pages myself would have been far more convenient than asking an administrator for assistance. This is just speaking for myself; I’m sure there are many editors who would use that ability responsibly were it granted to them, but are not interested in full adminship or would not pass an RfA due to a lack of relevant experience. Another example would be Carrite. In 2013, he was nominated for adminship by Dennis Brown on a temporary basis so he could have the ability to review evidence in the Richard Arthur Norton ArbCom case without the tedium of having to consult administrators in order to do so.

The foundation has come out in opposition to any sort of initiative that aims to increase access to deleted (and therefore, sensitive) material. I'd imagine that their strong reservations still stand today, perhaps even more so than at the time. This brings me to my next point, and the major alteration to the 2008 proposal: what I’m proposing is not a tool that would be given out at an administrator’s discretion to any old editor asking for it via WP:PERM. Viewdelete would be granted following a community discussion similar to RfA, wherein the basic question being asked is: “do I trust this user with the ability to view deleted content?” Or, to put it in another light: “will granting this particular user viewdelete cause the WMF legal issues, put anyone’s information at risk, open the flood gates to obvious abuse on their part, or make a mess for administrators to clean up?” After a lengthy discussion (say, 4-7 days, depending on what is agreed upon by the community), either an administrator or a bureaucrat (whoever is tasked with the granting of this tool) will assess the consensus and come to a decision. The threshold for granting viewdelete would therefore be quite high.

Additionally, the restrictions placed on the application of viewdelete would be stringent. In particular, it must not be used for the following purposes:

  • Restoring content after it has been speedily deleted per CSD
  • Restoring content that was deleted based on community consensus at any XfD page
  • Revealing sensitive information for any reason whatsoever, whether publicly or privately

Ideally, administrators would have the authority to automatically revoke viewdelete in the event that it has been misused. I've still not worked out all the fine details of its implementation, which is something I figured could be handled by the community were this to go forward.

I feel that my proposal addresses most of the opposing points that were raised in the RfC from seven years back. Viewdelete would not be a userright that is given out to just anyone, but to people who are sufficiently tenured and thoroughly vetted by the community. The only question that remains for me is whether or not the WMF would be open to this particular suggestion; does this proposal address the question of legality to a sufficient extent for it to be implemented? If the community and the WMF are willing to consider this idea as it is phrased, then I propose we put it to a test run lasting around three months or so. Specifically, we would be looking to see whether or not the workload for the WMF and the oversight team is significantly increased. As this would not be given to just anyone who asks for it, but only to editors deemed trustworthy enough by broad consensus, I do not feel that the exposure of sensitive information would be an issue.

Thoughts? Kurtis (talk) 16:37, 4 January 2015 (UTC)

  • I'm in favor of it, obviously, but it's hard to see too much traction for creation of such a specialized user right. Carrite (talk) 00:53, 5 January 2015 (UTC)
  • Strong Oppose for the same reasons this usually gets opposed: would create legal issues with minimal-bordering-on-zero benefit to offset them. Think of it this way: Viewdelete is the most "dangerous" of the admin tools, at least in the legal sense, as revealing libelous or personal deleted info can't simply be reversed the way a bad protection or block can be. Therefore, the threshold for granting that right would be just as high as RFA itself. Anyone interested in it should just go through RFA. Andrew Lenahan - Starblind 01:33, 5 January 2015 (UTC)
(edit conflict × 2) Why should a perfectly capable and trustworthy individual be forced to undergo a full RfA and all the garbage associated with it to be able to see deleted pages? Say I don't want to be able to protect a page, I don't want to be hassled by other editors asking me to undertake admin tasks, or I don't care about the block status of other users. Why can this not be an option? Dustin (talk) 01:45, 5 January 2015 (UTC)
For the same reason you can't access a police station's evidence room without being a cop, or a bank vault without being a banker: you want keys to the kingdom, you get the scrutiny that comes with them. Hell, if anything passing an RFA is a pretty low bar for the all-you-can-eat buffet of libel, copyvio, and weird details of highschoolers' sex lives that comes with it. Really it would make more sense for Viewdelete to be available not to every admin but admins who have an understanding of libel and intellectual property laws in the US. Andrew Lenahan - Starblind 02:18, 5 January 2015 (UTC)
Admins are supposed to be janitors, not cops. they certainly don't undergo the rigorous (albeit occasionally flawed) training, supervision and vetting of the latter. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:03, 12 January 2015 (UTC)
It is the most "dangerous" of the admin toolbox, yes, but it is also the one least likely to be abused in the hands of a responsible editor. "I want the ability to view deleted pages and revisions" is not going to fly at an RfA – period. If you're not expressing any interest in dispute resolution, XfD, or really anywhere you'd expect to find an administrator, then the community would see no point in granting the bit. Being an administrator requires more than just being responsible; it requires discretion (as in, good judgment). The only real discretion I would expect from viewdelete is the good sense not to be going around and revealing sensitive information. Remember, I did say that the threshold would be very high. Kurtis (talk) 02:20, 5 January 2015 (UTC)
"it is also the one least likely to be abused in the hands of a responsible editor" Kind of by definition, in the hands of a responsible editor no tool is likely to be abused. But for a deceitful editor, I would say it's the most likely to be abused - because unless you actually undelete the page, it's not logged anywhere. So if someone was giving deleted information out off-wiki, it would be nearly impossible to trace. RFA looks at competency because that's really all we can measure. We generally just assume trustworthiness. Unless someone is actually caught lying or something, I don't know how we could have a community discussion purely about the trustworthiness of an editor that's not just a grudge-airing and is more reliable than a coin toss. Mr.Z-man 04:11, 5 January 2015 (UTC)
I can definitely understand your concern about the possibility of gaming the system, and about the difficulty of passing such a process. I'm not suggesting that viewdelete should be easy to obtain. Really, such a system would not be much easier to game than the one that exists now, assuming someone really wants to get access to that kind of information. I see people opposed at RfA for all kinds of reasons that have nothing to do with competence or trust: in this RfA, for example, an editor who is clearly trustworthy was denied access to the tools because he did not demonstrate sufficient experience in administrative areas to sway a large enough portion of the commentators into supporting him. If someone with a similar tenure to his were to apply for viewdelete, I'd imagine that they would pass. Kurtis (talk) 05:09, 5 January 2015 (UTC)
  • (edit conflict) My short answer would be: 'If you want to view deleted pages, then you must run for adminship.' I appreciate the time you have taken to post the above suggestion but I'm fairly sure that the Foundation would not allow it. Perhaps Philippe (WMF) could chime in here. Secondary issues are that creating yet another user right would create more bureaucracy - it would almost certainly need an RfA style application (with all its issues) for the right (so again, why not apply for adminship?). I'm not personally aware that the demand for such a right is sufficiently compelling, particularly as all proposals for unbundling admin tools are perennial failures.
Finally, I reject the notion that RfA has become much harder to pass:
The RfA system has increased its level of maturity since the watershed year of 2007 prior to which the tools were handed out following RfAs of very low !voter participation. We now have a very high turnout at each RfA and even the revered 100+ 'Support' RfA are now perectly commonplace. That said, the !voters at RfA are still very much a transient pool of users, so in reality the criteria are set anew for each RfA depending on who turns out to !vote. By 2014 RfA was also no longer quite the humiliating process it was when I started WP:RFA2011 and Mr Wales supported tha initiative with his famous "horrible and broken process" statement. --Kudpung กุดผึ้ง (talk) 01:42, 5 January 2015 (UTC)
The most important part of my proposal is where I outlined the hypothetical process as being community-driven. This is not like being granted rollback rights; it's much more akin to adminship. As I've said above, an administrator is not only someone who has proven themselves trustworthy enough to be granted access to a certain degree of sensitive information, they must also demonstrate an ability to make tough judgment calls and a willingness to partake in maintenance work or dispute resolution. No one is going to be granted adminship just because they would like access to deleted revisions, even if they were trustworthy enough to have such permissions, as that would be a virtual waste. Kurtis (talk) 02:20, 5 January 2015 (UTC)

I think this a bad idea. If a view-deleted editor later decides to become an admin, they basically would have to go thru a second RfA. If you want to unbundle admin tools, a better approach would be a user right to place limited blocks and semi-protects. Oiyarbepsy (talk) 04:51, 5 January 2015 (UTC)

I think the researcher permission only applies to seeing the revision history, as opposed to the content itself. The whole point of this proposal is so that ordinary editors don't have to go to an administrator to view deleted pages. If they are deemed trustworthy enough, they can do so themselves. Kurtis (talk) 15:46, 5 January 2015 (UTC)
Correct, it is much like a RevDelete where only the text is deleted. — xaosflux Talk 19:37, 5 January 2015 (UTC)
  • I agree with the sentiment of unbundling viewdelete from the mop and bucket for purposes of article creation. Wbm1058 already made the excellent point of using REFUND for that purpose. I oppose the nomination's idea of an RfA-like process because RfA is probably too stringent. I don't think the flag should be given out by any single admin, either. Whatever the process, I'd recommend the permission be temporary and responsive to a specific request. "In order to write an article on X I'd like to see the deleted versions of Y and Z.". If the flag automatically hits sundown we can limit contempt for the permission. My question would be, how often does anyone really need to see a deleted version? Chris Troutman (talk) 20:24, 5 January 2015 (UTC)
  • Strong oppose per my concerns voiced at the debate at Commons. This is a solution in need of a problem. --Tom (LT) (talk) 22:35, 5 January 2015 (UTC)
    There is or might be a real problem in need of a simple solution: Some days ago I stumbled over two files on commons arriving there as thumbnail of what still was or used to be a decent image here. I think that license reviewers (folks with this right, a bot if that's all what it takes to figure out that 100KB on commons cannot match a deleted 1MB here) should have the right to review what exactly happened here years ago. –Be..anyone (talk) 07:51, 6 January 2015 (UTC)
  • I've read all this and I simply do not believe there is a real problem that needs solving here. As creating this user right would be a long and contentious process it does not seem worth the effort. Beeblebrox (talk) 23:33, 6 January 2015 (UTC)
  • Oppose per all the usual reasons. Let's just keep it as a package deal. -- œ™ 02:58, 7 January 2015 (UTC)

From what I can see, most of those in opposition appear to be sysops. Not to say sysops' opinions don't hold equal weight, but I think it would be best to do more discussing before going into all of that !vote stuff. Dustin (talk) 03:04, 7 January 2015 (UTC)

  • Oppose, IIRC the WMF has explicitly said that users must go through RfA or an equivalent process to get this, so there's really no point in having it separate. ansh666 05:58, 7 January 2015 (UTC)
  • Oppose as a solution in search of a problem. Stifle (talk) 14:04, 7 January 2015 (UTC)
    • This isn't personally directed at you Stifle, but I'm really beginning to hate this sentiment. It's used to rebut just about any proposal, and it says very little. Proposers spend a long while typing detailed descriptions of why a change might be beneficial, only to be dismissed with such a flippant and nearly meaningless sentiment as "solution in search of a problem". In this particular case, the proposer even outlined a very specific situation in which this restriction was a problem for him. Stifle, please don't feel personally obligated to reply to this, as like I said, this isn't directed at you as much as a general comment on the proliferation of proposals getting shot down on these grounds which boil down to "the status quo is just fine, change is scary and unnecessary". Gigs (talk) 17:09, 7 January 2015 (UTC)
  • Oppose - First, there have been successful single bit need RfAs in the past, so the current RfA process can be used in that case. And since RfA-esque community support is needed for the viewdelete right anyways I don't see the benefit of breaking it out as compared to say something like template editor. I disagree that RfA's have gotten harder having !voted in them over the years except for the edit count inflation they seem less contenious these days although fewer in number. I can see myself possibly supporting other bits being split off ( and have done so in the past ); but—especially given the requirements from legal—not viewdelete. PaleAqua (talk) 17:30, 8 January 2015 (UTC)
  • Oppose - the {{cent}} headline for this discussion asks whether we should "grant highly trusted users with the ability to view deleted content through a consensus-driven process". WP:RFA is the "consensus-driven process" by which the community "grant[s] highly trusted users" with this ability. The Wikimedia Foundation have also stated that there are legal issues with this kind of change. I'd certainly be happy to vote support in an RfA that sought to have time limited access to deleted revisions and pages if I trust the user in question: if someone were to propose allowing bureaucrats more latitude to, say, close an RfA as "promoted for a temporary period of X months" rather than either promoting or not promoting, then the RfA process could accommodate this kind of request. The only reason I can see to have a non-RfA process to grant this right is so that there is less participation and consideration given to a request for the unbundled right rather than the full administrative toolset. I'm not comfortable with this user right being granted with less participation than an average RfA gets. None of that changes the fact that RfA does suck in a lot of ways. The answer to that is to try and find ways to fix RfA rather than short circuit the valuable democratic oversight function that RfA provides. —Tom Morris (talk) 16:04, 11 January 2015 (UTC)
I was actually thinking that "viewdelete" requests could take place on the same page as RfAs and RfBs. I wasn't intending to suggest that this be a process where scrutiny could be evaded. Kurtis (talk) 16:51, 11 January 2015 (UTC)
  • Oppose in three points. First, I don't really see how it would be useful to create a bureaucracy to give out view-delete rights. Going based on my own experience, I can only think of one deleted article in the nine years I have participated on Wikipedia that I have ever wanted to view post-deletion. And that was only because the result of the discussion was merge and delete, but the merge was botched and a citation was lost. How many times can any editor really say they've needed to access content from a deleted article? Is it really that many times to justify having this ability enabled indefinitely? I don't believe it is.
Secondly, I believe WP:Requests for undeletion and CAT:RESTORE provide perfectly valid options regarding deleted content (CAT:RESTORE is a list of admins who are willing to provide deleted content). If an editor believes they are justified in viewing deleted content, then it shouldn't be too difficult to justify that at WP:UND. And to that point, as I've been thinking about this issue, one question comes to mind: does an editor need access to deleted content urgently? As the title of the essay WP:NORUSH goes, "There is no deadline."
Lastly, and above all else, there is a legal dimension to this proposal. If a representative of the Foundation can no longer say to a client's lawyer that sensitive deleted content is only viewable by "trusted administrators," then the project appears to be weaker. No matter how much trust we can invest in these certain editors who would be approved for the view-delete right, they are still not administrators. I believe it is in the best interest of the project that those people with view-delete be administrators. --hmich176 17:52, 11 January 2015 (UTC)
  • Oppose. I gave my main thoughts in my earlier comment. Now that voting has begun, I'll just reiterate that Adminship is about trust and competency. If you give a user only one of the tools and not all three, is it because you only have 33% trust and s/he is only a third as intelligent as a full admin? Anyone who wants one tool should be clever and industrious enough to convince the community that s/he would be competent with all three. --Kudpung กุดผึ้ง (talk) 20:07, 12 January 2015 (UTC)
    • If we refuse to give a user the tools, that says something about our trust. But if the user specifically asks for only one, that says something about the user. Maybe it says he doesn't expect a successful request. Maybe it says he doesn't want to be hassled by requests to block people. Maybe it even says that he doesn't want French spy agencies to arrest him and demand that he delete the article on Radio station military Pierre-sur-High again. The other editor's choice doesn't say anything about my trust in that editor. WhatamIdoing (talk) 22:35, 14 January 2015 (UTC)
  • I support the unbundling of the viewdelete and undelete user rights in the circumstances that I outline below and also the creation of some new user rights that I outline below.
    • I am under the impression that unbundling the viewdelete and undelete user rights would be acceptable if the rights were granted by a process that is practically identical to RfA (ie a community !vote, conducted over several days, with the opportunity to pose questions to the candidate etc). I think this would allow the same level of scrutiny that presently takes place at RfA.
    • We might also consider implementing multiple levels of deletion to avoid the problem that some deleted material is considered sensitive. What I propose to call "deletion level 1" would be for articles that are deleted for legal reasons or are otherwise considered to be sensitive (eg articles deleted as copyvios or for WP:BLP issues). What I propose to call "deletion level 2" would be for articles that are deleted for harmless reasons (such as possibly an article about a person who died in the year 1800, or a book published in that year, that was deleted solely on grounds of notability, which contained substantial content verifiable with reliable sources, and not sensitive in any way). It seems to me that the viewdelete and undelete for such a hypothetical "deletion level 2" could be handed out more freely, possibly at PERM or perhaps even given to all logged in users. This would be useful in that we frequently make very bad mistakes about notability (because GNG is so subjective and the SNG are incomplete in their coverage) and certain aspects of WP:NOT, such as failing to transwiki content to sister projects or deleting articles which ought instead to be rewritten or merged per WP:PRESERVE, and so forth. (And some of our exclusionary criteria are questionable, and consensus can change, and we might from time to time abolish particular exclusionary criteria, necessiting review of possibly large numbers of deletions done under them).
    • WP:REFUND is an extremely inefficient means of reviewing or restoring large amounts of deleted content, because it uses two people to do the work of one person and requires discussion between them that may be unnecessary. It is therefore not a viable alternative.
    • Since anyone can remove a PROD for any reason, and removed PRODs cannot be restored, it is not clear why only an admin can undelete an article deleted as an expired PROD. WP:REFUND appears to be an innefficient process for doing this. James500 (talk) 15:44, 14 January 2015 (UTC)
I indented your points to make it clear at first glance that it's one full statement instead of multiple unsigned comments. ansh666 21:45, 18 January 2015 (UTC)
  • Oppose - this is maybe a bit stale but I'm adding comments here anyway. I think that viewdelete is a right best left with admins. It's not terribly difficult to get an admin to help with access to or review of deleted content when the situation is appropriate, and whether or not such a request is appropriate is a decision best judged by admins, in my opinion as a non-admin. If a proposal to unbundle the deletion rights nonetheless requires candidates to be subjected to a process identical (or reasonably similar) to RfA, then it's not better than just making them run the RfA gauntlet. And I do think that such an unbundling should require such a process. Ivanvector (talk) 20:27, 23 January 2015 (UTC)
  • Comment correct me if I'm wrong, but don't we already have a consensus driven process aimed at highly trusted users that lets them review deleted material? I think its called "RFA" or some thing like that, and its purposes is exactly this. Why then do we need two versions of the same process? TomStar81 (Talk) 12:37, 29 January 2015 (UTC)
  • Comment. The 30-day period that would be typical for an RfC will run tomorrow, but this isn't an RfC. I'm just commenting to note that I've read the discussion and don't think it needs a formal closure, but I'm open to other suggestions. - Dank (push to talk) 11:41, 1 February 2015 (UTC)
  • Oppose Since most deletions aren't urgent, I see no need for this. If it were unbundling the blocking right, I'd be more likely to be in favor, since that can be urgent, but unless the deletion is a G10, it can wait.--Jasper Deng (talk) 04:33, 5 February 2015 (UTC)
  • Not a comment on the proposal, but I believe Kurtis meant to link to Wikipedia:Requests for adminship/Carrite rather than Wikipedia:Requests for adminship/Dennis Brown. ekips39 04:36, 5 February 2015 (UTC)
  • Oppose for all he usual reasons (I've gotten tired of listing them...). This is the umpteenth viewdelee proposal we've had lately - can we give these a rest for another year or so now? – Philosopher Let us reason together. 18:55, 6 February 2015 (UTC)
  • Oppose, mainly for the reason outlined by Starblind Cas Liber (talk · contribs) 03:57, 11 February 2015 (UTC)
  • Note - the similar (though not the same) user-right package Researcher already exists. - jc37 11:40, 16 February 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_118&oldid=1258091959"