Wikipedia:Village pump (proposals)/Archive 144

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

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

---

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

Notability of terrorist acts

I see no guideline about notability and terrorist acts at Wikipedia:Notability (events) or Wikipedia:WikiProject Terrorism. Should terrorism be mentioned in the guidelines?

(I was just at Wikipedia:Articles for deletion/December 2017 Melbourne car attack which made me want to post here.)

Anna Frodesiak (talk) 02:03, 22 December 2017 (UTC)

• I think there should be some guidelines on terrorism or suspected terrorism as AfDs on this topic tend to defer to guidelines that are haphazardly suited for the topic and as a result are generally tense. For example, routine coverage is a regular but terrible argument for deletion - somebody blowing up a building or running a stabbing spree doesnt fall under "in other news" type news coverage. At the same time, this is a regular event and not every event is notable enough for a standalone. Mr rnddude (talk) 07:10, 22 December 2017 (UTC)
• We should be spending more time fixing the broken guideline that is WP:RAPID. No one ever heeds the advice "don't rush to create articles" but use "don't rush to delete articles" as a safety net; all the while, the actual content of WP:EVENTCRIT is willfully ignored. It will not matter if anything materializes from this discussion as long as we continue the broken RAPID system. Either make it an essay, an argument to avoid, or remove it entirely if editors want to ignore the half that doesn't suit them.TheGracefulSlick (talk) 08:49, 22 December 2017 (UTC)
• An article I look at in particular is the 2017 Notre Dame attack. The incident involved TWO people injured by a man yielding a hammer... The attack was not notable in the least but a biography has been written on the subject. This is my example on why these things are so complex. - Knowledgekid87 (talk) 14:48, 22 December 2017 (UTC)
• Yes. The way to fix WP:RAPID not being enforced for this topic is probably to update WP:Notability (events) to address the topic directly – even if we think "an event is an event, and the subject shouldn't matter". If two pages coincide against junk articles like 2017 Notre Dame attack, then such pages will be less likely to be created or kept. The fact of the matter is that scared (or scare-mongering) humans do in fact threat terrorism, by default, as "magically different", so we will have to diverge from the theoretical ideal of never offering a more specific instruction when more general will do. We've had to make many WP:Common sense adjustments of this sort, because being specific often gets the job done, even if it costs us an extra sentence in a WP:P&G page. That is a low price to pay for thousands of fewer sentences in pointless debates.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  19:06, 22 December 2017 (UTC)
• Yes, but with caveats. I know that many don't like it, but I still feel that there has to be a threshold, whether determined by death, injuries, or damage. Also, protecting an article from AfD due to vague, wishy-washy accusations of terror should not be a viable choice - concrete evidence must be supplied from WP:RS, not what we saw with the Melbourne attack where we don't know that it is not terror. I am wary of instruction creep, but a fixed set of rules along these lines would garner my support as a time saving measure. Stormy clouds (talk) 20:59, 22 December 2017 (UTC)
• Yes I think it would be beneficial to have a Notability guideline to help editors determine if an terror/attack is notable. The current system has both sides shooting themselves in the foot, the writer for not waiting a week to write the article (probably in haste to get a 4x award) and the nominators for not waiting a week to nominate it, borderline POINTy. L3X1 (distænt write) 02:31, 24 December 2017 (UTC)
• In practice, most of these articles on terrorism are articles created in the direct aftermath of the incident, and are usually rarely or never updated (because coverage drops off significantly and people move on to other things). There usually isn't much to update anyway: typically the suspect has a trial and sentencing, which generates some coverage, and there's basically nothing else. These articles are the equivalent of hashtags or news timelines: they generate a lot of traffic and people rush to create articles which go directly to the top of Google search results. A lot of the editor population is addicted to adding newspaper sources into Wikipedia, and I doubt that this will change (I myself got started seriously on Wikipedia in that way). NOTNEWS is basically dead. Kingsindian ♝ ♚ 06:55, 25 December 2017 (UTC)

Add a preferences option to disable the new watchlist interface

Tracked in Phabricator
Task T173542

While I find the live updates feature useful, overall this update that happened a while ago, I've found problematic. The filter changes menu still takes a good five seconds on my computer to load, making it literally impossible to click any links and the like on Wikipedia while it's loading. It's especially a nightmare on my tablet, where first, it takes longer, and second, I think the watchlist is fully loaded when it's not and when I go to tap a link, which we'll call Link 1, once the tap goes through when the interface finally loads, I end up going to Link 2. This update has been rather annoying. Amaury (talk | contribs) 20:25, 26 December 2017 (UTC)

@Amaury: Looks like the developers are already planning to do that, you can subscribe to phab:T173542 for continuing updates on the topic. --AntiCompositeNumber (talk) 12:04, 27 December 2017 (UTC)

Feedback requested at VPT regarding possible bot run

Please see WP:VPT#Bot removal of <center> in Template:US Census population. Thanks. --Izno (talk) 17:57, 28 December 2017 (UTC)

Main Page columns

This is an extension from the discussion here: Wikipedia talk:Did you know#A suggestion. On the Main Page, there are two columns: one for Today's Featured Article/Did you know? (left), and the other one is for In the news and On this day (right). As far as I can see, the width of the columns for left and right have always been 55% to 45%, respectively.

In Did you know? project (DYK), we have been discussing two issues: 1) How to reduce the current backlog of approved submissions and 2) How to address the Main Page balance concerns, as the left column are often shorter than the right column. Currently, DYK is running on 8 hooks set every 24 hours. In the past, the DYK project have often switched to 12 hours set when there is a growing backlog. There are two problems: 8 hooks set every 12 hours often lead to the approved submissions running out almost too quickly. Also, it does not address the balance of the columns, which almost always happen when there are no images for Today's Featured Article (TFA), for example. To address the balance concerns, there has been a proposal (linked above) to increase the number of hooks (to 10, for example) per set for DYK. I have been wondering about an alternative method, which is to change the width of the columns first, and then find the best number and time for the hook sets. The following are some potential comparisons. I was hoping to gather more opinions prior to starting an RfC:

• 52:48, 6 hooks
• 52:48, 8 hooks
• 50:50, 6 hooks
• 55:45, 10 hooks
• Proposal: Is it possible to change the columns of the Main Page from 55%/45% to 52%/48% or 50%/50% to address the recurring concerns of Main Page balance? Alex Shih (talk) 16:58, 22 December 2017 (UTC)
• I was hoping to leave this discussion to a later time, but since it's been initiated, I guess I will have to comment now. DYK sets should not have more than 8 hooks in my view for a variety of reasons, some of which were canvassed in the above linked discussion. Apparently recent practice has been to add an extra hook or two to an existing set when there is an abundance of whitespace at the bottom of the DYK set. I don't have any great objection to an occasional extra hook but IMO DYK should not feature nine or ten hooks as standard, it's just too many (by contrast, both ITN and OTD feature no more than five).

In the previous discussion, as one possible alternative for eliminating whitespace below the DYK set, I suggested dynamically adjusting the width of the left and right columns on the mainpage as required, assuming it is technically possible and easy to do. As it happens, I'm not sure a 50:50 split would work as it looks a little odd to my eye, but 52:48 might be acceptable.

I should add that there are other possible solutions to the whitespace issue. One of the changes that may have led to the excess space was the removal of some text at the bottom of the DYK set which used to provide a brief explanation of the DYK project. I no longer recall what the rationale was for the removal of this text, but I thought it was a bad idea at the time and I still think the project needs a few words of explanation on the mainpage. So that's another possible solution to consider. Gatoclass (talk) 17:32, 22 December 2017 (UTC)

Right now, I believe the problem is that ITN is too short; other times, other sections are. What we need is for admins to actively monitor the sizes of the Main Page sections. עוד מישהו Od Mishehu 07:43, 24 December 2017 (UTC)

Why not just have one column? That's what I do on my custom Main Page. --Khajidha (talk) 16:11, 24 December 2017 (UTC)

How about having the ratio 50% / 50%?Vorbee (talk) 09:12, 26 December 2017 (UTC)

Each DYK is on the Main Page for 24 hours now? I thought they used to be cycled through quite rapidly, every six or eight hours (but, if memory serves, only about six entries at a time).

If we've got a backlog, then we should change the sets faster. It would be easy enough to do this for a little while, until the backlog is down to a reasonable buffer size. Or to set it to 18 hours, if you prefer. There's no rule that says it has to divide into 24 hours evenly. WhatamIdoing (talk) 19:45, 28 December 2017 (UTC)

Twinkle's "unlink backlinks" feature and meatbot edits

The popular automated editing tool Twinkle has an "unlink backlinks" feature, which is intended to allow removing links to an article that has been deleted. This seems generally helpful (although it has previously been claimed to be counterproductive). However, a major issue is that it has occasionally been abused for large-scale unlinking of articles: as vandalism in 2008 (threads at the village pump and ANI), and in good-faith incidents in August 2011, September 2011, October 2016, and in apparently several "unlinking of the sandbox" fails, that last of which was in 2015. The latest incident occurred today, when an editor used it to remove over 460 links to English language (ANI thread, and drama at the editor's talk page).

There have been vague proposals to place limits on the kinds of pages that can be unlinked (in 2015) or to restrict its use to either sysops, or extended confirmed users. Instead, I think it will be more productive to put in place a restriction on the number of links that can be removed. How many are normally removed as part of the tool's intended use? If Twinkle allows single-click unlinking of more than a few dozen pages, then it's within WP:MEATBOT territory and it should be regulated. – Uanfala (talk) 20:45, 27 December 2017 (UTC)

• There was no drama. There was a small group of editors that lost their collective minds when they saw a big number and just started reacting rather than discussing. Niteshift36 (talk) 21:22, 27 December 2017 (UTC)

• That's the sort of quote that will likely return to haunt you at your next ANI appearance.

Twinkle's docs justify its use for "a page on a non-notable, vandalism, or other problematic topic" - just which of these is English language?

There is no justification for this sort of delinking. No one else supports it, you have given none. So how do we stop it? Restrict access to this feature by editor identity? Or by the ability of the feature itself, such as only removing redlinks? Andy Dingley (talk) 23:37, 27 December 2017 (UTC)

I think the best solution is to allow it only for users who are capable of deleting pages (admins) or for redlinked pages. The former allows removing the backlinks before deleting the page by the user who is about to delete the page, and that is desirable. עוד מישהו Od Mishehu 07:06, 28 December 2017 (UTC)

• No, it won't "haunt" anything. There was a group of editors that lost their collective minds. Some even conceeded that the edits themselves weren't actually controversial, just that the manner bothered them. And yes, if some people actually thought about it, rather than reacted to it, they'd agree that most of those edits weren't controversial. In the end, 462 edits got reverted because a small percentage of them were contested. And some were contested for no other reason than 'I don't like how you did it' or 'Well, someone might click it'. Niteshift36 (talk) 14:31, 28 December 2017 (UTC)

There's a reason we have a BOT policy, and that is to prevent these sort of unilateral mass changes. Galobtter (pingó mió) 8:02 pm, Today (UTC+5.5)

• And you've continually beat that drum, ignoring what I've actually said. Regardless, the "crisis" has been averted. Gotham is safe. Hundreds of pointless links have been restored. You can put the stick away. Niteshift36 (talk) 19:08, 28 December 2017 (UTC)

I'm not disagreeing, but why is it preferable to delete such links before a page? Andy Dingley (talk) 12:35, 28 December 2017 (UTC)

• Nobody is proposing to delete the English language page. I've clearly stated that article is important and serves a purpose. What is not needed is the link to it spammed into thousands of articles. Niteshift36 (talk) 14:31, 28 December 2017 (UTC)

He's replying to Od Mishehu, who emphasized "before". Killiondude (talk) 19:48, 28 December 2017 (UTC)

We probably should consider whether some of these heavily linked articles should be linked in quite so many places. Even after Niteshift's alleged "near-orphaning", there were still more than 70,000 links to that article in the mainspace. (He removed only 0.6% of them, and I think he was right to do so in at least some of those cases.) WhatamIdoing (talk) 21:03, 28 December 2017 (UTC)

• Thank you. "Near-orphaning" was hyperbole from the start. Niteshift36 (talk) 21:44, 28 December 2017 (UTC)

I remember checking about a dozen of these edits (including a few that were made manually before the Twinkle episode) and found about two or three that were OK to be removed. The majority however were not OK to be removed. – Uanfala (talk) 21:20, 28 December 2017 (UTC)

• And that's where we atart to disagree. Even if I buy off on it in language related articles, saying that because a sentence says 'Joe was fluent in Spanish, French, English and German' and the other languages are linked, so English needs linked is absurd. (And yes, some of the objections were examples like that) It's more about aesthetics than usefulness. Niteshift36 (talk) 21:44, 28 December 2017 (UTC)

Is there a reason to remove though? If it looks aesthetically better, but has no disadvantages, then why not keep the link? Galobtter (pingó mió) 11:01, 29 December 2017 (UTC)

• The fact that you even consider aesthetics to be a valid reason makes me think you'll never understand removing them. One reason overlinking is a pain is that when scrolling on a mobile device, it's easy to start bumping unnecessary links. That's less user friendly, not more. Wikilinks serve an important role, to make it easy to find articles that help them understand the topic better. But we don't (according to the MOS) link terms that most people understand. Nobody has even tried to put forth the notion that most readers of the English Wikipedia don't know what the English language is. The article is there and it serves a role. People know how to find it. Linking it in some infobox to tell us that Top Gun was filmed in English serves no real purpose and is exactly what overlinking is. Niteshift36 (talk) 14:49, 29 December 2017 (UTC)

Policy is clear on what constitutes mass-editing and what permissions are required before running what is effectively a bot. Mass-removing hundreds of links without prior consensus to do so is clearly and obviously a no-no. Regardless of the underlying merit (which has so far failed to persuade most editors who looked at it anyway). Realistically the only solution I can see is alter twinkle to not allow standard user accounts to make that many changes to links. Is it possible to restrict it to say, anything more than 50 requires a bot flag? Only in death does duty end (talk) 17:07, 29 December 2017 (UTC)

• It has been undone, so all the "damage" is gone. Most of those who have disagreed have either taken issue with the fact that they weren't consulted, gave aesthetics reasons or have not even looked at the majority of edits and just claimed it 'doesn't hurt to have them'. So no, they weren't "persuaded" because they didn't even discuss most of the actual edits. Let's be honest, this whole "near orphaning" claim is a gross exaggeration from the start. Niteshift36 (talk) 20:31, 29 December 2017 (UTC)

Near the end of User talk:J947/Archive 1 we have a similar newbie mistake (by me) and I felt pretty much the same as Niteshift36. That was all due to me misinterpreting WP:OVERLINK. J947 ^{(c · m)} 05:01, 30 December 2017 (UTC)

an AfD-style "find sources" template for Talk Pages

When submitting an article for deletion, the template inserts useful links to find sources on the deletion discussion page (example). Is there any way to add something similar to a talk page of any article? Such a tool is very useful to editors and it's a pity if it's not available until an article is considered for deletion. AadaamS (talk) 10:06, 30 December 2017 (UTC)

AadaamS

{{Find sources AFD|Water}} gives

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Galobtter (pingó mió) 10:09, 30 December 2017 (UTC)

@Galobtter: thanks! AadaamS (talk) 10:43, 30 December 2017 (UTC)

• The simplest and most attractive template for this is {{FSS}} = {{Friendly search suggestions}}. Andrew D. (talk) 20:59, 30 December 2017 (UTC)

Free encyclopeadia that anyone can edit

I have been editing Wikipedia on and off for more than twelve years now, and I can remember the days when if one read an article in Wikipedia, it would have a sign saying "Wikipedia - the free encyclopeadia that anyone can edit" heading the article. My proposal is that we go back to having this sign, as this would inform newcomers to Wikipedia that Wikipedia is a wiki website.Vorbee (talk) 19:52, 17 December 2017 (UTC)

You want to readd the "anyone can edit" part? L3X1 (distænt write) 14:11, 18 December 2017 (UTC)

• That was my proposal, but if anybody thinks that it is well-known enough these days that Wikipedia is a website that this is not necessary, I shall understand. Vorbee (talk) 09:38, 20 December 2017 (UTC)

If we're going to re-add that, can we change it to read "anyone can edit (but there's no guarantee that your edit will last more than a nanosecond before someone deletes it)"? Truth in advertising? Better for keeping the newcomers we attract with the motto? Regards, TransporterMan (TALK) 14:58, 18 December 2017 (UTC)

I see no need to have it atop every page. And surely there's no need for, "and so can everyone else" since it's obvious. Jim.henderson (talk) 15:10, 18 December 2017 (UTC)

I believe that the "anyone can edit" part was put in place before we had imposed permanent bans on several thousand people for a variety of issues. bd2412 T 22:01, 29 December 2017 (UTC)

I don't think this is necessary. Natureium (talk) 15:58, 18 December 2017 (UTC)

