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)

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)

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)
  • I've got basic functionality for watching up at User:Martijn Hoekstra/watchthingy.js but I need help from someone who knows what they're doing in JS (both to tie it to the little star, and to make the code not suck). Martijn Hoekstra (talk) 01:54, 13 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)
    • But blaming the foundation is just what Wikipedians do. If we don't have that, they what? Oiyarbepsy (talk) 21:28, 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)

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)

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)

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)

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)

• This is a sensible and simple proposal to address this issue in a community-centric way. --Guerillero | My Talk 00:00, 13 January 2015 (UTC)
• Support I usually don't touch these pages, but this seem like a wholly sensible proposal. I'd often wondered how sensible it for an administrator to define their own recall criteria. --ceradon (talk • contribs) 09:23, 13 January 2015 (UTC)
• Support tweaks perhaps needed to length limits to evidence, timeline before !voting, threshold. Support in principle. Hipocrite (talk) 12:59, 13 January 2015 (UTC)
• Oppose — We have a RfA system which a huge segment of the Wikipedia community feels is broken and this is a proposal to allow it to be revisited for any administrator again and again and again. Having ARBCOM continue to do it is infinitely more preferable to this idea. Regards, TransporterMan (TALK) 14:50, 13 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)

• I'm willing to support if someone can convince me that the process won't become a lynch mob like WP:CSN, WP:QP, etc. Stifle (talk) 16:26, 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)

  • • I also agree with MastCell's first paragraph & the first two sentences of the second paragraph, though my pessimism is not based on those two noticeboards alone. Ncmvocalist (talk) 14:32, 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)

• Oppose for many of the reasons given above, but mostly because, as Jerichoman said, it is a solution in search of a problem. – Philosopher ^{Let us reason together.} 00:39, 21 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)

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)

• Bringing back the ((wikify)) template would help here - sure, it's vague, but it's better than a bunch of minor issues being spelled out at the top of the article. – Philosopher ^{Let us reason together.} 00:43, 21 January 2015 (UTC)

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)

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)

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

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)

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)

div#template-documentation, #documentation-meta-data{
    display:none;
}

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)

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)

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)

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)
  • It is my own proposal, I have not discussed it with other WMF staff members. I wanted to bring it here first, because I care about what the community thinks. -- Tim Starling (WMF) (talk) 19:44, 29 January 2015 (UTC)
    • size for relative importance: does that mean you're using your staff account for this as a coincidence? Martijn Hoekstra (talk) 20:11, 29 January 2015 (UTC)
      • I have been instructed to use my WMF account for all edits made on work time. I argued for using WMF accounts only when speaking ex cathedra or performing an office action or whatever (i.e. never) but this was explicitly contradicted. I will add a note about this to my user page. -- Tim Starling (WMF) (talk) 20:24, 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)
        • Thanks! Now I can start thinking about the social effects ;-) --Stephan Schulz (talk) 09:35, 30 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]

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)

• This doesn't feel like a proposal at this stage; but instead, a very good idea which I hope comes to fruition.--John Cline (talk) 16:30, 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)

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)

• It's a bizarre claim that the flags in the Manhattan infobox draw attention - in fact all they appear to do is inform the reader of related flags Alanscottwalker (talk) 17:53, 1 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"? --RacerX¹¹ Talk to me^{Stalk 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. --RacerX¹¹ Talk to me^{Stalk me} 15:22, 2 February 2015 (UTC)

• Strong oppose. Unhelpful rule creep, and Mandruss' comment of 08:00 is quite right. Nyttend (talk) 12:58, 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)
  • That earns an automatic block, I hope? I can't make sense of the page history or I'd answer my own question. ―Mandruss ☎ 23:22, 9 February 2015 (UTC)
    • I'm not sure of the correct protocol for something like that, but even if we agreed with the change, shouldn't that change be reverted with an edit summary something to the effect of "This wording is currently being discussed at Wikipedia:Village pump (proposals)#Discussion (MOS:INFOBOXFLAG)"? The edit in question is still the current revision. And shouldn't the user be given at least some kind of informal warning? --RacerX¹¹ Talk to me^{Stalk me} 00:30, 10 February 2015 (UTC)
      • Meh... That change is not something even I would quibble with. The problem with that paragraph isn't the last sentence (current, or former, form) – it's the first half of the first one. --IJBall (talk) 21:37, 10 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)

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 Tan⁹⁸ · 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)

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)
  • Hey. He was being WP:BOLD. That is still an allowed behavior here, regardless of how it might annoy some editors. Please exhibit some good WP:BITE tolerance. --User:Ceyockey (talk to me) 06:18, 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)

• ...And, also oppose per Fuhghettaboutit since ((Hasty)) exists. In fact. I don't see any reference of that template anywhere on Wikipedia:Criteria for speedy deletion; information about ((Hasty))'s existence and use should probably be added to the speedy deletion criteria page. (Pinging Chillum since they also referred to this template in one of their comments below.) Steel1943 (talk) 02:27, 8 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)

• Wow, did not know about that. It is worth noting Wikipedia:Templates_for_discussion/Log/2013_December_1#Template:Hasty where this template underwent community review and was kept. Chillum 23:45, 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. –Davey2010^Talk 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

This project page or section is in the process of an expansion or major restructuring. You are welcome to assist in its construction by editing it as well. If this project page has not been edited in several days, please remove this template. This page was last edited by MalnadachBot (talk | contribs) 15 months ago. (Update timer)

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)