See also prior discussions at MediaWiki:tagline. — xaosflux ^Talk 16:35, 18 December 2017 (UTC)

Some food for thought. While we take for granted in the English-speaking parts of the world that everyone knows what Wikipedia is (and that you can edit it), research in other regions is showing that knowledge of Wikipedia in general is rather low. I wouldn't assume folks know, "Oh, I can fix this." even where English Wikipedia reaches. While not data, purely antidotal, as someone who contributes and works for the foundation, when I talk to non-Wikimedians about my contributions/work they are often surprised that anyone can edit. I can't tell you how many people get confused and think my job is editing Wikipedia. ಠ_ಠ Don't worry, I quickly correct them. :) CKoerner (WMF) (talk) 22:20, 21 December 2017 (UTC)

• Main page still says "the free encyclopedia that anyone can edit." I think we can keep it shorter on other pages. Doc James (talk · contribs · email) 05:38, 28 December 2017 (UTC)
• Thank you for drawing to my attention that it is still on the Main Page - I have had a look and seen it is there. Vorbee (talk) 16:31, 1 January 2018 (UTC)
• No point stating the obvious, If an IP heads to an article and sees "Edit" then it's kinda obvious what clicking that button will do, No need for any tagline and all that. –Davey2010 ^{Merry Xmas / Happy New Year} 21:54, 29 December 2017 (UTC)

AWB proposal

I would like to make a proposal that an improvement is made to AWB so that it either highlights places where there isn't a capital letter at the beginning of a sentence. I have observed that AWB is not fixing this problem and this addition will make it easier to fix places where capital letter are not at the beginning of sentences. Pkbwcgs (talk) 17:30, 1 January 2018 (UTC)

@Pkbwcgs: Editors interested in fixing this error could use the existing AWB software to do the job, as the software already has enough find+replace options. They would have to check every change by eye before saving each edit; this is the rule for all software-assisted fixing of typos (WP:SPELLBOT). It's not a simple job. There would be many cases where a . does not mark the end of a sentence; for example, where it marks an abbreviation or is a decimal point. There would be other cases where a sentence is required to start with a lowercase letter, for example when writing about eBay. -- John of Reading (talk) 20:20, 1 January 2018 (UTC)

Pkbwcgs, if anyone is to do this, I strongly recommend it not be you. In case the string of warnings hasn't sunk in, you're one more mistake away not just from having the AWB permission stripped but from being blocked altogether. A task this complicated would need to be done by a person with a very keen eye for punctuation and an in-depth knowledge both of English grammar as it relates to punctuation and formatting, and of Wikipedia's style guidelines and when it's appropriate to disregard them, and given the number of errors and mistakes you make this person is definitely not you. ‑ Iridescent 20:26, 1 January 2018 (UTC)

I am clearly not making anymore mistakes. I also have a very keen eye for grammar and mistakes and I skip many articles on AWB when if I think that there is even one thing that is wrong. Pkbwcgs (talk) 13:30, 2 January 2018 (UTC)

Withdrawn I don't think it a very good proposal to make. Pkbwcgs (talk) 16:52, 2 January 2018 (UTC)

Extremist symbols in templates

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

Snow close. Clearly not going to gain support--Moxy (talk) 03:02, 7 January 2018 (UTC)

---

On the occasion of this debate, I would like to propose banning the uncommented use of extremist symbols as – to give another example alongside the ones referred to within the linked thread – formerly in Template:Allgemeine-SS. I do not think it is reasonsable and beneficial for a neutral encyclopaedia to add such symbols as mere "decoration" for templates, as this seizes on and even might promote an ideological symbolism in the sense of a cult and worship of or fixation with specific typical symbols, that is, to my mind, quite characteristic of extremist movements – especially National Socialism and Communism. As such an uncommented – not to speak of naïve – use of ideologically charged symbols only for illustrative purposes appears rather prejudicial than informative, in fact, I would also claim that one cannot regard a pertinent revision of relevant templates as an [unjustified] infringement of WP:CENSOR (as has been purported in the course of the preceding controversy). Please inform me if this issue or a related one has already been discussed recently. Kind regards--Siebi (talk) 21:04, 6 January 2018 (UTC)

This is WP:NOTCENSORED/WP:NPOV. There is no promotion of ideology by displaying the symbol associated to that ideology on a template for articles related to that ideology, much like there is no promotion of Canada on {{Canada topics}}. Displaying the Canadian maple leaf doesn't say Canada is awesome, nor Canada is awful. Headbomb {t · c · p · b} 21:45, 6 January 2018 (UTC)

Also, there is nothing inherently wrong with communism. A comparison to nazism is rather inappropriate. Headbomb {t · c · p · b} 21:48, 6 January 2018 (UTC)

I would think that an ideology responsible for the deaths of around a hundred million people has some issues and FTR I think Communism occupies the exact same spot on the moral plane as Nazism. That aside, I agree as I noted in my comments at the initial thread that this runs afoul of NOTCENSORED. -Ad Orientem (talk) 21:55, 6 January 2018 (UTC)

Do not confuse communism with Stalinism or the doctrines of whichever communist despot you have a bone to pick with. A "common ownership of the means of production and the absence of social classes" is not on the same moral plane as Nazism. Headbomb {t · c · p · b} 01:21, 7 January 2018 (UTC)

Sorry but that is horse hockey. Marx repeatedly advocated violence and terror as the only way to deal with "class enemies." Lenin, Stalin, Mao and Pol Pot are true representatives of Communism which in terms of sheer body count is the most murderous ideology in the history of the world. The Nazis probably would have given the reds a run for that title but happily got crushed. “There is only one way in which the murderous death agonies of the old society and the bloody birth throes of the new society can be shortened, simplified and concentrated, and that way is revolutionary terror.” -Karl Marx 1848. And he was right. If you are going to strip people of their property you had better not be squeamish because that is going to require a level of violent coercion that is going to involve filling a lot of graves. -Ad Orientem (talk) 02:45, 7 January 2018 (UTC)

I am pretty sure nazi historians determined that Jews are responsible for deaths of around a hundred trillion people, but we don't really cite that number because we know it's bullshit created by an enemy party during a war. So why do we cite the bullshit historians from the american side of the Cold War? Just because they won it? Karl.i.biased (talk) 22:20, 6 January 2018 (UTC)

Should we pretend the holocaust wasn't real just because the allies won? Smh AdA&D 22:29, 6 January 2018 (UTC)

Oppose Basically, I agree with Headbomb. Ealdgyth - Talk 21:52, 6 January 2018 (UTC)

• Support -- unneeded and distracting. Such graphics do not meet the requirements of MOS:ICONDECORATION, as the images are purely decorative. They also often make the template taller. K.e.coffman (talk) 21:52, 6 January 2018 (UTC)
• Opposed per NOTCENSORED. See also my comments on the earlier linked discussion. -Ad Orientem (talk) 21:56, 6 January 2018 (UTC)

(after EC) First of all, thanks for commenting. To take up Headbomb's last post, I want to make clear that I am not putting Nazism and Communism on the same level, but I am rather just saying they are both – as to Communism and/or Socialism at least in certain variants – extreme political ideologies using highly charged symbols that we do not really need in uncommented templates.--Siebi (talk) 21:59, 6 January 2018 (UTC)

Please so not make the category error of equating Communism (or Marxism, or Marxist-Leninism, or Marxist-Lenninist-Stalinism, or Marist-Leninist-Maoism) with Socialism. They are not the same, and the conflation of these ideologies is a hallmark of the right wing. Almost every developed country has socialist aspects to it. Beyond My Ken (talk) 22:04, 6 January 2018 (UTC)

That is why I made the qualification "at least in certain variants"…--Siebi (talk) 22:11, 6 January 2018 (UTC)

• Comment - I don't have a problem with the use of symbols to help in identification of extremist groups, as long as the usage is reasonable. There is a point where the symbol stops being identification and starts being promotion. This threshhold is crossed when the symbol is displayed at a size that is too large. For this reason, I would support a size limitation, perhaps something near or below 100px , but certainly no larger than 125px. This would keep the symbol there for identification, without it becoming promotional. (Note that a fairly recent well-attended RfC on Template:Nazism sidebar reduced the size of the Nazi Party flag to 60px. [1]) Beyond My Ken (talk) 22:00, 6 January 2018 (UTC)

That sounds reasonable. -Ad Orientem (talk) 22:02, 6 January 2018 (UTC)

That would be reasonable. Ealdgyth - Talk 22:06, 6 January 2018 (UTC)

Strong Oppose (to limiting the size of this images) So now images in an encyclopedia are claimed to promoted ideas they represent? Very cool. I am being offended by the image of the Kingdom of Jerusalem's flag, because it features a cross. Please remove Template:Crusader states, because I am being #triggered Karl.i.biased (talk) 22:17, 6 January 2018 (UTC)

Striking, please only !vote once. SkyWarrior 22:19, 6 January 2018 (UTC)

I meant to say I am strongly opposed to limited the size of the images too, so this is a vote on a different topic (i clarified my initial statement above to make it obvious). Karl.i.biased (talk) 22:23, 6 January 2018 (UTC)

I hope you do realize that what is being proposed by BMK is simply reducing the size of the images slightly, not removing them altogether? SkyWarrior 22:31, 6 January 2018 (UTC)

No, Karl.i.biased, this is not at all about banning images from the project, but only from templates where these images are not explained! That is a huge difference, I'd say.--Siebi (talk) 22:21, 6 January 2018 (UTC)

• Oppose. Judicious use of these symbols is not promotion, just identification. SarahSV ^(talk) 22:05, 6 January 2018 (UTC)
• Oppose: thin end of the wedge. This week we ban swastikas; next week it's the hammer and sickle; the week afterwards the crucifix, perhaps? The proposal completely fails to address the question of who defines what an "extremist symbol" is. --RexxS (talk) 22:06, 6 January 2018 (UTC)

@SlimVirgin: What exactly would you call "judicious" about such use in templates then? What is supposed to be the additional gain?--Siebi (talk) 22:16, 6 January 2018 (UTC)

And even if there were a certain gain (whatever that may be), in what respect would it justify being confronted with Nazi symbols (swastikas, SS runes) etc. of all things in a template?--Siebi (talk) 22:14, 6 January 2018 (UTC)

• The gain is that you don't get to decide what symbols we're allowed to see, viz WP:NOTCENSORED. I don't like seeing Nazi symbols, but having to put up with it is the price I'm willing to pay to make sure somebody can't censor lots of other symbols that I'm comfortable with and serve a useful purpose. --RexxS (talk) 22:30, 6 January 2018 (UTC)

• Comment -- such decorative elements are often completely unnecessary. Compare for example: No icon with Icon. What does the icon add? K.e.coffman (talk) 22:11, 6 January 2018 (UTC)

The same benefit iconography has always provided: rapid identification. Having a easily recognizable icon at the top of a navigational element allows the reader to quickly identify the subject the template relates to. AdA&D 22:20, 6 January 2018 (UTC)

The example I provided includes the icon to the side, mid-way down the template. It's not "at the top of a navigational element". What does the icon add in this case? K.e.coffman (talk) 22:39, 6 January 2018 (UTC)

• Strong Oppose this is an encyclopedia, not your safe space. Karl.i.biased (talk) 22:12, 6 January 2018 (UTC)
• Oppose because of WP:NOTCENSORED and also because it would generate arguments and edit warring over which ideologies are extreme as already seen already in this discussion. Weburbia (talk)

Great point, actually. User Ad Orientem had stated above that Communist states killed 100 million (sic!!!) people, while I personally think the US alone is responsible for much more innocent deaths than the USSR and China combined. So are we going to remove American symbols too? Karl.i.biased (talk) 22:28, 6 January 2018 (UTC)

Well actually the numbers generally cited in the West during the Cold War are being labeled hopelessly conservative by historians from the former Communist states, especially the former USSR. As for American war crimes, I have long since abandoned any silly mom and apple pie illusions about the good ol US of A. But I have never seen any numbers even remotely close to what you are claiming. -Ad Orientem (talk) 22:33, 6 January 2018 (UTC)

• Not to pile on, but I fail to see how the use of a symbol to identify a historical group can be seen as promotion. Headbomb's example of the maple leaf is well-taken. AdA&D 22:20, 6 January 2018 (UTC)
• Oppose. Wikipedia is not censored and I don't really see how having the images in the infoboxes is "promotion". Besides, how would we define what is an "extreme ideology" anyways without arguing and edit wars? SkyWarrior 22:35, 6 January 2018 (UTC)
• Oppose If there are symbols which are not serving any legitimate purpose on some templates then by all means remove those (e.g. the removal from Template:Allgemeine-SS which makes good sense) but I don't think we want to apply a rule to all templates for two reasons: First, there are some where the image is clearly serving a legitimate identifying purpose (e.g. Template:Nazism sidebar and Template:Communism sidebar) and, secondly, because we don't want to get into interminable arguments about what is and is not an "extremist symbol". There is no clear method of for sorting the edge cases and there are a lot of them. Even worse, the symbols can not be considered in isolation as context matters. There is scope for both legitimate confusion and also for deliberate trolling here. Even a swastika is not always an extremist symbol as it has a history pre-dating Nazism. The US Alt-Right has fun turning innocent things into short term extremist symbols with a rapidity which I doubt we could keep up with even if we could be bothered to. Furthermore, I suspect that they do it just to wind people like us up so all the more reason not to rise to it. In short, this would be a needless rod for our own backs as the existing rules are sufficient if applied properly. --DanielRigal (talk) 23:08, 6 January 2018 (UTC)
• Oppose, I fail to see the point of this debate. In situations were there is a commonly identified symbol for a certain feature, graphic identification is certainly helpful. And good luck trying to agree on a common definition of 'extremist'. --Soman (talk) 23:32, 6 January 2018 (UTC)
• Oppose, while I certainly wouldn't be for the use of such images just as decoration, we are not promoting them when using them as appropriate for identification. Use in a template about the very thing the symbol represents is an appropriate and reasonable use. It does not mean we endorse the symbol or what it stands for. I also think we start down a very bad path if we start deciding what constitutes "extremist". Seraphimblade ^{Talk to me} 00:24, 7 January 2018 (UTC)
• Oppose I fully expect to see Nazi symbology used in nazi-related articles, templates and infoboxes. Even as "decoration" (which isn't really about aesthetics so much as being about making it possible to identify the subject at a glance, without reading the small, low-contrast text used in templates). ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 00:49, 7 January 2018 (UTC)
• Oppose - who is going to determine what is "extremist" and what isn't? This is unworkable. MarnetteD|Talk 01:25, 7 January 2018 (UTC)
  • well, apparently the OP has begun removing them and now there are different editors removing and restoring them all over the place...Ealdgyth - Talk 01:48, 7 January 2018 (UTC)
• Oppose as per NOTCENSORED - If you're truly that offended by Nazi history then I would suggest you throw your modem out of the window and stick to sewing undergarments. –Davey2010^Talk 02:17, 7 January 2018 (UTC)

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

Remove "you can help" from maintenance template

I believe that the invitation "You can help" in {{Data missing}} is a violation of MOS:YOU, and should be removed. Any thoughts? Optimist on the run (talk) 00:16, 29 December 2017 (UTC)

• MOS:YOU is about article prose. Maintenance templates aren't part of the article text. They're ruptures in this text, the points where the fourth wall momentarily breaks down and we can directly address the reader with something to the effect of "Pssst. The facade is not all there is to it. Come behind the scenes!". That's part of the wiki way and it's more important than all the style manuals in the world. – Uanfala (talk) 00:23, 29 December 2017 (UTC)

  I disagree. We have plenty of places to invite readers to become editors of the encyclopedia that anyone can edit without breaking up the flow of text. This is why we don't have "you can help" in {{cn}} or a dozen other maintenance tags, Optimist on the run (talk) 07:25, 29 December 2017 (UTC)

Yeah, there's no reason why this one needs "you can help" when other maintenance tags don't. Galobtter (pingó mió) 11:04, 29 December 2017 (UTC)

I agree - a header template can say "you can help" or something similar without being too disruptive to the text; an inline template shouldn't say this. עוד מישהו Od Mishehu 16:00, 1 January 2018 (UTC)

I also think the invitation should be removed, as it makes the inline template too big. I don't think we have calls to action in the other inline templates, too. Enterprisey (talk!) 20:43, 7 January 2018 (UTC)

I'd agree with Enterprisey. Strip it off. — Insertcleverphrasehere ^{(or here)} 20:47, 7 January 2018 (UTC)

I've removed it. Optimist on the run (talk) 21:03, 7 January 2018 (UTC)

Proposal: rename "References" section to "Citations" section

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

---

For wikipedia it would be better to have a Citations section than References section because Citations are used in academic works and because it makes more sense in terms of "citation needed" tags. What do you think? Brian Everlasting (talk) 21:02, 1 January 2018 (UTC)

There's no rule against calling the section "Citations" (or anything else appropriate) if there's no possibility of confusion. In general, we avoid using "Citations" as a section name because of the potential for confusion; "Citations" could refer to a list of awards received by the article subject or a list of legal convictions, whereas "Notes" or "References" is unambiguous. Likewise, we discourage "Bibliography" as a section name because of the potential for confusion with a list of works either by or about the subject, rather than a list of the works used to source the article. (You can read chapter-and-verse of our guidelines for naming this section at MOS:FNNR.) I'd vehemently oppose any attempt to standardise the name of this section to "References", "Citations" or anything else, and I suspect virtually every other person to comment would as well, but if you really want to try to get consensus for it Wikipedia talk:Manual of Style/Layout would be the place to hold the discussion. ‑ Iridescent 21:13, 1 January 2018 (UTC)

Oppose per Iridescent · · · Peter (Southwood) ^(talk): 05:01, 2 January 2018 (UTC)

• Not going to happen, per Iridescent. — Insertcleverphrasehere ^{(or here)} 05:06, 2 January 2018 (UTC)
• Nope as per Iridescent - Having "References" saves a lot of confusement, Having it as "Citations" would cause a lot of confusmeent. –Davey2010^Talk 16:38, 5 January 2018 (UTC)
• See Wikipedia:Perennial_proposals#Changes_to_standard_appendices Galobtter (pingó mió) 11:55, 6 January 2018 (UTC)
• In addition to what others have said above: "Citations" in this context usually means in-line citations, while "References" may include both in-line citations and general references. Nsk92 (talk) 10:49, 7 January 2018 (UTC)
• Probably a bad idea. I recently found an article with both a "sources" and a "references" section. Talk about confusion! Doug Weller talk 17:38, 7 January 2018 (UTC)

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

Three Strikes Rule for AfC submissions and reviews

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

---

There have been several recent discussions about problems at Articles for Creation. Here, here, and here.

To address some of these concerns I propose the following:

On the third decline of any AfC submission, a bot shall be programmed to list the draft for discussion at Miscellany for Deletion. At the end of the discussion, if the draft is 'keep' or 'no consensus' it should be moved immediately to main-space (same as at AfD) and put into the New Page Patrol queue. If the decision is 'delete' it should be deleted and subject to G4 CSD as per usual if recreated. Other potential outcomes such as merging/redirect/etc are possible, however, the draft should not be sent back to the draft space following the discussion, regardless of outcome.

If a topic is deemed notable, but the article would fail on some other criteria (i.e. NPOV, etc), it should be converted to a short stub and sent to main space for expansion and improvement, not deleted.-Additional guidance added 7th Jan

This proposal is meant to address three primary issues:

• Concerns that some AfC reviewers are being too strict (or at least more strict than NPP or AfD would be with a similar submission). --The MfD discussion would reveal notable topics through discussion.
• Repeated submissions of clearly non-notable subjects (or borderline-looking, but non-notable subjects) that waste valuable reviewer time and contribute to a growing backlog. --The MfD discussion would reveal non-notable subjects and delete them so that they would then be subject to G4.
• Lack of collaboration (some have raised concerns that drafts are only seen by a handful of reviewers, who decline over and over, sometimes on spurious reasoning, and that this is contrary to Wikipedia's goals of collaborative editing). --The eventual MfD discussion after three AfC reviews would create a place where additional eyes would be put on the article.

This is especially important to help resolve borderline topics that tend to languish at AfC, they are not listed for deletion because it is not obvious that they should be deleted (they are borderline after all), and instead they are just resubmitted over and over until the author loses patience and either moves it to main space where NPP deals with it, or abandons it and it eventually gets put up for G13 CSD. As far as I have seen, there is a significant proportion of abandoned drafts that are suitable for main-space, so this is a relatively common issue.

NOTE: This proposal is not intended as a way to "get rid of" drafts, rather it is as much a way of ensuring quality reviewing from AfC reviewers as it is about getting rid of improper submissions that clog AfC. Even submitters gain from this process, as they will be at least given a firm answer to whether their submission is notable or not and will escape AfC purgatory (for borderline drafts). Drafts that are unfinished, but clearly notable (as determined by editors doing a routine search for sources at the MfD discussion), should be moved to main-space anyway, where they can be improved by more sets of hands and eyes. The only group affected with a slightly larger workload will be contributors to MfD.

My hope is that this is a solution that can help pretty much everyone involved, and streamline several processes at the same time. I hope that you guys also agree.

NOTE#2: Others have suggested that this proposal could overrun MfD, but estimates indicate only 2-3 on average would be expected per day. Well within the current capabilities of MfD. See my comment to GMG below.

NOTE#3: The {{AFC_submission/declined}} template should be updated to indicate that a third decline will result in a discussion at MfD.

— Insertcleverphrasehere ^{(or here)} 09:25, 21 December 2017 (UTC)

Discussion - three strikes proposal

Support, as proposer. — Insertcleverphrasehere ^{(or here)} 09:25, 21 December 2017 (UTC)

• Support Will make the AfC process more manageable and streamline work flow. Suitable submissions into main space unsuitable submissions deleted. -- Dlohcierekim (talk) 15:12, 21 December 2017 (UTC)
• Suppport-ish - I do like the idea of doing something about drafts that languish. However, if the draft passes MfD I see no reason to submit it to another review at NPP, or alternatively, why not submit to NPP directly and bypass MfD? I don't see the point of one review leading to an automatic second review, that's all. Also, why not do this for all G13-eligible drafts? Ivanvector (^Talk/_Edits) 16:16, 21 December 2017 (UTC)

There is other stuff that happens at NPP that is valuable other than article triage:tagging for cleanup, adding WikiProjects, stuff like that. There is no reason why the closer of the MfD discussion can't automatically tick it off if they are an admin though. Basically: our backlog at NPP isn't so bad that we can't support an initiative like this, so I thought, why not? Submitting directly to NPP will get shot down immediately, and I wouldn't support it; most of these are borderline and need discussion to sort them out one way or the other, it would subvert ACTRIAL, and we also shouldn't reward people repeatedly submitting trash drafts with automatic main-space publication. — Insertcleverphrasehere ^{(or here)} 17:53, 21 December 2017 (UTC)

I guess admin involvement is part of the problem here. Usually (but not always) the closer of an MfD will be an administrator, and administrators have the autopatrolled userright, so if moved as part of an admin MfD close the draft will be automatically patrolled and will not appear in the NPP queue. If this is to work, I think the onus is going to be on the MfD participants to reject unsuitable content (which is already done) and also tag drafts which are inclusion-worthy but need work, as NPP does now. I'll comment on the other suggestion below in a bit, I have to run for IRL things. Ivanvector (^Talk/_Edits) 19:31, 21 December 2017 (UTC)

• Comment MfD is nice, except a lot of us NPPers (non-biting page patrollers) don't frequent it, probably because it doesn't show up in our RFA-I'm-so-pretty logs. Why not send it to AFD? I mean, I know its not an article in the sense of residing int he mainspace, but its an article wannabe and I think it should be treated as such. If drafts showed up at AFD you could get a lot more eyes on it. Granted, no small portion of those eyes will be long toothed deltionists who believe "If it's at AFD it should be deleted, ja, sandwhich make me strong!" which can spam the !vote count towards delete, but more eyes is better than 3 eyes. L3X1 (distænt write) 17:23, 21 December 2017 (UTC)

I did consider this; although MfD is the place for drafts, we are de-facto treating the draft like an article for the purposes of discussion. I'm not adverse to the idea, however, I was worried that people would shoot it down for being too radical. I'll ask it as an additional question below. — Insertcleverphrasehere ^{(or here)} 17:53, 21 December 2017 (UTC)

• Support ANYTHING that means drafts by new editors are actually discussed by the community at large rather than the 1 on 1 'gauntlet' at AFC is good. AFC reviewers manage to eliminate the truly irredeemable, but unfortunately they also overreach far too often and condemn good potential drafts to a purgatory eventually leading to g13 deletion when the exasperated editor has given up. This policy would not only allow community oversight, but also allow a much wider range of people to actively help drafts reach a higher quality! I would also say that this policy, if adopted needs to have a clear warning for draft users, and perhaps the option at MFD or AFD for 'userfy' the article in cases where the writer wants to continue to work on it.Egaoblai (talk) 20:32, 21 December 2017 (UTC)
• Support. This is a neat solution to a number of problems, and essentially just formalises the current ad hoc process of taking drafts to MfD when we get fed up of them at AfC. I especially like the idea of getting a definitive community consensus on a draft relatively soon rather than encouraging new editors to go through an endless cycle of accept-and-reject. However, I do agree that MfD may not be the best venue. Perhaps AfD, or given the potential volume, we could even create a new 'Drafts for Discussion' process. That can be decided later, though. – Joe (talk) 20:33, 21 December 2017 (UTC)
• Uhh.... I think this proposal needs to come with some numbers. Actually a lot of numbers. The last stats I've seen were from October, and we had about 250 article reviews a day. I have no idea how current that number is, and no idea how many of those we would be pushing into XfD. But probably on the order of a regular 50 would be enough to overwhelm AfD (who all day today has had a grand total of 70 nominations), and MfD (heaven forbid) seldom gets more than a dozen a day. Nevermind the fact that this completely rewrites policy for at least AfD, and allows editors to nominate articles with basically no expectation that they do BEFORE. I have a hard time believing that there isn't a giant unintended consequence sitting out there somewhere. GMG^talk 20:41, 21 December 2017 (UTC)

Well, the before is that three reviewers thought there was nothing to the draft. I don't think the number that get rejected three times is so ridiculously high. Galobtter (pingó mió) 04:22, 22 December 2017 (UTC)

Ok. You asked for numbers: I looked at 50 random AfC drafts, of those; 29 had not been reviewed before, 15 had been declined once, 3 had been declined twice, and 3 had been declined 3 times. The three that had been declined three times were: Draft:Tony Parella, Draft:Win the Future, and Draft:WIN-911 Software. So about 6% of the AfC submissions currently in the backlog. If the backlog is ~2700 there should be about 160ish drafts that would qualify right now. Note that I would not recommend sending them all at once (what a disaster that would be). The bot could be programmed to send over a maximum of 5-10 per day (or some other number) until it is caught up. Once caught up I'm suspecting a rate of 2-3 per day is what we would be expecting (the backlog wait is about 2 months (!) at the moment, and some basic math: 160/60=2.7 . Rough estimates, but that is what we are looking at ballpark-wise. Not actually huge numbers. — Insertcleverphrasehere ^{(or here)} 08:58, 22 December 2017 (UTC)

• Comment - I'm skeptical about this. I would like to see about how many (per month or week) drafts reach these three strikes only to be accepted later, compared to how many reach the three strikes threshold. RileyBugz^会話_投稿記録 21:18, 21 December 2017 (UTC)
• I am worried that this will overwhelm MFD. Enough already would go down with a softdelete, so the persistent submitters would just ask for an undelete and then try again any way. In some cases the problem is with the decliners who are claiming problems that are not there or are insignificant. Yet we do not need an automatic report of the last decliner to ANI. Instead we shoul have a human decision. The page could goto the back of a priority queue, maybe we should have categories for heavily declined pages, and slightly more persistent than juat counting the current templates. Graeme Bartlett (talk) 21:25, 21 December 2017 (UTC)
• Question: Would this include user sandbox drafts once they've been tagged by the author for review, or only AfC drafts? I'd be opposed to this if it includes user sandbox drafts. Regards, TransporterMan (TALK) 21:30, 21 December 2017 (UTC)

I would think Draft-space only per our usual YourUserspaceIsYourCastle policies. L3X1 (distænt write) 23:52, 21 December 2017 (UTC)

@TransporterMan: What exactly do you mean by "tagged for review"? As far as I'm aware the only way of doing that is to submit it to AfC, and then it's moved to draftspace anyway, so the point is moot. – Joe (talk) 00:15, 22 December 2017 (UTC)

It's my understanding, perhaps incorrect, that placing {{subst:submit}} on a user sandbox draft queues it for review without moving it to draft namespace. Am I wrong? Regards, TransporterMan (TALK) 04:16, 22 December 2017 (UTC)

I'm pretty sure that's the case - they have to be manually moved to draft space. Galobtter (pingó mió) 04:22, 22 December 2017 (UTC)

@TransporterMan: It's not automatic, but the current practice is to move anything with that template on it to draftspace, which somebody is usually quick to do. But moved or not moved, putting {{subst:submit}} on it submits it to AfC and therefore makes it an "AfC draft", as you put it. – Joe (talk) 09:28, 22 December 2017 (UTC)

Then I oppose this proposal unless the practice of moving user sandbox drafts to draftspace after such tagging is forbidden. It's objectionable to subject userspace drafts to 3-strikes peril merely because someone asks for review. Indeed, I'm not sure how I feel about this entire proposal, but I'm sure I'm opposed so long as that's the case. - TransporterMan (TALK) 14:17, 22 December 2017 (UTC)

It's not merely because they asked for a review. It's because they asked for a review 3 times. And it's not peril - it's quite possible that the review will figure out that it is indeed notable and put it to mainspace. The user can always move it to mainspace themselves too. Galobtter (pingó mió) 14:24, 22 December 2017 (UTC)

If the draft is in userspace, I oppose this proposal regardless of how many times they ask for review if the result of that request is that their draft stands any chance of being nominated for deletion because it gets moved to draftspace. Drafts in userspace should not be subject to being automatically nominated for deletion, however that may come to pass. — TransporterMan (TALK) 20:45, 25 December 2017 (UTC)

@TransporterMan. Because of the way AfC works, adding the submit template to a userspace draft is also de facto requesting that the userspace draft be moved to Draft space. However, this isn't always clear to new users, and perhaps I could add a caveat above that the draft can be userified if requested. G4 has an exemption for userfied content, though I suppose that if the user decided to submit the resulting userspace draft for AfC again (4th time) without substantial changes or move it to main space without substantial changes, it would then qualify for G4.

Would you still oppose if I changed the last line to: ...the draft should not be sent back to the draft space following the discussion, regardless of outcome, but may be userified upon request (subject to G4 if moved to main/submitted to AfC without substantial changes).? — Insertcleverphrasehere ^{(or here)} 21:36, 25 December 2017 (UTC)

Yes, I think I would still object. You say, "adding the submit template to a userspace draft is also de facto requesting that the userspace draft be moved to Draft space" but I cannot find anything in policy or guidelines which allows that (and, indeed, STALE would seem to, if not forbid it, at least not to specifically allow it) and I find nothing on the AFC page or on the {{submit}} template which would inform an editor that that's going to happen merely because they submit-tag their draft. People should be allowed to work on articles in their own userspace for as long as they care to do so, subject to what it says in STALE, and merely asking for a review should not result in it being moved from there and (worse) then being put at risk of being nominated for deletion. If AFC doesn't want to review a userspace draft more than a certain number of times or more than a certain number of times per time period, that's fine (if a bit petty and BITE-y), but not telling them that asking for review may get their draft deleted is just plain wrong. Regards, TransporterMan (TALK) 23:08, 25 December 2017 (UTC)

@TransporterMan. Well, if you add the {{submit}} template to a non-draft space submission it says "Warning: This page should probably be located at Draft:XXXX" or if put on a sandbox draft it will say "Warning: This page should probably be moved to the Draft namespace." and gives a handy button for easily moving it, so it kind of tells them it will be moved to draft. I agree with you that this process should be transparent to the submitter, and the place to add it is next to the 'Resubmit' button on {{AFC_submission/declined}}. This should be updated with something along the lines of "Please note that if the issues are not fixed, the draft will be rejected again. A draft that is rejected three or more times in a row will be listed for discussion at MfD to determine if the topic is notable and/or appropriate for Wikipedia, and may be deleted or moved to main space as appropriate." (added text underlined). Would you still Oppose if that template is updated so as to make it perfectly clear that submitting a third time could result in deletion (I will add it to the above RfC)? See NOTE#3 above. — Insertcleverphrasehere ^{(or here)} 18:35, 26 December 2017 (UTC)

While that would improve one issue, it would not cure my primary concern and I would (and do) continue to oppose. As I said above, people should be allowed to work on drafts in their own userspace for as long as they care to do so, subject to what it says in STALE, and merely asking for a review should not result in a draft being moved from there and/or (worse) being put at risk of being nominated for deletion. Regards, TransporterMan (TALK) 17:56, 27 December 2017 (UTC)

• Support. It's a sound suggestion to address a definite problem. My experience of AFC is recent and limited, but I have seen a significant issue with articles that don't meet the criteria for acceptance being rejected, and then being quickly re-nominated. The suggestion, made here and at Village Pump, that AFC represents a "1 on 1 'gauntlet'" between good-faith newbies and cynical AFC'ers, is wide of the mark. I've been seriously surprised by the volume of articles that are either entirely authored by the article's subject, or are intended to promote a commercial enterprise, or both. An effective gateway process is certainly required and this proposal would work towards that. KJP1 (talk) 22:30, 21 December 2017 (UTC)
• Oppose. Based on my own experience working #wikipedia-en-help on IRC, a massive chunk of the users writing drafts haven't even bothered to read about our notability criteria, our neutrality requirement, or even what sources we deem acceptable, and when told about these immediately turn around and try to use "But <foo> exists!" as an argument. These users only see Wikipedia for its Alexa and search engine ranking. There needs to be drastically more education on the matters I linked above before we can even consider taking this step. —Jeremy v^_^v ^Bori! 23:13, 21 December 2017 (UTC)

And this proposal will actually solve that problem. Users who make poor quality articles will not only be told by one reviewer that it is poor or not notable, but by a group of reviewers at XFD. Also, the existence of a lot of poor drafters does not exclude the existence of good drafters, even if they might be a minority. Let's not through the baby out with the bathwater when we talk about article drafters. It would be mean-spirited to go into this thinking that all new drafters are idiots or spammers. There are plenty who write articles in good faith and are let down by the review system. this policy helps both the poor and the good drafters by giving them a much needed jury rather than one reviewer.Egaoblai (talk) 23:38, 21 December 2017 (UTC)

This would not help that step; it's just torque them off. Again, as I said above, these people have zero idea what WP:N, WP:IRS, and WP:NPOV are and have no inclination to find the information for themselves; sending it to a deletion discussion would spike their blood pressure for no benefit. These users need to be explicitly pointed to those pages. —Jeremy v^_^v ^Bori! 21:33, 22 December 2017 (UTC)

And how many of those users should we be helping at all to begin with? The biggest problem with both AfC and -help today is that the overwhelming majority of resources goes to help people who are not good faith editors but are motivated to get their article into Wikipedia because of external pressures that good faith editors don't have. This drains resources that could be spent helping the people that AfC declines because the reviewers don't know how high quality non-web based sourcing works or the like. I don't have an opinion on this proposal, but I don't really consider making spammers not want to edit Wikipedia a bad thing. TonyBallioni (talk) 21:43, 22 December 2017 (UTC)

Reviewers would (and already do/should) point out the existence of WP:N etc on a first draft. We're talking about a third draft here, so presumably they would have more than enough time to become acquainted with those places. the 'explicit pointing' would have already happened.

In my experience, they gloss over any links in the decline reason and ignore comments left by reviewers. —Jeremy v^_^v ^Bori! 01:28, 23 December 2017 (UTC)

• Support, but with caveats: I'm open to the idea, considering many drafts simply don't have a snowball's chance of ever being accepted; what I do is I simply put an IAR G6 tag on them and state that the draft would most likely be speedied if it were an article. However, from experience, since Wikipedia has no deadline, I've observed that some drafts, even those that were rejected multiple times, eventually could end up meeting Wikipedia's guidelines. Thus, while I can see the value in the proposal, I'm not sure if three strikes specifically a good number; how about five strikes instead? Or perhaps, we could have the three strikes thing, but have some leniency for promising articles, or at the very least allow requests for the deleted drafts to be recreated either at WP:REFUND or WP:DRV. In addition, if three/five/whatever number of strikes is implemented, perhaps on the last decline before when the draft would automatically be MfD'd (either the second or the fourth), an automated message should be left on the user's talkpage stating that the draft will be nominated for deletion the next time the draft is declined, while at the same time giving suggestions on how to improve the draft. Narutolovehinata5 ^tccsdnew 00:04, 22 December 2017 (UTC)
• Support, but I think we'll need to make a special section (at MfD) for the drafts that get sent there, so people interested in article creation can browse that and the people who normally frequent MfD can skip it if they want to. Enterprisey (talk!) 05:06, 22 December 2017 (UTC)

  Either that or just a separate DfD. Galobtter (pingó mió) 05:12, 22 December 2017 (UTC)

• Moral Support only moral support as I'm unsure whether MfD, AfD, or a new DfD would be the right venue, and can't support any final proposal yet. Perhaps we could get agreement for a limited test of both processes to see which works better? power~enwiki (π, ν) 06:22, 22 December 2017 (UTC)

@power~enwiki I am pretty sure that AfD is out as a possibility, and I am personally leaning toward a separate section at MfD for "Three Strikes AfC Drafts" to include auto-submitted ones. After all, slightly special instructions will apply to these articles. I don't think that we need an entirely new DfD for these given the numbers that we are expecting (in my (rough) estimation above I recon it is in the single digits per day). A new DfD would not have an existing base of users there to help discuss, and could end up with different standards being employed than at MfD/AfD, which is what we are trying to avoid in the first place. — Insertcleverphrasehere ^{(or here)} 06:33, 22 December 2017 (UTC)

• Support (mostly): This is a well thought out proposal, Insertcleverphrasehere. My only concern is the lack of participation at MfD and the potential of overloading a board that is simply not accustomed to deal with this level of activity. --Majora (talk) 21:10, 22 December 2017 (UTC)
• Oppose. As far as I can tell, this is a complicated scheme system to make sure that IPs have as much right (if with some extra hassle) to write bad articles that just barely won't get deleted as autoconfirmed users do. Why is that useful? If they want to write bad articles on notable topics, they can go ahead and register an account. --Trovatore (talk) 21:27, 22 December 2017 (UTC)

  I'm pretty certain most draft-writers *are* registered users, albeit not autoconfirmed. —Jeremy v^_^v ^Bori! 21:37, 22 December 2017 (UTC)

  Really? Then won't they be autoconfirmed by the time they've put an article through three AfC attempts? It's a pretty low bar. --Trovatore (talk) 22:30, 22 December 2017 (UTC)

  There are two elements to autoconfirmation: Time and edits. If a user creates and submits the draft in one edit and makes adjustments and resubmissions in one edit, or they do so at a rapid-fire pace, it's plausible that they won't be autoconfirmed at that time. —Jeremy v^_^v ^Bori! 23:06, 22 December 2017 (UTC)

  Sounds like an unusual case, and in any case easily fixed by making a few edits and waiting a few days. Why would we want to create all this complicated structure just to make it slightly less likely that a new editor will have difficulty creating a bad article? --Trovatore (talk) 23:44, 22 December 2017 (UTC)

if you are concerned about 'bad articles' then this system would actually help with that as it would mean that drafts would have the wider attention of the community, who might be more motivated to work on them together, rather than expecting the new editor to do all the work themselves (they'll still do most, but they'll have a hand from others when it comes to the XFD discussion. Egaoblai (talk) 00:47, 23 December 2017 (UTC)

I'm just wondering why we're bending over backwards to solve a problem related to non-autoconfirmed creations, when becoming autoconfirmed is so easy. --Trovatore (talk) 02:02, 23 December 2017 (UTC)

@Trovatore, this isn't aimed at any particular type of editor, the vast majority of drafts that I have reviewed were submitted by users, not IPs. I personally used AfC to submit my first article, even though I had many months of tenure and hundreds of edits. AfC is also used by autoconfirmed editors that simply want to contribute and thought that it is a place where they could get help. — Insertcleverphrasehere ^{(or here)} 05:25, 23 December 2017 (UTC)

Ah. Well, it's possible I haven't fully understood the context, then. I've never hung around AfC; I thought it was mainly there so IPs could create articles. I'll withdraw my objections and let the others figure it out. --Trovatore (talk) 07:21, 23 December 2017 (UTC)

AfC is primarily for new users who may not understand Wikipedia syntax and for COI editors to submit articles without fear of them being deleted out-of-hand in mainspace. This is part of why they require review: the reviewer is supposed to explain what the issues with the draft are, in general or specifically, when declining, and it's generally one of three things: Notability not shown, non-neutral writing, or the draft covers a topic already handled by an existing article. The overwhelming majority of drafts I have seen have been written by registered editors, not IPs. —Jeremy v^_^v ^Bori! 22:54, 23 December 2017 (UTC)

Oppose thought not for the reason you think. I agree that repeated resubmissions without improvement should be sent to MFD, but part of entertaining the resubmissions is establishing a pre-existing consensus by multiple AFC reviewers (see Wikipedia:Miscellany for deletion/Draft:The Ding Dongs as an example). One reviewer may be a stickler on RS, one may be a stickler on N, and a third may be a stickler on underlinking/overlinking pages, and a final one might have a conniption fit about REFSPAM. Automatically creating the MFD discussion by bot will only lead to more false positive MFDs and wasting time on things that have the potential to improve. Giving AFC volunteer reviewers the ability to exercise discretion is a much better option. Hasteur (talk) 02:59, 23 December 2017 (UTC)

Furthermore, I wonder if the better answer would be to stop patrolling the mouth end of the AFC queue so actively (go over the front for quickfail objections (Copyright, attacks, patent nonsense)), and work the tail end more actively. Giving these users feedback so rapidly only reinforces the cycle of "If I make one byte change, I might be able to get it in". If we instil the mentality of "Don't submit until you've really dealt with the issue" we could get a significant reduction in the overall backlog. Hasteur (talk) 03:07, 23 December 2017 (UTC)

If people are declining for under/over linking, then that is part of the problem this proposal is meant to address. — Insertcleverphrasehere ^{(or here)} 03:46, 23 December 2017 (UTC)

Hasteur, won't the MfD discussions invite more scrutiny on the reviewers who are using problematic reasons? Over time, as we catch problematic reviewers, the proportion of MfDs due to poor decline reasons should decline, so that the MfDs we see in the future are only for drafts that are very flawed. Enterprisey (talk!) 04:02, 9 January 2018 (UTC)

• Oppose problem AfC drafts being wholesale offloaded onto MfD. It would not be workable. Instead, AfC interested editors should establish criteria for what should be (1) accepted, (2) rejected for improvement, or (3) rejected outright. Currently, it is pretty vague, with no clear difference between (2) and (3). Also failing is the style of communication with the newcomer authors. Personally, I think that non-autoconfirmed should not be allowed to start any new page, including a draft. They should spend at least four days and ten edits improving existing content first. "Anyone can edit" is misconstrued as "anyone can start a page on anything". Draft:Researchfish is simply appalling on multiple fronts. The author has not be {{Welcomed}}. No Wikipedian has engaged the author with human-style talk. The many rejections are not in a language a newcomer can understand. The author does not understand Wikipedia. It is an embarrassment all round, and sending it to MfD hides the evidence of failure of the AfC process. --SmokeyJoe (talk) 05:04, 23 December 2017 (UTC)

  There are a couple things that unambiguously fall into (3): Specifically, any draft that would fall under G11 and anything that an existing article already covers. Other than that, however, barring more information or some wordsmithing most everything else rejected should fall under (2). —Jeremy v^_^v ^Bori! 23:00, 23 December 2017 (UTC)

  And this is one thing where AfC is continually failing. (3) is way too thin, and (2) includes a very large amount of stuff that can never become suitable. The AfC review process lacks a template to say this, the reviewers are very hesitant to say so, the draft author only gets an unclear message that they should try a bit harder. Hopeless resubmissions are the obvious consequence. —SmokeyJoe (talk) 06:33, 25 December 2017 (UTC)

• Support My only concern is the lack of participation at MfD, but it could draw other AfC contributors to vote. This is a great proposal. JTP ^{(talk • contribs)} 17:56, 23 December 2017 (UTC)
• Support - sounds as if it could actually contribute to solving two opposite ends of the current spectrum of troubles with AfC - too little breadth of input on the part of reviewers, and too little willingness to get stuff in shape on the part of some submitters. However, as Hasteur notes, MfD isn't exactly bustling. If this was piped into AfD instead, it would at least reach the people who only subscribe to special topic areas (like yours truly), but I guess that's not done for drafts. Related question: would the Deletion Sorting wikiproject be interested in expanding their servives to MfD? With 4-6 daily entries, it might not be much of a hassle. --Elmidae (talk · contribs) 08:01, 24 December 2017 (UTC)
• Oppose - Maybe I'm misunderstanding the proposal (I haven't read all the comments in this discussion), but I don't see how this would significantly reduce workload at AfC. The previous declines are right there in the reviewer's face and all it takes is quick diff to learn that it's been resubmitted again without significant improvement. Three strikes is overly bureaucratic and is punitive for no purpose but to be punitive. If it is clear that resubmissions are done in bad faith, we have other processes for dealing with that such as imposing a block for disruptive editing. ~Kvng (talk) 22:51, 26 December 2017 (UTC)

This proposal is not aimed at significantly reducing the workload at AfC, and nothing in the proposal claimed as much. It is as much aimed at incorrect reviewing as it is aimed at bad faith re-submissions. Generally this proposal is an attempt to address a number of issues that have been raised to a system that creates one-on-one interaction without collaboration.

I have made other suggestions elsewhere to discuss options to deal with the backlog at AfC, but largely it is my understanding that the backlog stems from too few active participants. Outreach and invitations to find new participants for the Wikiproject would likely be the best solution to the backlog and workload. — Insertcleverphrasehere ^{(or here)} 23:46, 26 December 2017 (UTC)

@Insertcleverphrasehere: I'm really not clear on what you're trying to address here; none of the 3 links in your proposal demonstrating the problem lead to anything specificall useful. If we have an "incorrect reviewing" problem at AfC, it is reviewers being too stingy with acceptance and this proposal does not address this. Truly bad-faith activities can be addressed as WP:DISRUPT if it rises to that level. Superfluous resubmission probably very rarely does. The best way to deal with such actions by newbies and IPs is to politely deflect it. Trying to impose a penalty for an ambiguous action is a waste of everyone's time and has the potential to make the problem worse. ~Kvng (talk) 14:04, 27 December 2017 (UTC)

hi Kvng, as someone who shares similar concerns as you, I was initially opposed to this proposal, but then I realised that it would actually help improve the AFC review process as eventually rejected drafts would come up in MFD, meaning that the wider community would get to provide oversight to AFC reviewers, without having to change the AFC system at all. Unless you are an AFC reviewer who wants to tediously go through all the rejected drafts, it's nearly impossible for the wider community to check that good potential drafts aren't being quietly deleted.Egaoblai (talk) 17:35, 27 December 2017 (UTC)

@Egaoblai: I didn't appreciate that a Keep result at MfD would result in the draft being automatically moved to mainspace. I doubt that would be the last word in some cases. This all just feels like we're building a bigger gauntlet. I'm afraid I remain opposed. ~Kvng (talk) 23:26, 27 December 2017 (UTC)

• Oppose a robotic system, but certainly support taking no-hope drafts to MfD to get rid of them or for additional editors to review and pass AfC drafts that meet notability criteria, verifiability, and BLP. If there are reviewers who are utterly failing to apply the appropriate criteria at AfC, then they should be talked to gently. If that doesn't work, warnings and removal from the area might be the way to go. I don't think throwing almost-there-but-not-quite drafts into mainspace is productive. I especially worry how this interacts with BLP. What if we have a clearly notable but totally unsourced biography of a living person? We're going to put that in mainspace due to a mechanical process? ~ Rob₁₃^Talk 16:52, 27 December 2017 (UTC)

Most new editors who have ′the "almost-there-but-not-quite" drafts don't really know how to make them complete. Surely putting them into mainspace where the community of people who do know how to add the finishing touches would be the best solution?Egaoblai (talk) 17:35, 27 December 2017 (UTC)

• (edit conflict)Support Per BU Rob13, actually, the FUD above makes me support placing multideclined drafts in front of MfD, because it allows for some definite broader community input as to what should happen with the draft. I trust the community to not place crap in mainspace, and I trust it better than one person deciding whether to decline/accept a draft. !dave 17:38, 27 December 2017 (UTC)
• Support as one of the more active AfC reviewers, an active MfD participant, and processor of thousands of G13 eligible drafts I've got a pretty good handle on the state of Draft space. I can say with confidence that this proposal will benefit both new users and AfC volunteers. There are far too many drafts that have 3, 5 or even 10 or more rejections. One I saw recently had 16 declines. At some point a topic is either suitable as an article or not - we need to decide that. Most of the declines are on subjects that are NEVER going to be suitable so let's tell the creators that definatively sooner than later. Some subjects are suitable but the poor draft creator lacks the wikipedia experience to get it page past AfC on their own. Such pages would benefit from sending them to mainspace to be expanded or merged by the big world of editors. AfC should not be a permanent holding pen for Drafts - more of a gateway that weeds out the crap and promotes the good. Clear decisions are much better than putting new users off wit repeated rejections. Legacypac (talk) 17:54, 27 December 2017 (UTC)
• Oppose currently We have tons of spammy articles getting through AfC. How is this going to help? We need more stringent notability requirements and should not become simply another social networking site on which people can promote themselves and their business. Doc James (talk · contribs · email) 06:03, 30 December 2017 (UTC)

@Doc James, I never claimed that this proposal was the answer to all the problems at AfC. I am not sure how to respond to this oppose as it seems to be a gripe that the proposal is not doing something that it never claimed to do (dealing with promotional articles was never a focus of this proposal). Other solutions may exist to that problem, but I agree that this proposal is not tailored to deal with those, although it might help to salt non-notable topics that are repeatedly submitted. — Insertcleverphrasehere ^{(or here)} 19:06, 5 January 2018 (UTC)

Thanks for the ping. I would support if those closed "no consensus" are deleted rather than moved to main space. Doc James (talk · contribs · email) 06:53, 6 January 2018 (UTC)

​In all other deletion discussions 'no consensus' defaults to 'keep', so I don't think that would work. However, I have added some clarification to the proposal that when the subject is deemed notable, but the submission is not suitable (i.e. NPOV) it should be converted to a short stub before being sent to main. This will avoid unsuitable submissions on notable topics being sent to main space. — Insertcleverphrasehere ^{(or here)} 09:18, 7 January 2018 (UTC)

• Support AfC isn't working well at the moment it would be great to have a change in it's working. In my own experience with having a biography of a person who's referenced in multiple peer reviwed papers and books not getting accepted because he's he doesn't hold mainstream views suggests that a lot of valuable content gets withold from Wikipedia by the current pratices of AfC. ChristianKl ❪✉❫ 22:54, 31 December 2017 (UTC)
• Support As someone who used to be very active at AfC, it seems like a win-win. Takes a load off of the AfC backlog, makes difficult borderline drafts get processed faster (since an AfC reviewer might be hesitant to single-handedly approve/reject it, and there's no good mechanism for wider consensus-building), and keeps AfC reviewers in check to make sure they are acting in-line with community consensus. --Ahecht (TALK
  PAGE) 22:25, 2 January 2018 (UTC)
• Oppose I don't think AfC's backlog should be unloaded to MfD, nor should the articles go into mainspace before they are actually ready. The problems include external links, references incorrectly formatted, unreliable sources, COPYVIOs, incomplete sentences, submissions not in English...Yes some of subjects may be notable, but the drafts are not ready for mainspace for other reasons. If anyone wants to improve the drafts and get them ready for mainspace they are free to do that, it is a free encyclopedia. What would help is if COI editors stopped submitting to AfC in the dim hopes that it will save their article from CSD. As for inexperienced editors and students submitting legitimate articles, I think what could help is additional categories so editors could more easily find drafts on topics they are knowledgeable about.SeraphWiki (talk) 07:24, 6 January 2018 (UTC)

​I wish you would have a bit more thorough reading of the proposal and reconsider your opinion. First: if you had read NOTE#2, you would know that this proposal is by no means a plan to "unload AfC's backlog to MfD" and doesn't even represent that large of a percentage of drafts. Second: the proposal does not advocate moving drafts to mainspace that are inappropriate. Third: COI editors are told specifically that they should submit their articles through AfC (I agree that they shouldn't be submitting articles at all, but that is never going to happen). — Insertcleverphrasehere ^{(or here)} 10:50, 6 January 2018 (UTC)

I read it twice and I understand what it means. Automatically putting drafts that have been rejected three times through MfD and then keeping them if there is "no consensus" is not, in my view, a feasible proposal. Where there is a policy-based justification for nominating a draft for deletion, it should be nominated, but why would that have to be automated? I should explain that what I am concerned about is those articles that are notable but are declined for tone, essay and other reasons. There should be more eyes on the drafts, yes-with a view to improving them. MfD is not cleanup, so if they are notable we will just move them to mainspace before they are ready? Sometimes it takes multiple declines to get there. Some calls, like whether a draft meets one of the deletion criteria, should be made by human beings. SeraphWiki (talk) 11:28, 6 January 2018 (UTC)

​Unsuitable topics can be taken to MfD already, being automated is what would make it also work as a review of the reviewers. Drafts that are declined multiple times are an issue, but not necessarily with the article. It can be one particularly nitpicky reviewer who watchlisted it and just declines over and over despite the draft being appropriate. In other cases the draft writer simply does not have the skills to get the notable topic past the NPOV, etc. In these cases the notable topic should be converted to a one/two line stub and sent to mainspace, not left to languish being repeatedly submitted and declined, or worse abandoned and later G13ed. An automated MfD would sort these drafts according to their issues, delete the non notable ones, and send the notable ones to main to be expanded and improved. I will add a line to the proposal above to make it clear what should happen to articles that meet notability criteria but that are not NPOV etc. While we can't expect reviewers or participants to put the effort in to fix a submission, converting to a short stub, even one line, and moving to main space is a solution to this issue. — Insertcleverphrasehere ^{(or here)} 20:47, 6 January 2018 (UTC)

• Support I have my concerns about making AfC an even more complicated process (for new users) than it already is, but making this change sounds like a good way to reduce the backlog. AdA&D 14:13, 8 January 2018 (UTC)

• Oppose any hard rules on automatically deleting something seem like a bad idea. Incremental progress is useful, and I don't see why setting "three strikes and your out" helps us grow the encyclopedia or engage new users in a lasting way. --Jayron32 16:41, 8 January 2018 (UTC)

hmm? it's not automatic deletion, it's automatic send to MfD where multiple people can take a look (and perhaps publish to mainspace) Galobtter (pingó mió) 17:11, 8 January 2018 (UTC)

@Jayron32, automatically deleting and "three strikes and your out" would be terrible ideas. It is a good thing that they are not part of this proposal. As discussed in proposal section, the proposal only automatically nominates a draft, which will then undergo a discussion, and determination as to whether it is suitable or not, and whether the reviewers have declined appropriately or not. After the discussion it might be deleted, not as a result of the automated nomination, but as a result of the discussion conclusions. — Insertcleverphrasehere ^{(or here)} 18:58, 8 January 2018 (UTC)

Additional question:

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

---

Should AfD be used instead of MfD? -- we are de-facto treating the draft like an article for the purposes of the discussion anyway (in terms of the potential outcomes), why not take it to AfD instead where there are even more eyes? (this is a proposed modification to the RfC above) Proposal by L3X1 above. Pinging previous !voters... — Insertcleverphrasehere ^{(or here)} 17:53, 21 December 2017 (UTC)

• Support Drafts are basically articles and should be dealt with as such. L3X1 (distænt write) 17:56, 21 December 2017 (UTC)
• Can just move the article to mainspace and insta nominate to AfD..doesn't really matter tho. Galobtter (pingó mió) 17:58, 21 December 2017 (UTC)
• Works for me. The AfC process works in screening out the obviously unencyclopedic and allowing a single author to develop an article as fully as possible. AfD would bring greater review and allow the community to sort the questionable. -- Dlohcierekim (talk) 18:24, 21 December 2017 (UTC)
• Oppose. GreenMeansGo makes a very good point above. The volume of drafts could very well overwhelm AfD, and it involves sending them there without any WP:BEFORE, which we are usually strict about. The administrative overhead at AfD, which has separate pages for discussion, logs, deletion lists, etc., is also higher than the other XfDs, and seems like overkill given that most of these will probably be uncontroversial deletes. At this point I'm thinking a new, separate process (DfD) would be best. – Joe (talk) 21:05, 21 December 2017 (UTC)

re:WP:BEFORE Things like WP:BEFORE and WP:ATD are extremely useful in preventing good quality articles from getting deleted. With drafts, it may not apply, but i'd argue the benefits outweigh the drawbacks. The problem is that the current system means that decent drafts can be deleted in a process where only one person has looked at the article. Some users and admins are blindly batch dropping and deleting hundreds of drafts at WP:CSD G13 without checking if the article has potential. This solution is the only one at present that solves the problem of a lack of transparency and collaboration at AFC without abolishing it completely. Egaoblai (talk) 23:31, 21 December 2017 (UTC)

Wait what?? Drafts aren't being judged on NOTABILITY btu on some other merit??? I don't care if is a frankly, crappy, article. If it is notable do a basic cleanup to the best of your ability and accept it. If it is, as Mabalu said once, a Promow*nk, then just TNT it! Nothing should be going to AfD sans BEFORE, and if it passes BEFORE (thereby being notable), it can be an article. 23:50, 21 December 2017 (UTC)

• Oppose using AfD to review drafts. I am a long time AfD participant, and AfD is for articles not drafts. We need more active participants at AfD, and this may break the back of that established review process. The biggest problem with AFC reviewing is the cookie cutter responses and the consistent failure to try to triage notable topics from non-notable ones. At AfD and at the Teahouse, people provide personalized responses instead of cookie cutter templates. If a topic is clearly notable, we should bend over backwards to help whip the draft into shape and add it to main space. If there is no evidence of notability, the kind thing to do is to kill the draft informatively so that the draft author understands why it is unacceptable. Treating poor quality drafts about notable topics the same way as poor quality drafts about non-notable topics is a terrible disservice to the encyclopedia. Cullen³²⁸ Let's discuss it 07:59, 22 December 2017 (UTC)

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

How about allowing certain CSD criteria to be applied to drafts?

I know that the proper venue for this question is at WT:CSD, this is just to check if there's any support for this (if there is, a formal proposal at WT:CSD could follow). From experience, while not as common as in the article namespace, quite a few drafts would most likely qualify for speedy deletion if they were in the article namespace. In many of these cases, even MfD might be too much considering MfD usually takes a week, so in these cases it's probably better to put these pages out of their misery quickly instead of subjecting them to a long discussion with an inevitable result. So I was thinking: should we allow drafts, if they meet the criteria, to be tagged under some of the CSD criteria for articles? For example, would it be possible to allow articles to be tagged under A1 or A3, or perhaps more likely, under A7, A9, and A11? Narutolovehinata5 ^tccsdnew 00:12, 22 December 2017 (UTC)

Not as part of this proposal. This proposal is not just a proposal to deal with bad AfC submissions. It is also meant to deal with too-strict reviewing by separating notable from non-notable topics via discussion and CSD does exactly the opposite. That being said, I'm not adverse to the idea for A7 and ilk (I've actually seen quite a few A7 tagged draft articles, appropriate or not). A1 and A3 should not be extended to the draft space IMO. — Insertcleverphrasehere ^{(or here)} 01:18, 22 December 2017 (UTC)

I recall having suggested this before, or more broadly that the article criteria should apply to drafts anyway since drafts are article drafts. There was very little support. Ivanvector (^Talk/_Edits) 14:29, 22 December 2017 (UTC)

For good reasons. Draft-space is designed to allow people to work on articles until they are ready for mainspace. If we started applying mainspace-criteria to them, we could just remove Draft-space altogether, because then where would be the difference? The last thing we need, not least in terms of editor retention, is to unleash a bunch of tagging-happy users (not saying that all taggers are such users, mind you) on pages that are in this namespace exactly for the reason of working on them without having to fear immediate deletion. Regards SoWhy 14:47, 22 December 2017 (UTC)

Oppose this strongly, CSD tagging drafts would be a disaster. we already allowed editors to tag drafts with G13, and as recent discussions have found out, some editors and admins aren't even bothering to check what is submitting to CSD and are just deleting things that are nominated without checking the article for alternatives. Adding more reasons for editors to use CSD for drafts would create more problems for the wiki and for the hope of keeping new editors. Egaoblai (talk) 17:14, 22 December 2017 (UTC)

@Narutolovehinata5: with respect, the G series of CSD apply to Draft pages. There has been significant opposition previously to users abusing process by promoting patently inappropriate drafts into mainspace in order to apply A series CSD rules to the page. If you think that the page has no hope and will never have hope, MFD is open for you to make your case as to why the page should be deleted. Hasteur (talk) 03:03, 23 December 2017 (UTC)

G11 and G12 are still valid deletion criteria for drafts (for G11, though, the draft would have to be so blatantly promotional that no amount of reasonable wordsmithing would fix it). —Jeremy v^_^v ^Bori! 17:40, 24 December 2017 (UTC)

*Support as one of the more active AfC reviewers, an active MfD participant, and processor of thousands of G13 eligible drafts I've got a pretty good handle on the stae of Draft space. I can say with confidence that this proposal will benefit both new users and AfC volunteers. There are far too many drafts that have 3, 5 or even 10 or more rejections. One I saw recently had 16 declines. At some point a topic is either suitable as an article or not - we need to decide that. Most of the declines are on subjects that are NEVER going to be suitable so let's tell the creators that definatively sooner than later. Some subjects are suitable but the poor draft creator lacks the wikipedia experience to get it page past AfC on their own. Such pages would benefit from sending them to mainspace to be expanded or merged by the big world of editors. AfC should not be a permanent holding pen for Drafts - more of a gateway that weeds out the crap and promotes the good. Legacypac (talk) 16:42, 27 December 2017 (UTC) Wrong section Legacypac (talk) 17:49, 27 December 2017 (UTC)

g13 already deals with this, and that itself is controversial. Giving people the power to delete active drafts (A real world equivalent would be snatching paper out of someone's hand and throwing it in a shredder) is far too much. If people's drafts are being rejected, they are free to keep trying, there is no current problem here that needs this drastic solution.Egaoblai (talk) 17:26, 27 December 2017 (UTC)

Agree. After all, does it really harm the encyclopedia to just wait in those few(!) cases until the draft is stale? And if a topic is sufficiently notable for mainspace and just needs some work, then send it to mainspace already. After all, the point of AFC is not to only allow GA-class articles to be sent to mainspace, is it? Regards SoWhy 17:35, 27 December 2017 (UTC)

@Legacypac, Was your comment meant to be in the above discussion section or this section about CSD? — Insertcleverphrasehere ^{(or here)} 17:40, 27 December 2017 (UTC)

Opps I placed it at the end of the discussion - which turned out to be the subsection not the main section. Thanks. Legacypac (talk) 17:49, 27 December 2017 (UTC)

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

Proposal for a new gadget (talk-tab-count)

Note that there is a discussion underway to decide whether User:Enterprisey/talk-tab-count should become a new gadget at WP:VPT#Proposal to make talk-tab-count a gadget. Enterprisey (talk!) 22:00, 9 January 2018 (UTC)

Bot to ping IP user talk pages when they're mentioned on another talk page

Hi, I've been working on a bot that will notify IP users when they're mentioned with a {{replyto}} by putting a {{ subst:Please see}} on their talk page. Thoughts?
Wikipedia:Bots/Requests for approval/Bellezzasolo Bot
∰Bellezzasolo✡ Discuss 22:10, 7 January 2018 (UTC)

Do IP users have talk pages?Vorbee (talk) 07:57, 8 January 2018 (UTC)

Yes Galobtter (pingó mió) 08:20, 8 January 2018 (UTC)

Excellent idea. Annoying to ping IPs, and I'm sure there are quite a few pings that are missed because someone thought IPs can be pinged.. Galobtter (pingó mió) 09:22, 8 January 2018 (UTC)

The address–person relationship is often very short-term, sometimes even a matter of hours. Depending on the type of connection and how much time has passed, the person behind the IP address may be at a different one, with a different talk page. You might even be notifying a different person by then. Seems flimsy. ―Mandruss ☎ 02:03, 9 January 2018 (UTC)

The bot is able to respond in a matter of minutes. Obviously, IP editors are an issue, but a talk message like that could easily be a warning for vandalism- or indeed a block. ∰Bellezzasolo✡ Discuss 02:39, 10 January 2018 (UTC)

I'm not talking about bot response time, but I'll withdraw my objection after more thought. Before coding a "replyto" for an IP, an editor should consider the amount of time since the IP editor's activity, just as they should do now before posting on an IP talk page. The bot would not introduce a new problem. ―Mandruss ☎ 03:34, 10 January 2018 (UTC)

• Could be a shared address, so a different person reacts to a ping regarding something they didn't do, even if it is just a few minutes. Many universities, offices, schools, have shared IPs. Plus IP addresses are not people applies here. If they want the benefits of being a user account, they need to get a user account. Dennis Brown - 2¢ 18:51, 13 January 2018 (UTC)

Agree broadly with this. Not having an account is a choice. Accounts are free and anonymous, if they want the benefits of an account they can have one in under a minute. Beeblebrox (talk) 20:30, 13 January 2018 (UTC)

Left-align all RfC listings

As seen here, some RfC listings are left-aligned and some are indented. This is done by the {{Rfcquote}} template. After brief discussion at Template talk:Rfcquote, it seems this is being done deliberately. Years ago an editor had the idea to center shorter listings, rationale unknown.

I was advised to sandbox a proposed edit to the template, but I lack the necessary tech skills. Perhaps if there is a consensus to change this, some kind-hearted template editor will do it.

PROPOSAL: Modify {{Rfcquote}} to left-align all listings to one indent level, as seen in many of the listings in the linked example.

• Support as proposer. The status quo makes no sense, and it gives the listing pages a messy and disorganized appearance. ―Mandruss ☎ 11:34, 9 January 2018 (UTC)
• Support utterly unnecessary. I've already figured out how do it- see Template:Rfcquote/testcases. (managed to do it through the my second choice in semi-randomly/cluelessly removing parameters!)- just have to remove margin:auto. Galobtter (pingó mió) 12:05, 9 January 2018 (UTC)
• Support. Unnecessarily difficult to follow the flow of threads at the moment. No good reason for treating short listings differently. Kb.au (talk) 15:24, 9 January 2018 (UTC)
• Suppport I don't really see why an RFC is needed for this when WP:BOLD would do, but for what it's worth, I'm for it. Headbomb {t · c · p · b} 17:51, 14 January 2018 (UTC)

 Implemented Galobtter (pingó mió) 17:55, 14 January 2018 (UTC)

Update post-edit confirmation (resolved)

You know the little "Your edit was saved" box that appears at the top of the screen? Now that the button that makes it appear has been renamed from "Save" to "Publish changes", the post-edit notification should be updated to "Your edit was published". It's needlessly confusing to click "Publish changes" only to be told your edit was "Saved", and avoiding this sort of confusion was the motivation (link fixed) for renaming the Save button in the first place. Adrian J. Hunter^{(talk•contribs)} 13:06, 13 January 2018 (UTC)

• Support for the sake of consistency. But I want to mention, Adrian J. Hunter, that the two links you posted are identical, and I can't find anything about the "motivation" at that link. Did you mean to post a different link for that? Anon126 (notify me of responses! / talk / contribs) 06:09, 15 January 2018 (UTC)

  Bah, thanks Anon126, fixed now. Adrian J. Hunter^{(talk•contribs)} 06:32, 15 January 2018 (UTC)

• There is already a ticket open about this. —TheDJ (talk • contribs) 09:47, 15 January 2018 (UTC)

  Resolved

   – Thanks TheDJ. Adrian J. Hunter^{(talk•contribs)} 14:25, 15 January 2018 (UTC)

Modest Proposal: Editors must read the Text or Author on which they edit prior to editing

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

---

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

---

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

---

Too many of our bloviating editors presume to edit articles on authors and texts which they have not themselves read. This problem is legion in the Philosophy section of the encylopedia, where the illiterati rule with an iron fist. I propose that no editor should be allowed to edit any article on a text or author without having read the text or author themselves, and that violators should be exiled or rebuked publicly with a scarlet letter. — Preceding unsigned comment added by 47.16.203.5 (talk • contribs) 2018-01-12T14:35:21 (UTC)

• Support Capital idea. Implement with furious speed. 47.16.203.5 (talk) 15:21, 12 January 2018 (UTC)
• Impossible until we solve thoughtcrime. —TheDJ (talk • contribs) 15:24, 12 January 2018 (UTC)
• Super-duper oppose. People writing about or commenting on topics they know absolutely nothing about are the life and blood of the encyclopedia. If they got removed, then Wikipedia as we know it will cease to exist. – Uanfala (talk) 15:46, 12 January 2018 (UTC)
• Oppose per others, entirely unenforceable, and violators should be exiled or rebuked publicly with a scarlet letter smacks of trolling. ―Mandruss ☎ 16:00, 12 January 2018 (UTC)
• Oppose - I propose that no editor should be allowed to propose a new policy without having read the existing policy themselves, WP:PRIMARY. The proposal also assumes you need to have read Wittgenstein to edit his date of birth... pffft. Cabayi (talk) 16:05, 12 January 2018 (UTC)
• Question. How would we know whether or not a would-be-editor has read an article?Vorbee (talk) 16:26, 12 January 2018 (UTC)
• Oppose Assume good faith is a core principle; we assume editors have read material that they are citing in an article. If it becomes a pattern that an editor is not at all representing what sources say to the point of being disruptive, we deal with that on a case-by-case basis. --Masem (t) 16:43, 12 January 2018 (UTC)

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

• Now seriously, even though there is probably no way we could do anything about that, we could at least acknowledge the problem, can't we? I don't think I'm the only one who's had to, time and again, deal with article content or !votes in discussions done in perfectly good faith but afflicted with misunderstandings and misinterpretations at various levels of subtleness or grossness, and which would never have been there if the editor who contributed them had had the most rudimentary awareness of the overall context of the topic. – Uanfala (talk) 19:57, 12 January 2018 (UTC)
• Reverse support. If an editor has read the text or author that is the subject of an article, they now have a COI and should not be allowed to edit the article. Natureium (talk) 20:00, 12 January 2018 (UTC)
• I'd be happy if people just read the article before editing it. The number of times I have to revert due to someone apparently not doing so is legion, eg: in the last couple of days at Bhagat Singh. It won't happen, of course, and I'm not daft enough to propose it. - Sitush (talk) 20:21, 12 January 2018 (UTC)

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

How many nesting levels of closing and hatting are we going to get? – Uanfala (talk) 20:29, 13 January 2018 (UTC)

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

RFC on Terms for Admins

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

---

Should there be a term for adminship, after which if an admin wants to continue as admin needs to go through another RFA? Sir Joseph ^(talk) 15:18, 17 January 2018 (UTC)

Survey: Terms for admins

• Oppose term limitslimited terms, but support effective recall procedures. --SarekOfVulcan (talk) 15:44, 17 January 2018 (UTC)

  To clarify, this is not for term limits, rather for terms of office. So an admin, under this proposal, can serve for 10 years, once they pass the RFA after every term. Sir Joseph ^(talk) 15:52, 17 January 2018 (UTC)

  Thanks, fixed. --SarekOfVulcan (talk) 16:00, 17 January 2018 (UTC)

• Support terms and also to echo SarekofVulcan there does need to be a real method of recall. I suggest for terms, a two year term. Sir Joseph ^(talk) 15:52, 17 January 2018 (UTC)

  Two year terms? There are currently 1200 admins. That's 50 RfA's per month, 11 per week. Since an RfA runs for one week that means 11 simultaneous RfA's running continuously, and even that assumes that they will be evenly distributed. Completely unfeasible. — Insertcleverphrasehere ^{(or here)} 20:14, 17 January 2018 (UTC)

• Oppose the whole reason en.wiki has gone with the whole “in good behavior” model is that the unique political environment we are in would make it so that admins in any area would be afraid to make the correct calls. Look at the most recent RfB (where I opposed, but I think it’s a good example): you have an admin who was doing his job in good faith and in line with policy facing calls for a desysop because he was conservative on CSD. I’d hate to imagine what the admins who actively work AE and ANI would face. TonyBallioni (talk) 15:56, 17 January 2018 (UTC)
• Oppose I don't like the prospect of essentially forcing recalls on every single administrator. We shouldn't be putting admins in good standing through multiple RfAs; I recommend focusing on something that actively works to remove the admins in which the community has lost trust instead. Nihlus 16:02, 17 January 2018 (UTC)
  • We already have that in the form of an ArbCom case request: they are very effective and serve both to protect the community from abusive admins and to prevent rage-based desysops at ANI. TonyBallioni (talk) 16:08, 17 January 2018 (UTC)
    • Yes, I know. However, the trend as of late is to establish a selective recall process of some sort that the community controls. However, the myriad of proposals (including this one) put forth so far have been underwhelming and entirely miss the mark. Nihlus 16:13, 17 January 2018 (UTC)
• Oppose Per TonyBallioni; oh god, yes he is somewhat single-minded in RfA's and being conservative in CSDs but that's not desyopable. I think an AE admin would have a smorgasbord of "oppose - blocks experienced editors too quick", "oppose - doesn't block quick enough", "oppose - has double-standards in blocking". On the number of RfAs, wonder how many less RfAs would be there assuming not automatic running, and so most inactive admins won't - but then you'd lose admins etc. Galobtter (pingó mió) 16:14, 17 January 2018 (UTC)
• Oppose per this. Any other discussion seems like overkill for a fairly clear SNOW fail. ―Mandruss ☎ 16:27, 17 January 2018 (UTC)

  How many of them are active, and how many would want to continue should an RFA be required? Sir Joseph ^(talk) 16:37, 17 January 2018 (UTC)

  In other words, many admins will commit adminisuicide rather than submit to another grueling RfA, so the problem isn't as bad as 12 per week. That's !wonderful reasoning—never mind that 3 per week would be more than we could handle. No, the sensible thing is to deal with the few bad ones and leave the many others alone. If the mechanism for dealing with the few bad ones needs improvement, this proposal isn't going to accomplish that. ―Mandruss ☎ 16:55, 17 January 2018 (UTC)

• Support - Wonderful idea, We can lose more and more admins after each year and then we become just like Simple English Wikipedia .... That sounds a great plan I fully support it can you tell ?. –Davey2010^Talk 16:31, 17 January 2018 (UTC)

  I can tell that this is clearly sarcastic. Emir of Wikipedia (talk) 16:45, 17 January 2018 (UTC)

  You're very perceptive. ―Mandruss ☎ 16:57, 17 January 2018 (UTC)

  I assume they had some help with that Regards SoWhy 16:33, 18 January 2018 (UTC)

• Oppose Mostly per TonyBallioni, but I also share the concerns of SarekOfVulcan. At least at the beginning, the number of RFAs running at a time would be overwhelming. The number of administrators both active and inactive would slowly drop, further starving the project of active administrators willing to deal with conflicts. --AntiCompositeNumber (talk) 16:35, 17 January 2018 (UTC)
• Oppose This looks like a solution in search of a problem. Unless we have a serious issue with dormant administrators returning and making catastrophic mistakes - which we don't - there is no purpose to this proposal. Yunshui ^雲_水 16:53, 17 January 2018 (UTC)
• 'Oppose. Mechanisms exist to remove egregiously bad admins, and this proposal would just deter people from engaging in controversial work and overwhelm RFA. ---- Patar knight - ^chat/_{contributions} 17:02, 17 January 2018 (UTC)
• Oppose At the moment we have 1,240 admins. If each of these was required to go through RfA after two years, and every two years thereafter until desysopped, this would mean that on average twelve reconfirmation RfAs would be started every week (one every fourteen hours or so), and that's in addition to the new admin candidates (there were 40 RfAs in 2017, or one every nine days). Quite apart from the fact that a number of admins would not wish to go through the whole RfA process even once after their original RfA, could we get an appropriate level of interest from the regular RfA voting crew without tedium setting in? The whole notion is impractical. --Redrose64 🌹 (talk) 17:09, 17 January 2018 (UTC)

  Oh, I see that SarekOfVulcan has already written much the same thing (subsection below). I stand by my argument. --Redrose64 🌹 (talk) 17:12, 17 January 2018 (UTC)

• Support Such extensive rights should be revalidated at a regular interval. The process for doing so might be streamlined or refocussed to look at what the editor had done with the admin functions. The recent reconfirmation of Harrias shows that it need not be a big deal. Note that, as the years pass and the amount of fresh blood is now limited, the admin corps may increasingly become a gerontocracy. This does not seem balanced or sensible when arbcom is subject to the comparatively stringent process of an identity check and regular annual elections. Andrew D. (talk) 17:32, 17 January 2018 (UTC)

  Your behaviour at RfA has repeatedly dissuaded a significant number of candidates from running at RfA, and it is your behaviour which dissuades a significant portion of the community actually committing to a sensible re-validation proposal. I don't think the community will begin to countenance a re-validation system when there are users such as yourself who make ridiculous and entirely unhelpful comments at venues such as RfA. Nick (talk) 18:03, 17 January 2018 (UTC)

  What is this significant number? Please list some of these candidates and provide evidence that they have been dissuaded. Andrew D. (talk) 19:55, 17 January 2018 (UTC)

• Oppose IMO this is a Wikipedia:Don't be high-maintenance RFC. There are other avenues for removing an admin who is not meeting the standards set for them. MarnetteD|Talk 17:42, 17 January 2018 (UTC)
• Oppose per Redrose64, it just isn't practical. --Cameron₁₁₅₉₈ ^(Talk) 18:01, 17 January 2018 (UTC)
• Meh - It's logistically prohibitive, as pointed out by others. And would probably mostly just end up clearing out a bunch of old timers, who are mostly harmless, if occasionally annoying. GMG^talk 18:13, 17 January 2018 (UTC)
• Oppose. One of the inevitable effects of an active adminship is that you will piss off spammers, COI editors, and zealots, even if only by the neutral and dispassionate closure of discussions in conformity with a consensus that disagrees with them. It is likely that an automatic reconfirmation procedure would become a magnet for the disaffected to make trouble for those who moderated the project to their dissatisfaction. I would support a reasonable recall procedure where the need can be demonstrated by showing bad admin conduct separate from merely disputed admin actions. bd2412 T 19:18, 17 January 2018 (UTC)
• Oppose periodic reconfirmations/refra's for all admins. I'd rather see inactivity reforms, perhaps with reconfirmation required for barely active admins that want to retain tools. — xaosflux ^Talk 19:22, 17 January 2018 (UTC)
• Oppose , concurring with  xaosflux. Besides which, this RfC is a perennial proposal which has never gained traction. Kudpung กุดผึ้ง (talk) 19:43, 17 January 2018 (UTC)
• Oppose aw HELL No... it is a bit like asking the diciplinarian parent to stand for reelection. The kids have more votes than the parents. — Insertcleverphrasehere ^{(or here)} 19:48, 17 January 2018 (UTC)
• Oppose - As others have said above, it would inhibit the work of any admin who is active an areas like AE, ANI, etc. We need admins who can act without fear of reprisal. I agree an effective (or more effective) means for recall could be helpful. And an inactivity review (perhaps just confidence/no confidence !votes). But new RFAs each term is extreme. EvergreenFir (talk) 19:51, 17 January 2018 (UTC)
• Oppose limited terms per TonyBallioni and bd2412, but support an effective recall process as suggested by SarekOfVulcan. Tony Tan · talk 19:55, 17 January 2018 (UTC)
• Oppose This proposal stands to do more harm than good. It doesn't actually stand to do much good at all. I'd like to see a more streamlined method of admin removal but not a system where someone loses their adminship because they can't get enough votes because a campaigning troll is pissed off at them because they were banned for behaving outside of wiki norms. A system like this stands to just do that.-Serialjoepsycho- (talk) 01:41, 18 January 2018 (UTC)
• Oppose per Wikipedia:Perennial proposals#Reconfirm administrators. All of the reasons mentioned there still apply, especially the huge amount of time wasted for having 12+ of those RfAs each week. Regards SoWhy 16:30, 18 January 2018 (UTC)
• Oppose per most of the above, in particular Tony. Suggest SNOW Close. -Ad Orientem (talk) 16:42, 18 January 2018 (UTC)

Discussion: Terms for admins

There have been previous discussions on this; anyone know some? Galobtter (pingó mió) 15:38, 17 January 2018 (UTC)

Listed as perennial at Wikipedia:Perennial proposals#Reconfirm administrators. ―Mandruss ☎ 15:40, 17 January 2018 (UTC)

Hmm, no recent, within few years discussion listed there on this Galobtter (pingó mió) 15:45, 17 January 2018 (UTC)

What is the rationale for this proposal? Jo-Jo Eumerus (talk, contributions) 15:56, 17 January 2018 (UTC)

For me, it's that we should not have lifers. We have admins who were granted the power a decade ago, we also have admins who come on once or twice a year. Everywhere else in the world some sort of power structure routinely has a tenure and a need for renewal. We should not grant people admin powers and then leave it in such a way that the bar to remove those powers are difficult. Sir Joseph ^(talk) 15:59, 17 January 2018 (UTC)

@Sir Joseph: At minimum you need to include your rationale in your !vote, else it's a !!vote (aka vote). ―Mandruss ☎ 16:02, 17 January 2018 (UTC)

(edit conflict) Our system is roughly like the US courts and most appointed upper houses: places where people are put specifically to make unpopular decisions that need to be made sometimes. The community recognizes this, and gives admins protection because of it. ArbCom can remove when needed, and normally does once a case has been accepted. TonyBallioni (talk) 16:06, 17 January 2018 (UTC)

I understand that, but what do we do about certain "super admins?" You're a fairly new admin and if you screw up, you could be removed, but there are admins that have such a cemented adminship that they are untouchable, and they know it, and everyone else knows it. We do need a better way of dealing with admins who should not be admins. Going to ARBCOM is such a big deal, perhaps an RFC/U or RFC for removal of adminship is something we can work on. But I also don't think being an admin should be a lifetime job. Sir Joseph ^(talk) 16:36, 17 January 2018 (UTC)

TRM and Salvidrim! were both desysoped, and they both were/are popular with large segments of the community and had been longstanding admins. The advantage of the ArbCom process is that it allows much wider community consultation than the noticeboards (upwards of 50 people commented on the Mister Wiki case request), it allows a thorough examination of the facts, and it forces a desysop to only occur when a cross section of the community has approved it: the committee is the only body that is elected by the community at large, and with around 2,000 people voting for it is much more representative than any noticeboard discussion could be. The solution if you don't like the current committee is to run or have people who think like you run. The solution if you think more admins should be desysoped for abusing their role is to file a case request. There is nothing stopping anyone from doing either. The fact that people don't I think shows that the system works as intended: if something an admin does isn't worth the ArbCom case it likely isn't a big enough deal to desysop. TonyBallioni (talk) 16:46, 17 January 2018 (UTC)

No, it could also show that a person is not willing to put himself in the crosshairs. Let's say I want you desysopped. I post on your page that I am requesting you to step down, or open yourself up to recall. You, and your posse, will then have it out for me. There are cliques here, ,and I think you will admit to that. Whether this passes or not, there has to be a better way of dealing with removal of sysop tools. An ARBCOM case should not be the only option. I have a couple of admins in mind who I think should not be admins but there is nothing I can do about it. Were I to post an ARBCOM case, the posse will come out, all oppose and then I'd be blocked most likely. Sir Joseph ^(talk) 17:29, 17 January 2018 (UTC)

@Mandruss and Sir Joseph: sorry about the mis-sign (the script read it). Whomever is proposing this RfC should use a full signature rather than just having the date so we know who to address questions to. TonyBallioni (talk) 16:01, 17 January 2018 (UTC)

Ok. Sir Joseph, please sign your RfC. ―Mandruss ☎ 16:03, 17 January 2018 (UTC) @Sir Joseph: Never mind, I did it for you after waiting over ten minutes. ―Mandruss ☎ 16:15, 17 January 2018 (UTC)

There are currently 1240 admins, according to WP:ADMIN. With two-year terms, that's as many 12 RFAs per week, continuously. That's not practical. --SarekOfVulcan (talk) 16:10, 17 January 2018 (UTC)

That might only be if all 1240 are active and want an RFA, which is something to consider. Sir Joseph ^(talk) 16:36, 17 January 2018 (UTC)

Say 33% decide not to run again. That would take it down to 8 RFAs per week, again continuously, for at least 2 years. --SarekOfVulcan (talk) 17:04, 17 January 2018 (UTC)

If people think RFA is horrible now, wait until some of these reconfirmation RFAs are put up. --NeilN ^{talk to me} 17:06, 17 January 2018 (UTC)

Most unlkely that there will be a stampede by admins standing for reconfirmation on a voluntary basis. It's already been stated in several places that this is such a rare occurence, it's not even worth discussing. Kudpung กุดผึ้ง (talk) 19:49, 17 January 2018 (UTC)

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

Should mathematical Equations be text instead of images?

There have been many times that I have wanted to use mathematical equations I found on Wikipedia, so that I could put them into a text document or online calculator like wolfram alpha and realized that they were inline images rather than formatted text. If I just want the equation as is, that would be fine, but I often want to use the equation or slightly edit it, and images are not usable. I just have to open multiple tabs and hand copy it over.

I am not sure how this would be implemented, but it would help end users like me. — Preceding unsigned comment added by Michalchik (talk • contribs) 23:01, 8 January 2018 (UTC)

I'm confused. Taking a few examples from template:math:

f(x) = b^x = y

and

1/2 − 1/3 = 1/6

copy/paste just fine from WP directly into Wolfram Alpha for me using Win10 and Google Chrome.

∫^+∞
₀ e^−x dx = 1

does not. From the above, though, I'm not sure what alternative presentation you are suggesting. Wtmitchell (talk) (earlier Boracay Bill) 02:49, 9 January 2018 (UTC)

@Wtmitchell: A) The user is probably commenting on <math> tags, which for B) the majority of users and all readers (not logged in users) are served images, rather than some obviously copy-and-pasteable stuff. --Izno (talk) 03:35, 9 January 2018 (UTC)

Having mathematical equations as text seems to make sense for me - after all they are not images. Vorbee (talk) 11:53, 12 January 2018 (UTC)

@Whatamidoing thanks for the ping. It would be great if average users could copy equations on Wikipedia the same way as on other websites. For example two days ago user:Elcap wrote: "Bei der Schreibweise der Formeln und den Einheiten habe ich Probleme, seitdem ich Windows 10 habe. Die Formeln und Einheiten mit "math" geschrieben werden beim Kopieren nicht in Word eingefügt, deshalb in geschriebener Weise." [2] (= he cannot copy equations into microsoft word) I did not enquire further since the discussion was on improving the article, but from my expericence with <math>, the very old "use html for simple formulas" was copyable, the png images could be copied as images (with obvious drawbacks), MathJax (as opt-in for registered users) was copyable and the current rendering is not, unless you are for example a firefox user and have installed the "MathML Copy" addon.

My suggestion would be to use MathJax like on math.stackexchange.com, however it appears to be difficult to integrate into MediaWiki and my proposal [3] did not get enough votes. I hope this changes with MathJax 3.0 (a first alpha version was released recently) which has built in support for node.js.--Debenben (talk) 17:05, 13 January 2018 (UTC)

@Michalchik: In Preferences -> Appearance, there is a 'Math' section that lets you chose between "PNG images", "LaTeX source (for text browsers)", or "MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools)" - does the last one in particular handle this issue? Is it not the default for readers/new users? Thanks. Mike Peel (talk) 20:34, 13 January 2018 (UTC)

Mike Peel, you are correct that MathML is the default. But I believe User:Izno is also correct to say that most readers are getting the "SVG or PNG fallback" instead of the MathML. Whatamidoing (WMF) (talk) 18:26, 19 January 2018 (UTC)

Redirect _ to Underscore (character)

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

---

Redirect https://en.wikipedia.org/wiki/_ to Underscore (character) Care to differ or discuss with me? The N^th User 04:09, 15 January 2018 (UTC)

• Support The intent of the person who typed "_" into the URL bar is obvious. Care to differ or discuss with me? The N^th User 04:09, 15 January 2018 (UTC)
• Oppose. That title is currently not allowed because of technical restrictions, and I don't think change that is worth it for this case. (And even if it were allowed, spaces and underscores are interchangeable in URLs, so who's to say that it shouldn't redirect to Space (punctuation) instead? ) Anon126 (notify me of responses! / talk / contribs) 05:50, 15 January 2018 (UTC)

In that case, what if it led to the standard bad title page, but with links at the bottom to Underscore (character) and Space (punctuation)? Care to differ or discuss with me? The N^th User 02:01, 16 January 2018 (UTC)

If I've understood correctly you're asking for a change to Wikimedia code that has no function other than to allow something useful to appear when a user types an underscore into the search box. I don't know what the developers' priority queue looks like, but I wouldn't count on that bubbling to the top of it any time soon, or ever. --Trovatore (talk) 02:15, 16 January 2018 (UTC)

@Trovatore: These can easily be changed at places like MediaWiki:Title-invalid-empty and MediaWiki:Badtitletext. You can find more here. Nihlus 02:25, 16 January 2018 (UTC)

Ah. Well, I did say "if I've understood correctly" :-). --Trovatore (talk) 04:09, 16 January 2018 (UTC)

• Oppose - I fail to see the point in this .... If you didn't know the name of it then you'd search "_" but I'd imagine 99.99999% of the world knows what an underscore is. –Davey2010^Talk 16:35, 17 January 2018 (UTC)
• Oppose Underscores are url representations of spaces. Titles cannot start or end with a space per Wikipedia:Naming conventions (technical restrictions)#Spaces and underscores. An exception for an isolated space would require a MediaWiki change and be confusing. Many features stripping leading and trailing spaces would need adaptation. Different wikis would want to redirect it to different names or make it an article so I assume " " (one space) would become a valid title linked with [[ ]] and [[_]]. The name would be invisible unless you also make a MediaWiki change saying that a single space is displayed as an underscore unlike all other spaces. This creates more confusion. If you make a redirect on "_" without making it a real page then you confuse people trying to edit the page or find its code. And I don't find it "obvious" that a single underscore or space in the url or search box means that a user is looking for an article about those characters. It could just as well be a software or human error. The top article at User:West.andrew.g/Popular pages is currently "-" with 10 million views in a week. How many of those were actually looking for that character? PrimeHunter (talk) 18:02, 17 January 2018 (UTC)

To be fair, most of the hits on - are coming from the Blackboard Safeassign web spider, not real users (see phab:T150990). --Ahecht (TALK
PAGE) 21:22, 18 January 2018 (UTC)

• Oppose: Going to "_" doesn't work and brings up "The requested page title is empty or contains only the name of a namespace." Adding a link to just an underscore doesn't work (see here: [[_]]) (I didn't use nowiki tags). —MRD2014 ^Talk 00:55, 22 January 2018 (UTC)
• Oppose Technical reasons as outlined above. In fact, it's basically impossible and we'd probably reject a Phab request to do it. Suggest closing this proposal. FACE WITH TEARS OF JOY ^[u+1F602] 05:54, 22 January 2018 (UTC)

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

RM is botched

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

---

The requested moves process is botched. For example, {{refimprove}} was recently moved from its original name to a name that would be more appropriate for an inline template due to a RM "discussion" with 3 !votes. I think that RM should be closed, and move requests should be handled via the XFD process, which, unlike RM, actually involves discussion. KMF (talk) 01:50, 23 January 2018 (UTC)

• The requested move process is in my opinion one of the most effective discussion venues we have on Wikipedia largely because of the fact that the regular participants in RMs understand that Wikipedia's policies and guidelines are often in tension, and those of us who close RMs regularly balance the arguments with this same understanding in mind. If anything, as someone who is an active participant in both venues, I would much prefer XfDs to be made more like RMs, not vice versa. Additionally, XfDs should close as soft delete if there have been no comments opposing and it seems uncontroversial (see WP:SOFTDELETE), and RMs follow the same principle. You'll have relists when neccesary if the closer finds it controversial and not in line with policy. Finally, 3 !votes is more than you get on most XfDs these days, and is more than enough for a consensus at an RM, which simply requires lack of opposition. TonyBallioni (talk) 01:56, 23 January 2018 (UTC)
• I think the RM process is quite good, robust, intuitive, easy to engage. WP:MR is quite good too. Maybe KMF’s problem could be stated as inadequate advertising for a protected template, requiring more advertising sounds reasonable, changing the process, no. —SmokeyJoe (talk) 02:18, 23 January 2018 (UTC)

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

Move some talk-page templates to page itself

I think that templates such as {{image requested}}, {{map requested}}, and {{infobox requested}} should be placed on a page itself instead of its talk page, in line with most other cleanup templates. KMF (talk) 18:12, 20 January 2018 (UTC)

That'd be a problem because cleanup templates are for problems and there is no universal agreement that the absence of infoboxes, maps or images on a given article is one. Jo-Jo Eumerus (talk, contributions) 19:10, 20 January 2018 (UTC)

I would agree with Jo-Jo Eumerus and oppose this proposal. There are quite a lot who already complain that too many articles languish with clean-up templates on them for years and years without the underlying issues ever being addressed. Adding to that burden with "image requested" templates on vast numbers of pages helps noone, nor can anyone just nip out and resolve the issue, as they can by editing the article itself and addressing content or style concerns. Flagging pages for image or a map wanted are merely desiderata for improvements, best left to the Talk page. I could be pursuaded that flagging up an absent Infobox/taxobox is worth highlighting on the main page, but that wasn't what you were proposing. Regards, Nick Moyes (talk) 14:00, 21 January 2018 (UTC)

Disagree - Though i agree that images are one of the most important portions of an article, i think cleanup templates and so forth are already too prominent. The average user who never has any interest in editing will just think it’s a worthless article that even editors disdain. It’s better if they don’t see how hard the swan is kicking. Nessie (talk) 16:00, 21 January 2018 (UTC)

Agree - It better reminds of editors that the article needs an image/a map/an infobox.--RekishiEJ (talk) 14:17, 23 January 2018 (UTC)

List of creators through Twinkle

Before reading this thread, kindly go through the small thread at Wikipedia:Village pump (proposals)/Archive 143#List of previous creators of an article.

The progress of "creation log" is now officially in "discussion mode" (similar to a court stay order).
Anyways, I hereby request a tweak in automated edit summary of twinkle (and other admin tools) while deleting a page, to add creator's name. This can be used while creation log is created. —usernamekiran(talk) 12:12, 24 January 2018 (UTC)

Please create a Github request for Twinkle related modifications.Though given the inactivity of the devs, I don't expect much!Winged Blades^Godric 12:21, 24 January 2018 (UTC)

RFC: Infoboxes should be collapsable, in non-politician & non-sports bio articles.

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

---

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

Clearly failed per WP:SNOW. GeoffreyT2000 (talk) 04:10, 24 January 2018 (UTC)

---

We've several articles (mostly bio articles, I believe) that have infoboxes (usually up in the right top corner) in them, which aren't politicians or sports figures. Such article's infoboxes should be collapsed, to satisfy those who 'prefer' them & those who oppose them. GoodDay (talk) 02:49, 24 January 2018 (UTC)

• Oppose This is an attempt to impose infoboxes on all bio articles. MarnetteD|Talk 03:07, 24 January 2018 (UTC)
• Comment Discussion should be on an individual infobox basis. Doc James (talk · contribs · email) 03:10, 24 January 2018 (UTC)
• (edit conflict)Ummmmm what a wiki-wide rfc for putting politicians and sports figures apart? How about bridges and LDS Temples? If this is about a specific template, that template's talk page is a good place to have a chat. — xaosflux ^Talk 03:11, 24 January 2018 (UTC)
• Oppose I prefer infoboxes in all bio articles and I don't believe they should be collapsed. Lepricavark (talk) 03:23, 24 January 2018 (UTC)
• Oppose per Xaosflux. TonyBallioni (talk) 03:26, 24 January 2018 (UTC)
• Oppose - If you don't believe we need an infobox in an article then take it to the talkpage and get consensus for its removal, Even if we had this "collapsible" option that would never solve the issue ... It'd start a whole new issue instead. –Davey2010^Talk 03:57, 24 January 2018 (UTC)

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

This is an Rfc, not an Afd or Page move proposal. Should be opened for a full month. GoodDay (talk) 04:13, 24 January 2018 (UTC)

WP:SNOW applies to all kinds of discussions. not just AfDs or RMs. — Insertcleverphrasehere ^{(or here)} 04:15, 24 January 2018 (UTC)

I'll bring this topic to WP:INFOBOX, but avoid making it an Rfc. GoodDay (talk) 04:21, 24 January 2018 (UTC)

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

RfC: Cross-wiki redirects to Wiktionary

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

• Summary:--There is consensus to Y keep the cross-wiki redirects.And, the proposal stands N rejected.
• Details:--On weighing the arguments put forth by the two sides, it seems that the redirects serve a quite good purpose to our readers, not only by linking to these special dic-defs in a user-friendly manner but also by actively deterring users from creating dictionary-entries at the corresponding red-links.In a nutshell, SoWhy's and Bushranger's arguments clearly tilt the outcome of the discussion.
• Signed by Winged Blades^Godric at 04:58, 26 January 2018 (UTC)

---

Should cross-wiki recirects to Wiktionary be deleted, all or in part? Huon (talk) 00:46, 26 December 2017 (UTC)

Survey (Cross-wiki redirects to Wiktionary)

• Delete all Huon (talk) 00:46, 26 December 2017 (UTC)
• Save prefix/suffixes. For instance: -ic, -izzle, Petro-, -ous, it seems appropriate for these. Brightgalrs (/braɪtˈɡæl.ərˌɛs/)^[1] 13:56, 27 December 2017 (UTC)
• Delete them all. I've always hated this cross-project redirects, and interwiki search results make them even less useful. FACE WITH TEARS OF JOY ^[u+1F602] 18:34, 27 December 2017 (UTC)
• Delete all per NOTDICTIONARY, which they basically turn us into. TonyBallioni (talk) 19:13, 27 December 2017 (UTC)
• Delete all yeah, don't see the value in them, NOTDICTIONARY and all that. Galobtter (pingó mió) 19:24, 27 December 2017 (UTC)
• Delete all, unless the search filters out the results for a term (e.g. " ", though that page isn't a Wiktionary redirect). Jc86035 (talk) 08:54, 28 December 2017 (UTC)
• Keep {{wiktionary redirect}} is not really a cross-wiki redirect, it's little more than a replacement for the standard "Wikipedia does not have an article with this exact name" message, and doesn't over-emphasize Wiktionary, but is infinitely more useful for readers that get there via a wikilink or google search.--Ahecht (TALK
  PAGE) 17:48, 5 January 2018 (UTC)
• Keep. I don't understand the rationale behind this proposal. {{wiktionary redirect}} serves a valuable function in helping to prevent the creation of dict-def articles. older ≠ wiser 20:56, 5 January 2018 (UTC)
• Keep. I think this keeps Wikipedia from being a dictionary. Otherwise we'd have articles that would be a definition. The soft redirect highlights the difference without leaving users in a lurch. Users are unlikely to click on a red link and then search and then click on the wiktionary suggestion. Nessie (talk) 17:03, 7 January 2018 (UTC)
• Keep all per NessieVL's reasoning above. WP:NOTDICTIONARY says "Wikipedia is not a dictionary, phrasebook, or a slang, jargon or usage guide" (emphasis added). Linking to a dictionary does not make Wikipedia a dictionary just like linking to YouTube does not make it a video sharing platform. The redirect serves a valuable function in cases of (accidental) linking and actively prevents users from creating dictionary entries by making it clear that someone has already thought about it and decided that this is not a subject that should have an article. The template's documentation already limits the usage to a few cases but those are useful ones. Regards SoWhy 10:31, 8 January 2018 (UTC)
• Keep per the rationales above. The links to Wiktionary help direct readers to the actual dictionary definition, which prevents a duplicate article from being created here. --Jayron32 16:38, 8 January 2018 (UTC)
• Delete all - Wikipedia is not a dictionary. Jack1956 (talk) 00:42, 11 January 2018 (UTC)
• Delete all per others and WP:NOTDICT, especially now that interwiki search results exist. Even when some users use a gadget via preferences settings to opt-out/hide the results, I don't see necessity to preserve all crosswiki redirects to Wiktionary entries as they take up a lot space and lack valuable encyclopedic content. Some of them can be either converted to or reincarnated as encyclopedic articles. Well, I perceive potential re-creations of some crosswiki redirects to those entries, but that's something that can be individually raised at RfD (or DRV) in the future. I wonder whether WP:G4 applies to those redirects if deleted per this discussion and then re-created.

  WP:R#KEEP guideline shows what reasons are to avoid deleting redirects; however, even when R#KEEP is enforceable for those redirects, I don't see how preserving those crosswiki redirect pages helps improve Wikipedia. Even the conditions of WP:R#DELETE aren't met for most of them. WP:GUIDES says to make some exceptions and use common sense in case that the guideline doesn't help much.

  Other things already do the same roles that those redirects do. Disambiguation pages and {{Wiktionary}} are sufficient enough and can take over the roles of those cross-wiki (soft) redirects. In response to an argument saying that those redirects are meant to prevent dictionary entries, the protection system, which includes creation-protection and EC-protection, already does the role (but by preventing re-creation) if things get out of hand. George Ho (talk) 09:23, 11 January 2018 (UTC)

Your argument fails to take into account direct links to such pages (R#KEEP #2 and #4), which includes links from other websites. People coming from such sites are not helped by the fact that the search does find Wiktionary entries now. As for the idea that they "take up a lot of space", Wikipedia:Don't worry about performance. So far neither you nor anyone else arguing for deletion has explained how WP:NOTDICT applies to links to a dictionary (because the page certainly does not say so) or how the project actually benefits from deletion (which is basically what WP:R#DELETE requires). Regards SoWhy 16:45, 11 January 2018 (UTC)

All right, you got me good. Switching to neutral; I still think "keep all" as is wouldn't improve much. Also, in the light of this event about interwiki results from Wiktionary (which happened weeks after the proposal started), maybe I shouldn't have too much faith in interwiki as good substitute. Better late than never (switching votes), eh? George Ho (talk) 12:29, 24 January 2018 (UTC)

• Keep all, per SoWhy. Those that can be converted to articles certainly should be, but anyone can be BOLD and do that. As for the rest, if we leave these as redlinks, people are persistently going to be driven to recreate them, and it's really not plausible to create-protect 1300+ pages. ♠PMC♠ (talk) 09:57, 11 January 2018 (UTC)
• Keep all until someone can point to several AfDs that have shown a clear consensus to delete individual cases. The purpose of NOTDICTIONARY is to ensure that people don't make fake articles that consist merely of a definition padded with some Google hits—an article needs encyclopedic content about the topic, but the cases being discussed are explicitly not articles. Johnuniq (talk) 21:34, 11 January 2018 (UTC)
• Delete all - per above and WP:NOTDICT. Hummerrocket (talk) 00:41, 12 January 2018 (UTC)
• Keep all. WP:NOTDICT is the reason these redirects exist, not a reason to delete them. The project would not be improved by this; in fact, quite the opposite, as there would suddenly be several hundred odd redlinks, that 1. would no longer be directing people to where they could find the information they want (interesting tip: not everyone uses, or knows how to use, search, so "interwiki searches exist" is not a viable reason either) and 2. acting as bait for people to create content that does fall foul of NOTDICT. Unless it's being suggested that every wiktionary redirect come with a serving of WP:SALT on the former title? In short: this wouldn't improve the encyclopedia, it would in fact harm the encyclopedia and have well-within-reasonable-plausibiity potential for further harm, and would require additional work from editors afterwards. (Also, did someone seriously say delete them because they take up space? DWAP aside, redirects take less server space than deletions do...) - The Bushranger _{One ping only} 07:02, 13 January 2018 (UTC)
• Yeah, I didn't think this would be so evenly split, otherwise I would've chimed in sooner. Of course these should be kept per what Bushranger and others above me have said. Killiondude (talk) 07:07, 13 January 2018 (UTC)
• Keep per The Bushranger. MichaelMaggs (talk) 10:48, 13 January 2018 (UTC)
• Keep. The Bushranger sums it up perfectly, so I won't parrot him and just say I completely agree. Dennis Brown - 2¢ 18:54, 13 January 2018 (UTC)
• Keep all per SoWhy, The Bushranger. These redirects exist because of WP:NOTDICT, not in spite of it. From a practical standpoint, like it or not, there will be people who try and use Wikipedia like a dictionary, and in those cases, we should direct them to Wiktionary, which is the sister project that is actually a dictionary. Having these redirects informs the above people of Wikitionary's existence and prevents them from creating half-assed dic-def pages that Wikipedia would then have to delete. ---- Patar knight - ^chat/_{contributions} 16:32, 17 January 2018 (UTC)
• Keep all per The Bushranger who's put it better than I ever could - These redirects all serve a useful purpose so as such should all be kept. –Davey2010^Talk 16:44, 17 January 2018 (UTC)
• Keep all, per Bushranger mostly. But also because some people might think it's worth linking food items in a sentence like "he had the soupe du jour and a croissant". Headbomb {t · c · p · b} 22:53, 17 January 2018 (UTC)
• Keep per The Bushranger. Ckoerner (talk) 21:00, 18 January 2018 (UTC)
• Keep per Bushranger. Gimubrc (talk) 16:12, 23 January 2018 (UTC)
• Keep per The Bushranger. Deleting the redirects would hinder our readers and lead to the creation of more DICDEF articles. Lepricavark (talk) 15:15, 24 January 2018 (UTC)

Threaded discussion (Cross-wiki redirects to Wiktionary)

There are some 1,300+ cross-wiki redirects to Wiktionary, many of them making use of Template:Wiktionary redirect. Since the default search has been adapted to show results from sister projects (including Wiktionary) when there's no WP page of that title, those redirects don't serve much of a purpose any more. The template was recently nominated for deletion; the discussion resulted in "speedy keep" and a finding that the fate of the redirects should be discussed at the village pump instead. So I'm bringing it here. The only redirects that arguably still serve a purpose are those where the Wiktionary page redirected to doesn't share a name with the WP page with the redirect. So keeping those and only deleting those where target name and origin name are identical is an option. Personally I don't think that's worthwhile. Huon (talk) 00:46, 26 December 2017 (UTC)

• No comments on the merits of this proposal.As the closer of the original TfD, this is the correct venue for such discussions.Regards:)Winged Blades^Godric 08:29, 26 December 2017 (UTC)
• Support this deletion. And yes, a discussion here is the right way to handle these, not a TFD discussion (although a case could be made for a mass-RFD, a discussion here is probably better). עוד מישהו Od Mishehu 10:35, 26 December 2017 (UTC)
• If there is a mass deletion, would links to the deleted pages be changed to wikt links? Or failing that, notification sent to authors/watchers of pages linking to the redirects so that editors can update pages? Nessie (talk) 13:31, 28 December 2017 (UTC)
• What do you all think should be done with a page such as Floccinaucinihilipilification (one of the soft redirects affected by this proposal)? Redlinked, so that people will keep trying to create it? Hard redirect directly to the Wikitionary entry? "Just not have these pages" is an unlikely outcome, since many of these soft redirects are already protected due to repeated re-creation. WhatamIdoing (talk) 19:52, 28 December 2017 (UTC)
• Are we sure that all people likely to end up on such soft redirects come to the soft redirects via the site search? Direct links to Wikipedia pages do exist, as does Google search. Jo-Jo Eumerus (talk, contributions) 10:53, 29 December 2017 (UTC)

Linking

I think the real issue is about linking, where most people will see these pages - should they be linked (they currently are somewhat), or should the wiktionary entry be directly linked, or is it that there is no reason to ever link them (or if there is, there should be an article instead of redirect)? If they shouldn't be linked I think they should be deleted to prevent linking. Galobtter (pingó mió) 10:25, 11 January 2018 (UTC)

I'm unsure whether MOS:LINK and WP:Red link help resolve this situation. I see cute hoor and moonless not used in mainspace pages. Local battery and cocksucker are used by a few pages. Per annum is used by multiple pages. See others at Special:WhatLinksHere/Template:Wiktionary redirect. George Ho (talk) 11:07, 11 January 2018 (UTC)

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

RFC: Feedback on the re-write of the NCORP guideline

There is an RFC open for feedback on the proposed re-write of notability guideline for corporations. The re-write is pretty significant. Your feedback is appreciated on NCORP talk page. Thanks, Renata (talk) 20:39, 28 January 2018 (UTC)

Emergency role account

Resolved

 – Account created. Joe Sutherland (WMF) (talk) 21:47, 23 January 2018 (UTC)

Could a role account be created, in the same vein as User:Oversight, to contact the emergency team? The email address for emergency, visible at Wikipedia:Emergency, could be assigned to the account to make it easy to email via the interface. Conveniently, User:Emergency is not registered. Home Lander (talk) 18:30, 11 January 2018 (UTC)

Attempting to create that account results in it saying "Username entered already in use. Please choose a different name." Emir of Wikipedia (talk) 20:05, 11 January 2018 (UTC)

Image of it at Imgur here https://imgur.com/a/ogwKH --Emir of Wikipedia (talk) 20:07, 11 January 2018 (UTC)

That name is already registered, yes. Jo-Jo Eumerus (talk, contributions) 20:07, 11 January 2018 (UTC)

Suppose there's no chance in hell that that account, since it appears to be a blocked sock on fr (am I correct?), could be renamed to something else to vacate the username? Home Lander (talk) 20:19, 11 January 2018 (UTC)

JSutherland (WMF) might be the one to ask about this (or he would at least know who the correct person to ask is.) TonyBallioni (talk) 20:24, 11 January 2018 (UTC)

I'll shoot him a message. Home Lander (talk) 20:53, 11 January 2018 (UTC)

Why not User:EmergencyContact? It's not registered on any wiki. —Jeremy v^_^v ^Bori! 21:46, 11 January 2018 (UTC)

It would work, it just wouldn't match up exactly with WP:Emergency, like Oversight does. I've already sent JSutherland (WMF) an email as described above. Home Lander (talk) 21:50, 11 January 2018 (UTC)

Received :) This is something we'd need to chat about as a team, though. Joe Sutherland (WMF) (talk) 22:20, 11 January 2018 (UTC)

Yeah, this is something we can ask for but emergency response is done by the back office, so it’s pretty much up to them if they want to do this. Beeblebrox (talk) 22:36, 11 January 2018 (UTC)

Ping Home Lander, et al. – We spoke about this as a team, and have basically come to the conclusion that this isn't something we need to give an okay for. If the community wants for there to be a specific role account for this purpose then we can look into it, though I would probably suggest an RfC or something similar to judge if it's something the community would find useful. Joe Sutherland (WMF) (talk) 20:05, 19 January 2018 (UTC)

Hello again Joe. Sounds like a plan. I have not before opened an RFC, but it seems to me that Wikipedia proposals would be the most appropriate location for something like this? Home Lander (talk) 23:02, 19 January 2018 (UTC)

That seems as good a place as any, it can also be listed at WP:CENT to draw more community input. I’ve done quite a number of RFCs, if you need any further advice/assistance with it let me know. (I’ve also written an essay on the subject but it is more aimed things likely to be controversial, which this hopefully will not be.) Beeblebrox (talk) 00:07, 20 January 2018 (UTC)

@Beeblebrox:  Done here. First time I've done this, so if I've done anything really stupid, feel free to trout me. Home Lander (talk) 00:54, 20 January 2018 (UTC)

Looks fine, I’ve added it to CENT. Beeblebrox (talk) 00:57, 20 January 2018 (UTC)

Pinging Joe and Beeblebrox: Per [4] the RfC is closed. Can we have a foundation member with access to the emergency email being the process of creating this account? Home Lander (talk) 22:01, 21 January 2018 (UTC)

@Home Lander: et al. - this account is now created as User:Emergency. It should be active on all wikis now. Joe Sutherland (WMF) (talk) 21:47, 23 January 2018 (UTC)

Excellent. I went ahead and edited Template:Threat of harm and purged Wikipedia:Responding to threats of harm to include this. Home Lander (talk) 22:14, 23 January 2018 (UTC)

• Late to the party here, but I think a better implementation of this would be to use the Special:Contact extension and phase out the 2004-era solution of role accounts. Special:Contact allows sub-pages, so you could have Special:Contact/Emergency and Special:Contact/Oversight, and allows you to place text above the email box that is specific to the group you are trying to contact. See m:Special:Contact/Stewards for an implementation example. -- Ajraddatz (talk) 10:06, 29 January 2018 (UTC)

• That works on Meta because everybody there has some background knowledge of how MW wikis operate. On en-wiki, the experienced users already know how to email arbcom-l (or whatever) direct; these role accounts are intended to act as landing points for new and new-ish users who don't understand the bureaucracy and jargon, but know enough to grasp the basic "if you want to talk to a Wikipedia user, type 'User:' followed by their name" and consequently end up at User:Arbitration Committee etc. Even if we switched to a contact-based system, the role accounts would still need to continue to exist since realistically the target good-faith-but-inexperienced users will still type User:Oversight, not Special:Contact/Oversight so the role accounts will still need to remain as landing pages. ‑ Iridescent 10:16, 29 January 2018 (UTC)

• That doesn't make much sense. New users are no doubt directed to the role accounts from the relevant policy pages, like WP:OS. They don't think that there is a user named Oversight who happens to action all of those requests. Just change the links and problem solved. You could put a note on User:Oversight linking to the contact form instead of the Special:EmailUser link. I would have no objections to the role accounts continuing to be used concurrently and eventually being phased out. -- Ajraddatz (talk) 10:21, 29 January 2018 (UTC)
  • Note that configuring Special:Contact/Oversight and such requires an account with the appropriate email address set and confirmed, which may as well be the role account. So you could prefer to use the Special:Contact page instead of Special:EmailUser, but you can't really phase out the role account entirely. Anomie⚔ 16:12, 29 January 2018 (UTC)

• Thanks for the technical details. Moving away from Special:EmailUser was my main thing, so keeping the role accounts and changing the links could work. But perhaps that isn't worth the discussion required. -- Ajraddatz (talk) 19:23, 29 January 2018 (UTC)

ecopedia

I would love to see Wikipedia develop a similar resource to help me and others understand the ecological impact of all the decisions I make each week. For example, what is the environmental impact of the manufacture, use and disposal of each of the types of light bulbs, eating beef, eating fish, fertilizing my lawn, etc. etc. — Preceding unsigned comment added by Steve Aram (talk • contribs) 20:43, 5 February 2018 (UTC)

Wikipedia is not designed for this purpose, but there's another site using the same software called Wikia that may be useful for you. --Jayron32 03:37, 6 February 2018 (UTC)

Remove "is disputed" language from NPOV and accuracy cleanup templates

The "is disputed" language in {{POV}} and {{disputed}} is a remnant of 2004-2006, when non-neutral and/or inaccurate content in articles usually caused talk page flame wars. Now that aforementioned flame wars usually no longer happen, I propose that this language be replaced with typical "this article may be..." language (and that {{disputed}} be renamed to {{cleanup-accuracy}}). KMF (talk) 01:15, 24 January 2018 (UTC)

The {{POV}} tag should normally not be present on an article if there is no (more or less active) discussion on the talk page. This is partly just practical (how can I fix the problem if I don't know what problem you found?), but also because we've had too many instances of editors "losing" talk page discussions, and then trying to keep the tag on the article semi-permanently as a sort of "Consensus is against me, but I'm going to 'warn the readers' that at least one editor disagrees with all this stuff about the Earth being round" tag.

(NB that nobody's required to remove a tag that they believe belongs on an article, but if the talk page is empty, or if nobody's mentioned the tag for months, then you're not allowed to edit-war to keep the tag in place. You would normally, however, be allowed to add a quick comment about the problems you see to the talk page and then re-add the tag.)

I understand that {{Disputed}} is supposed to be about verifiability, rather than neutrality. I don't know anything about the history of that template. WhatamIdoing (talk) 21:13, 24 January 2018 (UTC)

• Disagree -- The articles are tagged with T:POV precisely because their neutrality is disputed. The "aforementioned flame wars" of course still do happen. --NaBUru38 (talk) 20:06, 31 January 2018 (UTC)
• Flame wars no longer happen? Where the heck have you been? --Jayron32 03:39, 6 February 2018 (UTC)