Wikipedia:Village pump (proposals)/Archive 149

• 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

RfC: Deletion of drafts

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.

There is a consensus to enact the changes as proposed. Some of the opposition are concerned that this proposal creates a "three strikes" rule for submitted drafts, but the language of the new text does not give a hard number; draft reviewers are encouraged to take heed of the "without any substantial improvement" clause and not nominate simply based on decline count. As a note, none of the sub-proposals made gained any traction or significant support. Primefac (talk) 19:50, 10 June 2018 (UTC)

---

The deletion of drafts via MfD was previously discussed over two years ago in this RfC that concluded that drafts should not be subject to the notability criteria, but that there may be other valid reasons for the deletions of drafts. Reading the comments of the RfC and the close, there also seemed to be agreement that drafts should be works in progress, eventually expected to meet mainspace standards. Currently, it is possible to continually resubmit a declined draft to AfC with no changes while not meeting any of the CSD criteria or failing WP:NOTWEBHOST and effectively stay in draft space forever. This has caused some back and forth at MfD as what to do with these articles. To help provide clarity for this situation, I am proposing WP:NMFD be modified to read the following (updated text in red):

Drafts are not subject to article deletion criteria like "no context" or no indication of notability so creators may have time to establish notability. Drafts may be nominated for deletion at Wikipedia:Miscellany for deletion, but not solely based upon a concern about notability. A draft that has been repeatedly resubmitted and declined at AfC without any substantial improvement may be deleted at Wikipedia:Miscellany for deletion if consensus determines that it is unlikely to ever meet the requirements for mainspace and it otherwise meets one of the reasons for deletion outlined in Wikipedia:Deletion policy.

TonyBallioni (talk) 18:39, 11 May 2018 (UTC)

Drafts RfC Survey

• Support as proposer as it will clarify what has de facto become a delete reason at MfD, deal with cases that will never be G13 or G11 eligible but also have no chance of ever becoming an article, and also provides protection to drafts so that they are still not eligible solely because of notability and requires that they be given more time to develop. This also has the potential to lighten the load on MfD because it would set the standard as repeated resubmissions (read 3 or more times) and would leave the others alone to develop or meet G13. I think this wording is a good way of splitting the baby of protecting drafts from overeager while remembering that at the end of the day, we are ultimately an encyclopedia first and foremost, and that the end goal of the draft space is to build that encyclopedia. Content that doesn't have a chance of meeting that goal shouldn't be kept. TonyBallioni (talk) 18:39, 11 May 2018 (UTC)
• Support. Drafts that are tendentiously resubmitted without improvement are an unnecessary waste of volunteer time and should be deleted. Some submitters evidently have difficulty in understanding the word "no" (let alone "encyclopedia"). Deletion makes that message clear. I'd like to see some article CSDs (A11 in particular) apply to submitted drafts, as the act of submission indicates that the submitter believes their draft should be treated as an article. MER-C 18:54, 11 May 2018 (UTC)
  • User:MER-C, the resubmitters are never told “no”. Have a look at some. —SmokeyJoe (talk) 22:04, 11 May 2018 (UTC)
    • In some sense, yes -- I strongly agree with you that we waste far too much time sending the wrong message to and accommodating those who aren't here to improve Wikipedia. But having a draft declined stating that further improvement is necessary and not doing that before resubmitting is still failing to understand a very simple concept. MER-C 11:57, 12 May 2018 (UTC)
• Support per Mer-C & Tony but is not strong enough. I like Robert's idea of A7 for draft articles.-- Dlohcierekim (talk) 19:00, 11 May 2018 (UTC)
• Oppose As I noted at AN before the thread was closed, resubmitting a draft multiple times is a conduct issue not a content issue and should be handled by sactioning the user in question instead. Once the user has been banned/blocked, the problem posed by the RFC is solved. This proposal would allow a single editor to decline a draft three times and then nominate it for MFD for being declined three times, effectively circumventing the whole reason why we have Draft-space in the first place (which is also why I strongly oppose any attempts to expand A7 to drafts). Regards SoWhy 19:02, 11 May 2018 (UTC)

  SoWhy I would be in complete agreement, except Tony has inserted the phrase "without any substantial improvement". If there is question about what "substantial improvement" here constitutes, an per-case discussion happens at MfD. This is not a "Speedy" process, although I also think there should be such a process for egregious cases. 78.26 _{(spin me / revolutions)} 19:07, 11 May 2018 (UTC)

  I just don't see it as solely a conduct issue. The reason why a draft may be repeatedly declined is because the subject simply isn't suitable for an encyclopedia and has no foreseeable chance at becoming suitable in the future (WP:OVERCOME); that's a valid content issue, if I did hear one. Although it might work, the problem I see with treating it as a behavioral problem is WP:BITE. Threatening to block should be a last resort, and I see deletion as the neatest solution that saves the most time and doesn't unnecessarily personalize the issue for new editors. Mz7 (talk) 00:30, 12 May 2018 (UTC)

  How does deletion stop a user from recreating the same page? BITE problems are a big reason why I don't favor deletion of drafts at all (I see it as a fool's errand to devote energy to pages whose existence does not pose an actual problem in terms of outside visibility) but even BITE has its limits. We block users who don't get the message after being warned multiple times in other areas as well, so how is AFC different? Deleting a page someone has worked hard on is usually as BITEy as blocking them because both send the message that they are not welcome. But only sanctioning the user will actually address the problem posed by Tony. If we agree to sanction users, we could easily create an edit filter that prevents those users from resubmitting drafts (which would be less BITEy than blocking them without being less effective). Regards SoWhy 09:11, 12 May 2018 (UTC)

  Off topic uninformed oppose Vote! on a clarification of policy to match existing practice at MfD from a user with 17 visits to MfD in their last 50,000 edits over a decade. Sanctioning new throwaway accounts is a fools errand and does nothing to remove the bad Draft from the system. Legacypac (talk) 05:18, 12 May 2018 (UTC)

  @Legacypac: An ad hominem argument obscures the points you are trying to make. You should stop attempting to discredit users by who they are or what they've done and instead discredit their points by answering their points directly. --Izno (talk) 12:11, 13 May 2018 (UTC)

• Support - I appreciate the nuance given here to those editors who make good-faith efforts to improve their draft, even if it takes 3 or more or many more attempts. Tendentious resubmissions with no effort to address the concerns of the declining editor, however, should be cause for deletion. Even speedy per Dlohcierekim. 78.26 _{(spin me / revolutions)} 19:03, 11 May 2018 (UTC)
• Support as redundant addition. I don't see the slightest effect that this will have on what we currently have. Also agree with SoWhy. Changed to support. As I already made it clear, I am not against the substance of this proposal but the amount of difference it can make to what currently exists. After TonyBallioni's response, I am convinced supporting this will surely be a one step forward and the impact will (hopefully) be seen in the long-term. –Ammarpad (talk) 19:11, 11 May 2018 (UTC)
  • It makes “repeatedly resubmitted with no improvements, has no chance of being in mainspace, and has no sourcing for uninvolved editors to show notability.” an unambiguously valid reason for deletion at MfD. I think it should be already per NOTWEBHOST. This makes that clear. TonyBallioni (talk) 19:33, 11 May 2018 (UTC)

  @TonyBallioni: I generally agree with the principle of any proposal that will hasten deletion of non-notable drafts that otherwise didn't meet any of our extant WP:GCSD. But I would like to support something that will make impact. Many proposals nowadays are just collection of random support without short term or long term effect. Even now, that this proposal is not in effect, one can nominate non-notable, hopeless and repeatedly submitted draft and it will surely be deleted. But considering your points;

  1. repeatedly resubmitted
  2. with no improvements,
  3. has no chance of being in mainspace, and
  4. has no sourcing for uninvolved editors to show notability

  Shouldn't this be clear need for speedy deletion criterion? If a draft meet all these criteria what else people will discuss? How many people participate in MfD these days? –Ammarpad (talk) 08:18, 12 May 2018 (UTC)

  Hi, Ammarpad, thanks for pinging me. The reason I didn't propose those here is because those would be a lot bigger changes than this, I don't think they have consensus at this time, and I hadn't done any work into looking at what a process there might look like.

  My general approach to policy reform is that policy is meant to be descriptive of practice, not prescriptive. That means I typically only propose RfCs where I think there is a pre-existing consensus. Here, I'd heard enough complaints about how we deal with drafts through MfD, I was aware that previous attempts to get a CSD criterion approved had not been successful, and that draft PROD would be more controversial than this and would probably have a 50/50 chance of passing. I think this proposal addresses a concern that people have, already has consensus, and will improve the encyclopedia as a whole.

  There may be other reform ideas in this area that could be successful, such as Kudpung's suggestion for DfD or yours for Draft PROD. I'd likely support those. That's not the intent of this proposal though. This is an attempt to be a first step in making the process easier by documenting what people already bring up at MfD pretty frequently in policy. If you support the idea generally, like Mz7 below, I hope you'll consider supporting. This doesn't pretend to be the perfect solution, just a viable step forward. TonyBallioni (talk) 12:45, 12 May 2018 (UTC)

  Thanks, TonyBallioni, I now understand you better. Hopefully, although this doesn't mean much now (my concern), it is a stepping stop to something more impactful in the future, instead of ignoring/opposing it now and end up discussing it again at the time we ought to be discussing measures beyond it. –Ammarpad (talk) 07:01, 13 May 2018 (UTC)

  MfD receives reasonably high participation actually; for a CSD you'd need an A7-esque standard, as what counts as "no sourcing" for notability and not suitable for mainspace is contentious Galobtter (pingó mió) 12:52, 12 May 2018 (UTC)

  • Indeed, I think if you look at Wikipedia talk:Miscellany for deletion and its archives, you'll see that the current wording of this section has resulted in a lot of confusion and debate. For that reason, I do not see this clarification as redundant, and if you think it is descriptive of current practice, I think you should consider supporting. Mz7 (talk) 20:15, 11 May 2018 (UTC)

  Yes, I see it as that. That means it will have no solid impact. It merely repeats what already exists. Any draft that meet what was described above will surely be deleted at MfD. See my reply to TonyBallioni above. The current problem as described requires only speedy criterion to make sense and for us to know we're moving forward. Or to a lesser extant, to establish special "sticky prod" for drafts. I will shortly describe it in General comment section. comments below. –Ammarpad (talk) 08:53, 12 May 2018 (UTC)

• Support see User:JJMC89_bot/report/AfC_decline_counts where drafts are declined as many as 11 times! It is a serious waste of effort and gums up AfC. This can help the actually notable draft stuck in AfC as well because it will expose the page to a discussion where someone can make a case for promotion, but mostly it will provide an exit path for the hopeless repeated reviewer free spin of the wheel style resubmissions. I also support applying A style CSDs to submitted drafts. The act of submission is a request to apply mainspace criteria to the page so treat the page as such. Legacypac (talk) 19:10, 11 May 2018 (UTC)
• Support Why should notability not be considered for drafts? The point of drafts is to develop into articles, and articles require notability. What then is the purpose of allowing drafts on non-notable subjects? Natureium (talk) 19:23, 11 May 2018 (UTC)
• Oppose - We should not be spending time in deletion discussions about drafts. These discussions and administrative actions take unnecessary resources, are WP:BITEY, and feed trolls. Please let these submissions wait their turn in the queue for a few weeks before rejecting them. Authors will get the message and the drafts will eventually be deleted under G13. ~Kvng (talk) 19:37, 11 May 2018 (UTC)
• Oppose, per Kvng. This proposal comes across as a punitive measure, too. --Doncram (talk) 19:52, 11 May 2018 (UTC)
  • The other working proposal to deal with this is to block them and let G13 take hold. I consider that much more bitey and puntative. TonyBallioni (talk) 19:56, 11 May 2018 (UTC)
  • @TonyBallioni: I proposed above that we basically put these drafts in timeout. Can we put that on the table too? No change to process is required, just a change to reviewer behavior. ~Kvng (talk) 00:41, 12 May 2018 (UTC)
    • I'm not really sure if there is a way to prevent them from submitting the AfC draft. I'm also not sure what good it does to keep them for 6 extra months if we've already made the determination we don't want them. If the main reason is BITE, I'll somewhat echo Seraphimblade below in noting that most of these are not actually good faith users who are trying to contribute something encyclopedic that they find interesting to Wikipedia. Most of these are people who have a financial incentive to keep resubmitting and take advantage of our good faith. I'm not sure BITE is really a good argument in dealing with people we don't want contributing anyway. TonyBallioni (talk) 01:12, 12 May 2018 (UTC)
• Support Oppose arguments such Kvng's are admirable in their assumption of good faith, but practical AfC data shows that there are far too many bad-faith article creators. This reality is the reason that we have made ACTRIAL permanent, after all. The proposed language is a common-sense way to address bad-faith resubmitters. The difference between good-faith and bad-faith article creators is often disclosed by their response to AfC rejection. The former will at least query the rejection and its feedback, while the latter will just send the exact same article back into the queue. This proposal only targets the latter behavior, something that should be dissuaded in any event. Eggishorn (talk) (contrib) 19:57, 11 May 2018 (UTC)
  • @Eggishorn: Can you provide some details about this "practical AfC data"? ~Kvng (talk) 00:41, 12 May 2018 (UTC)

@Kvng:, I suggest starting with the meta:Research:Autoconfirmed_article_creation_trial and wp:Autoconfirmed article creation trial/Post-trial Research Report. Eggishorn (talk) (contrib) 04:29, 12 May 2018 (UTC)

@Eggishorn: I've read those and they don't support what you're saying here. There is nothing in the report about draft author behavior. Also the WMF is only now gaining an understanding of how AfC works. The AfC-related conclusions in the report are disputed. There were more submissions to AfC but there is no evidence there was a "struggle" to keep up with it. See Wikipedia_talk:Autoconfirmed_article_creation_trial/Post-trial_Research_Report#AfC_backlog_"struggle". ~Kvng (talk) 14:38, 12 May 2018 (UTC)

• (edit conflict) Support – It is true that in the wide majority of cases, the notability guidelines that justify the deletion of articles do not automatically justify the deletion of drafts. This is because one of the purposes of the draft space is to serve as an incubator for drafts about non-notable subjects that have a high likelihood of becoming notable in the near future (e.g. film actors who are about to star in a significant role, upcoming films from major studios, athletes who are about to debut in the top tier of their sport). The draft space is the successor to Wikipedia:Article Incubator in this respect. Articles that were in the incubator did not stay there forever, however; they either were moved back to mainspace or were nominated to MFD or userfied (see WP:GRADUATE).
  I've long held the view that there are two general cases where notability should and does factor in as a part of a decision to delete a draft (see this July 2017 discussion). The first is repeatedly submitted AfC drafts with no foreseeable chance at acceptance due to lack of notability, and the second is long-abandoned non-AFC drafts about non-notable subjects with no foreseeable chance at becoming notable in the future. The second case has largely been mitigated with the expansion of CAT:G13 to all drafts, but I see MfD as the natural place where repeatedly submitted AfC drafts should be sent. I don't see blocking or other conduct sanctions as the best solution because the issue is indeed fundamentally with the subject of the article: no amount of editing can overcome a lack of notability. Mz7 (talk) 20:06, 11 May 2018 (UTC)
• Oppose for a few reasons, although mostly this is just echoing SoWhy. First, AfC doesn't own the entire Draft namespace, so constant submission is a project problem. In that case, I think SoWhy's response (i.e., it becomes a behavior/cluefulness issue) is appropriate. Second, the purpose of draftspace is for folks to work on pages that are inappropriate for mainspace; this would defeat the whole purpose of treating something as a "draft" rather than an article. I've said elsewhere that I am unconvinced of the damage or harm a large draftspace would supposedly cause, and that remains true. Finally, I think the proposed text weakens WP:NMFD to a degree that it will cease to be a barrier. ~ Amory (u • t • c) 20:34, 11 May 2018 (UTC)

Sure, AfC doesn't own the draft namespace, Amorymeltzer, but it was created with them in mind and with the hope that ACTRIAL would take place one of the days. Well, ACTRIAL took place, and has since become ACREQ and there has been the anticipated (but slightly lower than feared) increase in the number of drafts. Nevertheless, SoWhy's argument (i.e., it becomes a behavior/cluefulness issue) is indeed also appropriate, because the reviewing needs to be much improved so that even if they have clue, they will be singing from the same page of the same hymn book, and at the moment they do not appear to be doing either. And that's a much longer story. Kudpung กุดผึ้ง (talk) 20:48, 11 May 2018 (UTC)

I would qualify your description of the purpose of the draft space in this way: the purpose of the draft space is for folks to work on pages that are inappropriate for mainspace but will soon be appropriate for mainspace. The draft space is not a dumping ground for articles about just any topic that doesn't meet mainspace standards to remain indefinitely – that would be using Wikipedia as a web host. We expect drafts to be actively worked on and improved so that they will eventually be a part of the encyclopedia. If a draft is about a topic that is inherently non-notable and has no foreseeable chance at becoming notable in the future, then more community time is wasted when we allow it to be repeatedly submitted at AfC than if we allow it to be deleted at MFD. Fundamentally, it is not just a conduct issue, but an issue with the subject of the draft. If the real solution is to threaten to block a user if they don't stop submitting, and let it be deleted after waiting out 6 months via G13, then isn't that WP:BITEy and perhaps even more time wasting than if we just waited out 7 days at MfD? Mz7 (talk) 23:59, 11 May 2018 (UTC)

• (edit conflict)(edit conflict) Support strongly - in fact I would go one further and suggest the creation of DfD - Drafts for Deletion. Since ACREQ was rolled out, there are going to be a lot more drafts for deletion. As one of the editors who works a lot in these areas I prefer pragmatic solutions rather than philosophical ones. Being BITEY is not part of the equation , telling a troll his trash is not wanted is not being bitey, nor is telling an obvious paid editor that Wikipedia was not conceived as a platform for blatently making a career from making money out of our volunteer-created encyclopedia; Wikipedia is not a business directory either or a register for rappers. What is really needed are a better set of instructions (without TL:DR, but more than just a quick click-through of four four-line pages) at the Article Wizard, and more consistent reviewing at AfC; and above all, more truly active AfC reviewers Kudpung กุดผึ้ง (talk) 20:35, 11 May 2018 (UTC)

@Kudpung: I would say, personally, I would like a DfD system, but I've heard arguments that it won't have nearly enough traffic to work properly. Jjjjjjdddddd (talk) 03:45, 12 May 2018 (UTC)

• User:Kudpung, User:Jjjjjjdddddd - I am genuinely puzzled by the idea of Drafts for Deletion. My question is why drafts need a separate deletion process from MFD, especially since MFD is primarily used for drafts anyway. Why do drafts require their own deletion process? Why not do at MFD whatever would be done at DFD? I hope that this isn't considered a stupid question, but I really don't understand why a new process would solve the known problems with cruddy drafts. Robert McClenon (talk) 23:12, 12 May 2018 (UTC)

• Support In my experience, G13 is just not good enough to deal with this issue. Drafts that are truely not notable, which are just cruft should be able to be deleted rather than going after x months of no edits and instantly undeletable. Additionally, at MfD/DfD/whatever it is called, there will be the chance for more people to look over nominations than one reviewer every few weeks. While I'm an advocate for a more engagement-based approach on paid editing, in cases where companies are non-notable, we do need to be less wishy-washy on the message we send out. Mdann52 (talk) 20:54, 11 May 2018 (UTC)
• Support but I like Kudpungs idea a lot - Having "DFD" would be a much better place for all of these as IMHO Drafts are unrelated to MFD, Anyway support this proposal. –Davey2010^Talk 21:05, 11 May 2018 (UTC)
• Support (edit conflict) - I understand SoWhy's concern but I think that if the article is undergoing substantial improvements there is no concern with this affecting the draft. -- Dane ^talk 21:07, 11 May 2018 (UTC)
• Support - this is a step in the right direction, although it is still insufficient. Blatantly non-notable drafts (one where no reasonable editor can make a case for notability) should be eligible for deletion either as a speedy or through a XfD process without the need to show anything else. Endorse Kudpung's DfD process. Tazerdadog (talk) 21:18, 11 May 2018 (UTC)
• In-the-end Support but not yet, not when the resubmissions followed a face reading of the saccharine decline template that encourages the author to edit improve and, with a big blue box, “resubmit”. The template confuses the newcomers who think this is how to communicate. The root fault lies with the AfC template and this deletion process does nothing to address it. Support for resubmissions that follow removal of the saccharine resubmit template only. —SmokeyJoe (talk) 21:34, 11 May 2018 (UTC)

The prerequisites to precede are (1) Wikipedia_talk:Criteria_for_speedy_deletion#Applying_A*_criteria_to_submitted_drafts and (2) fixing the AfC practice of the confusing rejection template. —SmokeyJoe (talk) 21:39, 11 May 2018 (UTC)

• Support. I also wouldn't mind having a Drafts-for-Deletion notice board, but would prefer to save DFD for a Disambiguations for Discussions notice board. Also, if we are going to separate drafts from MfD, we should create a master deletion noticeboard where editors can see all discussions going on at AfD, MfD, CfD, RfD, and any others that are made. bd2412 T 21:42, 11 May 2018 (UTC)

DAB pages are dealt with at MfD. They may need to be deleted occasionally, but rarely for the reasons that junk that is received at AfC needs to specially treated. Kudpung กุดผึ้ง (talk) 22:06, 11 May 2018 (UTC)

Actually, DAB pages are usually dealt with at AfD - if the issue is deletion. More importantly, however, there are a number of non-deletion issues for which disambiguation pages require a central noticeboard, including move requests, and proposals to change an existing article or redirect to a disambiguation page (or to turn an existing disambiguation page into an article). bd2412 T 22:19, 11 May 2018 (UTC)

DAB pages are never dealt with at MfD but are immediately referred to AfD. DAB discussions would be better as RM discussions on the DAB talk page, except if an outcome is deletion the discussion would be deleted. —SmokeyJoe (talk) 22:25, 11 May 2018 (UTC)

In that case you'd better send this to RfD ;) Kudpung กุดผึ้ง (talk) 22:53, 11 May 2018 (UTC)

With four incoming links, and before today an average of less than one view per ten days, rfding it would be busywork. —SmokeyJoe (talk) 03:39, 12 May 2018 (UTC)

• Oppose per Kvng and SoWhy. I don't agree with deleting drafts that are declined multiple times after many resubmissions since it may come off as WP:BITEY and completely unnecessary. Just undo/revert the submitter to solve the issue easily instead of MFD-ing which is a waste of time or reviewers should just leave them alone for a few weeks before declining since no one outside the community cares about the draft space and keeping the drafts around will not be detrimental to WP. What is already written is sufficient and the proposed addition could actually make it more confusing rather than give clarity. KingAndGod 22:02, 11 May 2018 (UTC)

  You are free to vote bow you like but basing your vote on the reasoning of an editor with no AfC and extremely limited MfD experience is less convincing. Legacypac (talk) 08:01, 13 May 2018 (UTC)

  @Legacypac: See above your comment to SoWhy re ad hominem. --Izno (talk) 12:13, 13 May 2018 (UTC)

• Support, absolutely, per Tony. Volunteer time is our most precious resource; we should not be forcing wasting it on reviewing and declining drafts that are tendentiously resubmitted by people not acting in good faith. ♠PMC♠ (talk) 23:37, 11 May 2018 (UTC)
• Oppose - Resubmitting the same draft over and over is a behavioral issue. Deal with the user. If it's a recurring problem, disallow it via AfC processes. If AfC allows resubmitting the same draft over and over again, don't defer to another process to fix it by deletion. — Rhododendrites ^talk \\ 23:53, 11 May 2018 (UTC)

Sanctioning new throwaway SPA accounts does not solve much. MfD is no more a seperate process from Draft space than AfD is a seperate process for Mainspace. I am unaware of any way to prevent someone from adding the AfC submit code to any page other than to block them. Legacypac (talk) 05:18, 12 May 2018 (UTC)

• Support, draft space should be used for things for which there's a reasonable likelihood that they can one day be an article. It should not be a dumping ground for people to write about their pet dog, nor (and I've seen this tried on multiple occasions) for an undisclosed spammer to see just how much promotional language they can get away with by making small changes and resubmitting. We either need this, or a "______ strikes, you're out" speedy criterion. At some point, repeated failed resubmissions indicate that either the author is not acting in good faith, or lacks the competence to write an article. In either case, there comes a point at which we need to say we've spent enough time on it. Seraphimblade ^{Talk to me} 00:02, 12 May 2018 (UTC)
• Support – this is a no-brainer: this is an encyclopedia devoted to articles on notable subjects – if a draft has been determined to insufficently notable at something like AfC multiple times, and is unlikely to ever be notable, it does not belong as part of this project, even in Draftspace. WP:NOTAWEBHOST. --IJBall (contribs • talk) 01:16, 12 May 2018 (UTC)
• Support - While I understand the good faith aspect here, and indeed whenever possible, if a draft has potential to become an article, they should be kept as long as they're being worked on. But unfortunately, there are many drafts on subjects that simply would be deleted quickly if they were an article. It would be better to put them out of their misery quickly as opposed to keeping them in the limbo of waiting for them to become G13 eligible. This is especially with ACTRIAL becoming permanent after all. With that said, perhaps MfD would be a better compromise as opposed to extending certain CSD criteria to drafts, since many drafts are still potential articles, and it's necessary to see which is workable and which needs to go. Narutolovehinata5 ^tccsdnew 01:48, 12 May 2018 (UTC)
• Support Most people that repeatedly submit the same bad submission are either not acting in good faith, or are ignoring the decline reason. AfC is already heavily backlogged as it is, and besides, the MfD discussion will either have the bad-faith trash deleted, or give the (presumably somewhat good-faith) submitter a push to improve their draft. Jjjjjjdddddd (talk) 03:58, 12 May 2018 (UTC)
• Support. We are WP:NOTWEBHOST for material unsuited to our project. Sandstein 07:46, 12 May 2018 (UTC)
• Support this seems reasonable, it allows for people to try to bring a draft up to acceptable standards without turning draftspace into a webhost for pages which will never become articles. Hut 8.5 10:05, 12 May 2018 (UTC)
• Support per Hut 8.5. This doesn't stop people from using user space for longer term storage, but it does give us the appropriate tool to deal with the few drafts that need to be cleaned up. Dennis Brown - 2¢ 10:08, 12 May 2018 (UTC)
• Oppose This proposal makes a very bold assumption: that AFC reviewers are infallible and that if a draft has been rejected by them three times then "obviously" the draft must be worthless. the problems with AFC's lack of accountability have been discussed many times on Wikipedia and I fail to see how this does anything bu increase the lack of accountability.

  AFC reviewers are declining articles for incredibly petty reasons like not formatting a reference correctly, or "this looks notable, but can you make the article perfect", or the most obnoxious, which is the dreaded copy-pasted boilerplates that say the draft is not good, but do nothing to advise the draftee on how to improve it.

  Something many older reviewers don't realise is that new users are corralled into AFC. AFC is not mandatory for creating a page, but if you are a new user, the instructions you receive to everything to convince you that the only way to create a new page is to make a draft and submit it for review. This has given the reviewers of AFC an incredible amount of power, in a way that goes against the entire spirit of the Wiki (Collaboration). Many AFC reviewers instead of looking to improve articles, have appointed themselves unilateral quality editors and continually reject drafts that AFD would never delete. This proposal seeks to increase the power of AFC editors, but I suggest that this is a solution to a problem that doesn't exist. Egaoblai (talk) 10:23, 12 May 2018 (UTC)

Egaoblai this isn't a CSD so they aren't automatically deemed worthless. Having an MfD for those drafts declined spuriously means that they'll get attention from multiple editors and more accountability and an accept in those cases where the declines are spurious Galobtter (pingó mió) 12:13, 12 May 2018 (UTC)

At MfD we can discuss and save if the AfC reviewers are wrong Legacypac (talk) 08:01, 13 May 2018 (UTC)

I agree with your concerns Egaoblai but a timely MfD is likely to be an improvement on the draft ageing out and being quietly deleted G13 after 6 months. Espresso Addict (talk) 00:26, 15 May 2018 (UTC)

• Support. I see this as a genuine problem and this seems like a practical way to solve it. WP:MFD will get extra eyes on them in case there's a consensus that the AFC reviewers have erred, and there's always WP:DRV as a backup as with other deletion processes. Boing! said Zebedee (talk) 10:26, 12 May 2018 (UTC)
• Support per Tony and Mer-C; blocking the accounts is hard to do when they are likely in good faith etc; you'd need first need to leave specific warnings rather than encouraging AfC messages and it is basically much more effort overall. Galobtter (pingó mió) 12:52, 12 May 2018 (UTC)
• Support - this seems like a measured solution to the problem. Richard⁰⁶¹² 13:47, 12 May 2018 (UTC)
• Oppose Per WP:NOTPAPER, there is no physical limit requiring deletion. If resubmission is an issue, it is better to retain drafts as a record of previous versions. If you start deleting versions, then further submissions will seem to be starting afresh, so causing the process to loop indefinitely. So, just as we keep our discussions and archives indefinitely, we should keep draft versions too. If they don't seem to be going anywhere, then use a category or other tag to mark their status. Andrew D. (talk) 21:23, 12 May 2018 (UTC)
• Measured oppose "Repeatedly" is an interesting word, and the criterion should not be "repeatedly" but "repeatedly without prospective changes in notability" - that is, we ought to avoid burning up a draft where the notability of the topic or person has a decent chance of being altered substantially. Collect (talk) 21:29, 12 May 2018 (UTC)

if that is true for a draft that can be discussed at MfD. Legacypac (talk) 08:01, 13 May 2018 (UTC)

• Support - a measured proposal that doesn't try to go too far. — Insertcleverphrasehere ^{(or here)} 23:04, 12 May 2018 (UTC)
• Support - Something needs to be done about tendentious resubmission. Either the drafts can be deleted, or the resubmitters can be blocked, or both. Something needs to be done. I don't see a practical way to request that the fools and flacks be blocked, because WP:ANI isn't worth the drama and will probably wind up with a warning anyway, and they aren't vandals. I don't think it goes far enough, but it is better than nothing. I would like to be able to speedy drafts that have no credible claim of significance, but I know that I am in the minority there. Robert McClenon (talk) 23:28, 12 May 2018 (UTC)
• Oppose - The issue of a draft being submitted too many times would be better addressed at Wikipedia:Articles for creation/Wikipedia:WikiProject Articles for creation. For example, a process of barring a draft from resubmission for a certain period of time or barring a user from submitting draft(s) to be considered for a certain period of time could be established. Let the AfC process govern itself; the problem should not be thrust directly on MfD. If AfC establishes a guideline that such drafts should be deleted (as opposed to my examples above which I believe are better options), they can cite it at MfD. WP:NMFD is not the place for such guidance to reside. All drafts inducted into the AfC process become eligible for speedy deletion per G13 after 6 months of inactivity anyhow, so I fail to see the necessity of early deletion. — Godsy ^(TALK_CONT) 00:21, 13 May 2018 (UTC)

If they get repeatedly resubmitted they never get to G13 Galobtter (pingó mió) 06:35, 13 May 2018 (UTC)

• Support - per User:Robert McClenon Smallbones_(smalltalk) 15:09, 13 May 2018 (UTC)
• Support a separate "drafts for discussion" page, as well as a CSD for drafts that have been declined more than 3 times without any plausible improvement. Lojbanist ^{remove cattle from stage} 19:07, 13 May 2018 (UTC)
• Support a working solution to a real problem of NOTWEBHOST content that otherwise falls between the cracks. – Finnusertop (talk ⋅ contribs) 22:42, 13 May 2018 (UTC)
• Support just formalizing my own personal view. If the same submission gets repeatedly submitted without correcting the problem I go from friendly to not-so-friendly in my comments with the last comment being to the effect of Do not resubmit this without correcting the issues already raised otherwise I will nominate this for deletion at MFD. It doesn't threaten the user directly, it simply explains what the consequence of them failing to read/understand/correct will be. Hasteur (talk) 01:38, 14 May 2018 (UTC)
• Oppose per SoWhy and Amory. Besides, draftspace is exactly the place to put not-article-worthy-yet drafts. This would defeat the whole purpose of it. Besides, there are some AfC reviewers that will acept draft with lower standards, while others will wait for them to be GA-class to accept them. L293D (☎ • ✎) 02:24, 14 May 2018 (UTC)
• Support, but only under a specific set of criteria. I agree that drafts that aren't likely to go anywhere need to be shown the door, but I'm not sure just doing it by MfD'ing everything that gets power-submitted is the way. I'd actually think a valid case could be made for drafts that fit all of the following criteria:
  1. The draft has been rejected at least five times, or has been resubmitted and rejected with no substantial edits to it three times. If someone is working on a draft and at least trying to make it work out, the likelihood of it getting rejected five times is slim to nil. On the other hand, someone who's just spamming the submit button is likely doing it for Google exposure, not to build an encyclopaedia.
  2. The draft's sources are unacceptable, and no acceptable sources are available online or off. Oftentimes the biggest hurdle to a draft is finding usable third-party sources, and newer users are less likely to understand what we deem acceptable. I would also suggest amending the decline message for lack of notability to include a link to a plain explanation of acceptable sources (which I'll probably dope up soon, since this is almost universally THE main sticking point as far as helpees in -en-help go).
  3. The draft, in addition to the above, has not been (substantially) edited for at least three months since the last decline or edit. Given that the usual backlog for AfC at present is in the neighbourhood of months (as an acknowledged consequence of ACTRIAL and ACPERM) this gives time for sources to come into existence and thus subvert the second bullet above. This is also why a WP:BEFORE check must be done before a draft gets taken to MfD. While I suggest three months (as a fair chunk of drafts are made in anticipation of a topic) this should be considered a suggestion and not a hard-and-fast rule, but it should be no less than ten weeks and no more than 6 months (when G13 kicks in anyways). —Jeremy v^_^v ^Bori! 03:30, 14 May 2018 (UTC)
• Support - This is not an area where I have a great deal of experience, but it seems to me that the "support" !votes present better arguments than do the "oppose" !votes. Having no strong personal reason to oppose, and trusting in TonyB's judgment, I support. Beyond My Ken (talk) 03:54, 14 May 2018 (UTC)
• Support – Regardless of whether resubmitting a draft repeatedly is a behavioural issue as some argue it should be treated as, this will make it easier to get rid of problem drafts via MfD. If it is a substantive draft that is actually worth keeping, MfD will see it as such. Draftspace has been a mess for a while, and the problem isn't with the potentially publishable drafts; it's with the repeatedly resubmitted corporate spam and self-published non-notable bios. I don't see the issue here. Kb.au (talk) 14:39, 14 May 2018 (UTC)
• Support - I will ask a going further, for those where consensus is at MFD that there is no clear case at mainspace WP:SNOW - then admins should be able to SALT the page. I have been seeing people recreating their useless drafts and then repeatedly recreating. Banning individual users may be in need, but we need warnings, final warnings and etc. And the user maybe able to contribute in other areas, so sometime can't ban also. Therefore, to solve the content issue, SALT the page. --Quek157 (talk) 21:16, 14 May 2018 (UTC)

• G4 is applicable if they blindly re-create it after an XfD debate without fixing any of its issues. We shouldn't salt the earth unless and until they prove themselves unwilling or incapable of listening to criticism of their article by repeatedly growing a new one from the ashes. —Jeremy v^_^v ^Bori! 19:18, 15 May 2018 (UTC)
• @Jéské Couriano:, I declined a draft with 2 - 3 can't remember previous deletion, CSD G11 (Advertising) with G4 (SALT). The admin who process initially did G4, but then said "unnecessary for draft" so then reallow creation for G4. G4 can only be used for mainspace, not draftspace, I am thinking to extend it to here. --Quek157 (talk) 21:20, 15 May 2018 (UTC)

"It excludes pages that are not substantially identical to the deleted version, pages to which the reason for the deletion no longer applies, and content that has been moved to user space or converted to a draft for explicit improvement (but not simply to circumvent Wikipedia's deletion policy). This criterion also does not cover content undeleted via a deletion review, or that was only deleted via proposed deletion (including deletion discussions closed as "soft delete") or speedy deletion."(emphasis in italics). This is the big problem NOW at the draftspace which is this entire RfC is for. It is quite protected and is not like others. I just came back after a long hiatus and apparently it is now like that, FYI too =) --Quek157 (talk) 21:25, 15 May 2018 (UTC)

• Support- I'd personally go further, in terms of Notability as a criterion, but the proposal would certainly be an improvement on the current position. KJP1 (talk) 05:39, 15 May 2018 (UTC)
• Support. I do think that this would address a need. What makes it work for me is that it is directed at drafts that keep getting resubmitted without "getting the message", and that it makes it possible to decide that a draft should be deleted, as opposed to saying that a draft must be deleted. In other words, it still leaves discussion and editorial judgment in place. --Tryptofish (talk) 19:25, 15 May 2018 (UTC)
• Support. This is already how discussions at MfD are turning out: the community (or, at least, the portion of the community that regularly votes at MfD) feels that it is appropriate to delete tendentious resubmissions that utterly fail to address the reasons for their rejection as a way of communicating to the user that their disruption won't be tolerated without going to the extreme of bans or blocks. —Compassionate727 ^(T·C) 21:18, 15 May 2018 (UTC)
• Support. Anything not in one of the "normal" namespaces can already be nominated for MFD, and any such page will be deleted if consensus favor deletion. This isn't adding any new ideas or procedures to policy; it's simply saying what's already happening. WP:PPP. Nyttend (talk) 11:29, 16 May 2018 (UTC)
• Support, also support Drafts for Deletion. Having drafts with no hope of becoming articles is helpful to no one; having a dedicated drafts for deletion space will allow people specializing in drafts to watch it, as shepherding a draft into an article is a skill. --GRuban (talk) 20:30, 16 May 2018 (UTC)
• Support per Kudpung. Amorymeltzer is exactly wrong; draft space only exists as the location for AfC's backlog. SoWhy is correct insofar as problem editors are behind the repeated submissions. Because these drafts are of interest to businesses or fan collectives where meatpuppetry or sockpuppetry is likely, deleting the draft is a more efficient practice. Chris Troutman (talk) 16:44, 20 May 2018 (UTC)
• Support: no chance of ever becoming an article & tendentious resubmissions which take up volunteer time. This is a suitable approach to addressing the issue. K.e.coffman (talk) 01:30, 22 May 2018 (UTC)
• Support: well, a decision should be taken based on a statistic (in available). I agree that if a draft gets declined 3 times (ofthen for the same reason) further resubmissions for AfC is just time wasting. I believe that if a WP:RENOM style policy would be implemented for drafts would be a good step forward. We all know that a new editor, not familiarised with all the policies needs some time to know that there are some fair rules. So a time frame to improve an entry between two resubmissions would be a viable solution as well. However, if the draft keeps getting declined by different reviewes several times during, let's say, 6 months or a year... we all know what that means. As a NPP reviewer and page mover - sometimes, when I felt like an article has potential - I draftified those articles and some of then giving advice to its creator how to improve the draft. Robertgombos (talk) 23:07, 24 May 2018 (UTC)
• Oppose This feels like we are trying to make a crystal ball to predict if a subject will become notable or not. I do not agree with the wording and what it can imply. I could get on board for an "abandoned" guideline, that any draft that has not been improved in X amount of days is deleted or userfied.--Paul McDonald (talk) 23:17, 24 May 2018 (UTC)
• Support per Tony and K.e.coffman. Could not have said it better myself. JTP ^{(talk • contribs)} 15:41, 31 May 2018 (UTC)
• Support IF ANSWERED - it is codified how much and how frequently is going to trip the tendentious resubmissions bit. I'd like just being able to userfy etc, but if those who endlessly resubmit would presumably do the same in AfC.

TonyBallioni the latter part of your proposal "otherwise meets one of the reasons for deletion". AfC pass requirements are stricter than those for an article to remain. Most notably on issues such as verification (AfD can be stopped by sheer possibility of finding sources) and promo levels (AfD articles have to be completely promo). Would a strict following of this proposal not risk us having a group of articles that would continually fail AfC but not be deleted under WP:DEL-REASON? Nosebagbear (talk) 14:54, 6 June 2018 (UTC)

I'm obviously not Tony, but I would imagine that in such a case if an MfD is closed as keep, then the article fails AfC again or just sits there for a while, then that very fact can be used as an argument to delete at a second MfD. And, of course, if the draft is left unedited for 6 months then it'll get G13'd. ƒirefly ( t · c · who? ) 09:34, 7 June 2018 (UTC)

Nosebagbear, sorry for the late response. AfC's acceptance criteria is "is likely to survive AfD", which means they are substantially lower than the mainspace requirements. Also, if the reviewer has made mistakes, MfD will likely suggest booting it to mainspace with no prejudice against sending to AfD. TonyBallioni (talk) 14:21, 7 June 2018 (UTC)

• Support per above. Seems sensible, and already appears to be the case at MfD anyways. -FASTILY 23:05, 7 June 2018 (UTC)

Drafts Discussion

TBD, the whole Draft system itself, should be abolished. IMHO, it's best to let an editor create an article as a stub, then let the community gradually evolve that article. Meanwhile, individual editors can use their own sandbox to construct what they want to put into an article created by themselves or somebody else. The Draft system is just an extra layer, for editors to fight over. GoodDay (talk) 19:17, 11 May 2018 (UTC)

I do not think that is an appropriate suggestion at all. Coming from a user who has a very high count of minor edits and not in the areas under discussion here, I wonder on what experience you actually base your comment. Kudpung กุดผึ้ง (talk) 20:59, 11 May 2018 (UTC)

Up until a few weeks ago, there were quite a few Draft-related disputes concerning behavior being brought to ANI. This wouldn't have occurred, if there were no Draft system. GoodDay (talk) 21:20, 11 May 2018 (UTC)

'Quite a few' is quantitively subjective. I'm no friend of statistics where concrete empirical evidence exists, but I would like to see that claim supported by some numbers. Are you an admin? Do you frequent ANI regularly? I do. Those issues would probably have been brought to ANI under some other reason. — Preceding unsigned comment added by Kudpung (talk • contribs)

Abolish the Draft system & the community just might be happier for it. GoodDay (talk) 22:17, 11 May 2018 (UTC)

Heh, I remember the days when AfC drafts were stored in the "Wikipedia talk" namespace because the draft namespace just did not exist. Let us not return to those days. Mz7 (talk) 09:56, 12 May 2018 (UTC)

Re: "Up until a few weeks ago, there were quite a few Draft-related disputes concerning behavior being brought to ANI. This wouldn't have occurred, if there were no Draft system." On those grounds, if we abolish article space we'll have no article concerns brought to ANI, and if we abolish User space we'll have no User space concerns... perhaps we should just abolish Wikipedia? Boing! said Zebedee (talk) 10:35, 12 May 2018 (UTC)

• Comment - the interpretation of the RfC that "notability criteria don't apply to draft space" continues to be tone-deaf, overly simplistic, and harmful. Of course drafts should be on notable topics; anything else fails WP:NOTWEBHOST. Deciding which is which is a task for MfD (or perhaps drafts should be handled at AfD since they're supposed to be articles) but just setting another completely arbitrary draft working limit (like "six months") is not going to do anything to address the problems identified by this proposal (which are real problems which should be addressed). It's just inviting fights about what constitutes meaningful improvement. Ivanvector (^Talk/_Edits) 19:20, 11 May 2018 (UTC)

(edit conflict) I also endorse GoodDay's comment. Ivanvector (^Talk/_Edits) 19:20, 11 May 2018 (UTC)

I agree but 1) I never propose RfCs that I don’t think have pre-existing consensus, and I think making N apply to all drafts at the beginning doesn’t have a chance of passing. 2) This actually expands the force of N to drafts more than it is now, while still shielding them from the brunt of it initially. It can’t be the sole reason for deletion, but a repeatedly deleted draft that fails the notability criteria and doesn’t have a chance of being in mainspace. TonyBallioni (talk) 19:30, 11 May 2018 (UTC)

I just think the implementation of the RfC has been very poorly done; I get the intent, but, ugh. The notion that the draft space should be an incubating space for content intended to form part of an article, and not a junk space to hold whatever bits of writing anyone wants to drop there, seems to be a minority opinion. It's absurd to me that we allow editors to post basically anything they want in draft space, like the thousands of drafts that are nothing more than SEO listings for entirely non-notable businesses. We keep telling the authors of these articles that they "don't demonstrate notability" but our AfC messages encourage them to try again by adding more references, as though we'll decide to accept their article that's just a list of directors of their tech startup if they just pay for enough copies of their own press release, and so of course they resubmit over and over again with no meaningful improvement. There's no meaningful improvement to be made, the topic is not notable. We should empower our AfC reviewers to just come out with it and say, "this isn't notable" and punt the drafts to MfD immediately. And we can word that response as gently as we need to, we've been rejecting and deleting articles on non-notable topics for, oh, 17 years now? But if everyone who's been here a month can see that a draft on a non-notable topic is going to end up being deleted, is it more bitey to string an editor along for months and possibly years with messages telling them they just need to improve the draft a bit more before it can be an article when it never will be, or just delete it outright and say "thanks, but no"? I realize I'm ranting here and I'm probably not even really addressing the proposal at this point, but if anyone wants to really consider this, my talk page is probably a good place to respond.

Tony, to reply to your comment more briefly, a draft that doesn't have a chance of being in mainspace shouldn't need to be repeatedly [declined] before we pull the plug and delete it. In my opinion we should be able to make that determination much earlier in the process. To GoodDay's point, when a draft is reviewed we should be able to determine its article-worthiness on the first go-round, and either promote it or delete it. If it's notable but poor quality, promote it and let the usual community improvement process proceed. If it's not notable, delete it. Somehow AfC has evolved into a highly arbitrary quality pre-screening process, and I'm pretty sure that was never the intent. Ivanvector (^Talk/_Edits) 20:39, 11 May 2018 (UTC)

Ivanvector, The notion that the draft space should be an incubating space for content intended to form part of an article, and not a junk space to hold whatever bits of writing anyone wants to drop there, seems to be a minority opinion, is in fact very much a majority opinion. Our CSD criteria are very strict and narrow but there is no catchall for cases that don't completely match a criterion. I agree entirely that when a draft is reviewed we should be able to determine its article-worthiness on the first go-round, and either promote it or delete it. But we don't even do that in the harsh reality of the front-line trenches at at NPP where there are borderline cases that have to be sent to AfD, or inappropriate CSDs that admins have to decline and send to AfD. Contrary to GoodDay's point, it's not the Draft namespace that should be deprecated - it's more likely that AfC should be abolished or merged into NPP - but we're trying to come up with a compromise that will prevent that happening). Kudpung กุดผึ้ง (talk) 21:38, 11 May 2018 (UTC) Kudpung กุดผึ้ง (talk) 21:38, 11 May 2018 (UTC)

User:Kudpung, User:Ivanvector - I honestly didn't know that the common sense stated above was a majority opinion. It often seems that I am in the minority in thinking that draft space should be kept free of crud that will never be ready for mainspace. I don't mean to be sarcastic, but it does appear that Ivanvector and Kudpung and I are in the minority in wanting to apply common sense to what can be in drafts. Perhaps the problem is that AGF and BITE are carried to such extremes that they are allowed to override judgment about drafts. As User:Legacypac said today at my talk page, there is a culture of busybodies who have no practical experience at AFC or MFD but show up to express opinions. This is unfortunately part of a larger Wikipedia culture that it is a good idea to dump on the reviewers for not being sufficiently welcoming to new editors (even if they are fools or flacks). I honestly didn't know that Ivanvector and Kudpung and I were in a majority, when there is a culture of editors who preach platitudes about AGF and BITE without seeing the fools and flacks. (Of course new editors who have clues should be welcomed. Some do, many don't.) Robert McClenon (talk) 23:24, 12 May 2018 (UTC)

• I disagree. When reviewing pages at NPP, there are a lot of articles that could potentially be articles with a lot of work, but aren't good enough for article space. For example, an "article" of thoughts in bullet form with a list of references. Without the option to move this to draft space, are you suggesting that this be kept in article space or be deleted? Natureium (talk) 19:26, 11 May 2018 (UTC)

Userspace. —SmokeyJoe (talk) 21:44, 11 May 2018 (UTC)

• Support, or at least extending ACTRIAL to DraftSpace. On the whole it is a big negative, mostly due to the silent cold reception given to the newcomers. They should edit mainspace before starting new topics. —SmokeyJoe (talk) 21:42, 11 May 2018 (UTC)

Of course it would be better extend it to all users. We could do away with AfC altogether then, but that would defeat 50% of the object of having ACTRIAL - allowing IPs and non-confirmed user to create drafts was part of the plea bargain in order to get ACTRIAL approved at all. Kudpung กุดผึ้ง (talk) 04:32, 12 May 2018 (UTC)

• Wouldn't it be a possible idea to have a ClueBot NG style bot monitoring drafts and reverting resubmissions without substantial changes? I guess an edit filter won't work because it probably can't detect resubmissions but a bot could and that would be a potential time saver if human editors weren't forced to check those pages manually. Regards SoWhy 10:27, 12 May 2018 (UTC)

  Hmm, this is beyond AI at this time. SoWhy. "What is substantial changes"? Lot of text? Lot of references?. Number of sections?. –Ammarpad (talk) 10:37, 12 May 2018 (UTC)

  • • Well, ClueBot NG is pretty good at spotting vandalism. But that's why I asked. A bot could at least handle cases where no changes were made, couldn't it? Regards SoWhy 11:55, 12 May 2018 (UTC)
      • Actually, this isn't a bad idea. There's one draft currently being debated at MfD, where it was rejected for the seventh time for notability with the note that the Daily Mail isn't a reliable source, so the person removed the Daily Mail and then re-submitted. I've also seen drafts where it was re-submitted immediately after the rejection with literally no changes. It would very easy for a bot to detect and reject these submissions. —Compassionate727 ^(T·C) 21:33, 15 May 2018 (UTC)
• I don't really have any idea what this is all about. But from a purely technical viewpoint I could quite easily train an AI program to scan for substantial changes to an article, measured by a weighted quality score rather than using any one measure. Such a program could be programed to automatically detect whether sources have been added or just slightly altered. And it would be feasible for it to detect and warn reviewers of policy violations in the text. The only reservations I have is that since no program is perfect I would not recommend you have an AI editing articles all on it's own. JLJ001 (talk) 11:10, 17 May 2018 (UTC)
• The more I read these debates, the more I feel the ability to ban/block users from any form of article creation process is inevitable. Junkcops, aka FMecha (mail box|what I did) 05:41, 23 May 2018 (UTC)

Regarding MfD of drafts and G13

I've heard that G13 is supposed to delete the junk from draftspace, but there's a better way. I propose that we repeal G13 and expand *some* CSD to draftspace, possibly write up new draft-specific CSD and PRODs, without actually expanding the normal PROD to draftspace (because it wouldn't be patrolled enough). Why? First off, G13 is simultaneously too fast and too slow. Too slow to delete the obvious garbage (and does nothing for repeat, unchanged, AfC submissions), and too fast to accommodate an abandoned-but-workable draft. Second, G13 is arbitrary. 6 months means nothing (see also WP:NODEADLINE). In a nutshell, more specific deletion criteria, less G13 dragnet. Thoughts? Jjjjjjdddddd (talk) 03:58, 12 May 2018 (UTC)

Keep G13 and extend PROD to drafts. After all, it's no worse than PRODing a new article at NPP. Again, however, I come back to what I've been saying several times: Improve the Wizard so that it provides some useful instructions for new users. Kudpung กุดผึ้ง (talk) 04:27, 12 May 2018 (UTC)

G13 actually sorks in favor of good drafts. A non-AfC Draft gets the attention of an experienced user working the G13 elegable list and, if tagged for deletion, an Admin's attention. I've sent many pages to mainspace from the G13 list (but 99% that reach G13 need to go in the dust bin). Rejected AfC Drafts may be bot nominated.

MfD can function as an advertised PROD for Draftspace. If no one objects a week after nomination an Admin deletes. Legacypac (talk) 04:55, 12 May 2018 (UTC)

How would some sort of PROD be helpful for drafts if they're being resubmitted? That just sounds like you want to take G13 down from 6 months to 1 week. Nobody but the occasional AfC participant looks at any given draft, so any PROD-like system is just an attempt to mass-delete drafts. I don't think we have a rash of people who take a week or two off from their draft but come back and "ruin" G13 five months later. Either these pages are resubmitted to the point of disruption or they're not. ~ Amory (u • t • c) 13:17, 12 May 2018 (UTC)

G13 is one of the most bizarre rules on Wikipedia. I still don't know the reason it was instituted. These arguments about "clogging" the wiki are bizarre when you consider that it's all online. Also many of the deleting admins at g13 don't even look at what they are deleting, which to me is ludicrous for a wiki that claims to be a repository of the world's knowledge. Again, what exactly is the problem here and why are people looking for ever more unilateral ways to delete potential content?Egaoblai (talk) 10:43, 12 May 2018 (UTC)

I agree with you on G13, but I think it should be easier to delete drafts without potential, and other junk, so there are less junk drafts to get in the way of viable drafts. Jjjjjjdddddd (talk) 23:41, 12 May 2018 (UTC)

Egaoblai, Also many of the deleting admins at g13 don't even look at what they are deleting, which to me is ludicrous, that's a strong claim. Please state on what experience you base your assumption. Provide concrete examples. Kudpung กุดผึ้ง (talk) 02:37, 13 May 2018 (UTC)

I was looking through the G13 pages in December and saw one that I thought might be worth looking at, or at the very least not deleted without a conversation. The next day I went back to find it, but it had gone. I posted on deleting user's talkpage and asked them what the reason for deletion was, they said that it was because it hadn't been edited in 6 months and that was the only reason needed to delete an article.

I posted on the admin board about this as I believed that this was not the spirit of the rule and that deleting admins at g13 were supposed to check the articles before deleting them. The incident was closed and I messaged the closing admin about it, which actually led to this discussion: https://en.wikipedia.org/wiki/User_talk:Primefac/Archive_14#Closing_the_Incident whereI was told that deleting admins can and do delete articles at g13 without looking at them. Winged Blades of Godric even stated that "even a GA-standard article, that for some reason has been lingering for over 6 months in draft space, could be G13-ed." Not that they neccesarily agreed with that, but that is the system that is happening right now. Do we really want the same lack of oversight to be applied to PROD too? Egaoblai (talk) 16:16, 13 May 2018 (UTC)

This is commonly known, Kudpung. It may be that most admins who patrol G13 are diligent, but – as often happens – the vast majority of G13 deletions are carried out by the minority of admins who aren't. – Uanfala (talk) 14:47, 13 May 2018 (UTC)

On the contrary when I nominate G13 I save the occasional useful page and the Deleting Admins occasionally save a page I nominated so they are looking at them. We have a G13 postponed category too. We definately need G13 or the rejected and abandoned would pile up. G13 sweeps up all kinds of problematic pages, including link spam. Legacypac (talk) 04:06, 13 May 2018 (UTC)

Wow... just wow... Time for a history lesson. G13 was originally created when we had One hundred and thirty thousand pages in the space Wikipedia talk:Articles for Creation/ that had been created by 15-minutes-of-fame editors that had zero interest in coming back and correcting the issues raised with their submission. G13 was originally written to address AfC pages that had been 100% unedited for 6 months. Editors went through and did bulk nominations causing admins to be upset with the amount of pages G13 nomination category and with the overall size of the CSD nominations set. I developed a bot script that would procedurally go through all the pages and warn the author that the page was in danger of being deleted under G13, how they could prevent the deletion, how they could get the page back with a very low effort, and if they were a user the option of WP:USERFICATION. The bot limited the number of pages in the G13 sub-category to 50 pages at once so as to not overflow the admins. Over time the backlog was addressed, AfC moved to Draft space, Incubator moved to draft space, the G13 rule got finessed to be "unedited for 6 months (barring bot edits or trivial changes)" (which I think opens it up to discretion and uphold the more strict interpertation of the rule), and finally G13 got expanded to encompass all of Draft space. G13 was written to be a binary question Has this page been unedited for at least 6 months? If so, you may nominate for CSD:G13. The amount of Good will that is expended towards the authors whose pages get swept up by G13 is far more than any other area in Wikipedia for the simple reason that these authors are supposedly the newbies and shouldn't be bitten by not knowing all the esoteric rules of mainspace. Abolishing G13 will only create more MFD nominations. Hasteur (talk) 01:56, 14 May 2018 (UTC)

• G13 was logically required, and still is. G13 cannot be repealed for as long as newcomers are encouraged to start drafts. --SmokeyJoe (talk) 07:58, 14 May 2018 (UTC)

• G13 is certainly required but I've found ~5% of G13-ed abandoned drafts are on notable topics which might be salvageable with work but aren't ready for mainspace. I wish there were some way of dealing with these and bringing them to the attention of a wider editor base. Robotically deleting G13s because they are eligible feels wasteful to me. Espresso Addict (talk) 12:00, 15 May 2018 (UTC)

Sticky PROD for drafts (idea)

TonyBallioni expressed these 4-points in the above proposal.

1. repeatedly resubmitted
2. with no improvements,
3. has no chance of being in mainspace, and
4. has no sourcing for uninvolved editors to show notability

There are many, many drafts that currently possess the above characteristic squarely. However, I (previously) largely opposed because, it just repeats what exists, and will not make any solid difference to how MfD is run now. Because any draft that clearly possess these characteristics, it will surely be deleted at MfD. Now we are looking for way to move forward. To agree on more process that will hasten deletion of utterly non notable drafts that otherwise didn't met any of our CSD criterion and at the same time be courteous to these new users. One of the option can be clear need for Speedy criterion for them, which has been repeatedly discussed but lacked support. So I think why should we not try special PROD for that kind of drafts?. I know something like this was discussed before, but I am outlining it more explicitly below for more thought.

1. A draft meet all the above four characteristics.
2. A special sticky Draft Proposed Deletion tag (DPROD) is placed by user.
3. Once draft is tagged with DPROD tag, then it cannot be removed unless if the person wishing to remove it has thoroughly rewrote the article and moved it to mainspace. (This will serve two purposes: It will be an incentive to save salvageable drafts and at the same time any non-notable draft moved to mainspace without development will now be subjected to both WP:ACSD and AfD.)
4. If the tag, remains in the draft after say 1 week, 2 weeks or 1 month at most; then it will be summarily deleted as expired DPROD. Any recreation is subject to rule of G4 since it is determined not notable at all and no one is willing to explain why it should stay here.

Through this method, a large number of these hopeless draft will be easily shown the way out without exhausting editors' time at MfD and at the same time ample chance is given for anybody to prove why they should stay here.

Of course, this can be tweaked and refined. –Ammarpad (talk) 10:24, 12 May 2018 (UTC)

• Strongly Oppose Every single time someone makes a proposal to increase deleting things, the argument is always "but we'll only do it for the ones that are really non notable, we swear", and every single time, the dragnet is increased and increased until you have uninvolved editors, who have zero knowledge or interest in the subject of an article or draft declaring "this will never be notable". At least with the jury system of AFD these decisions have a fighting chance, but increasing the scope of what are basically unilateral deletions is not helping the Wiki with collaborative editing. Just the other week I dePRODded an article, which the nominator then sent to AFD instead, to which the community decided that the article was notable. How many articles that the community would have seen as notable have been wiped from the Wiki because of PROD? It's undemocratic and goes against the spirit of consensus, which is supposedly how this Wiki is run.Egaoblai (talk) 10:49, 12 May 2018 (UTC)

Again Egaoblai you are making some very strong assumptions. The way Wikipedia is run, some examples would be needed to give weight to your opinions. Our PROD systems were introduced on very strong consensus - are you suggesting PROD is 'undemocratic' just because you found one that was kept at AfD? Kudpung กุดผึ้ง (talk) 02:47, 13 May 2018 (UTC)

So, I have looked at your editing history and your user page and checked out the articles. I admit that more 'BEFORE' should have been done prior to listing them for deletion. But this is not a fault of the system, it's a problem of educating the users who tag them. In the case of the school article on which your arguments were excellent, your adversary has a clear pattern of singling out schools for deletion. They generally lose the school AfDs they nominate or vote on. Kudpung กุดผึ้ง (talk) 03:11, 13 May 2018 (UTC)

A system should be evaluated by how it works in practice, not in theory. Furthermore, just because a system is established by consensus does not mean the system itself is democratic. — Godsy ^(TALK_CONT) 04:57, 14 May 2018 (UTC)

• Support in principle, but perhaps a normal PROD would suffice. I am reminded of recent discussions somewhere about a 3-Strike rule, but I don't recall the outcome. Perhaps a PROD following the 3rd rejection? Kudpung กุดผึ้ง (talk) 02:51, 13 May 2018 (UTC)
• Support Prod for drafts but I prefer simply sending them to MfD as a form of advertised Prod If no one votes keep and adopts the page in a week it gets deleted without fanfare. Legacypac (talk) 07:49, 13 May 2018 (UTC)
• Support I am surprised there is not already some guideline providing for the deletion of drafts resubmitted after being rejected for non-notability, and where the draft has been changed little if at all since the last rejection. I certainly think this would be helpful in helping the community delete some of these drafts that clearly have no chance of becoming actual articles. But I wonder: the proposal uses the word "repeatedly"--does that mean that a draft that was rejected once, resubmitted, and then rejected again would immediately become eligible for deletion? Does "repeatedly" mean "2 times or more" here? (BTW what the answer to this question is doesn't really matter as far as my support for this proposal is concerned.) Incidentally, I might even support the use of a new CSD criterion for drafts repeatedly rejected as non-notable, where the lack of notability is obvious. Every morning (there's a halo...) 21:08, 13 May 2018 (UTC)
• Comment Do you realise how BITEY this sounds? "Hey your draft sucks and we've put a label on that means if you don't improve it in one week it's getting deleted!" If you wish to frustrate new users or people that can't afford to spend hours a day on Wikipedia, then this is the proposal for doing that. AFC reviewers are not gods and their opinion on what is notable should not supercede the community at large. Currently drafts can be deleted through MFD, which at least puts things to a public discussion. There is also G13 which is mostly hidden and allows drafts to be deleted without discussion after 6 months. Now you want to increase that power and allow drafts to be deleted after a week? based on the opinion of one person at AFC? What is with this paranoia and hand wringing about drafts. What problems are there that this is a solution to that G13 or MFD don't already solve? Please consider that for many many users here, writing a draft is a learning process and so is submitting it for review. Not every draftee is out to try and scam the wiki, many are good faith contributers, often with English as a second language who need guidance and help and community. What ever happened to that on this wiki? As far as I can tell this proposal does not allow any chance for the community to help the draftee improve the page, nor does it offer any space for the community to discuss the merits of the draft. According to the proposal one or two AFC editors could effectively blackball a topic from wikipedia and this would go unnoticed by the majority of editors, unless they were also AFC editors who happened to look in, or people who browsed Prod. This is really unacceptable for anyone who sees this as a community project. Egaoblai (talk) 00:06, 14 May 2018 (UTC)
• Oppose So you'd rather take the consensus discussion that happens at MFD to individual draft pages and put a arbitrary stickey prod on it? PROD is "I propose a uncontraversial deletion". The only exception is BLPPROD, and that is foundation policy. Hasteur (talk) 01:58, 14 May 2018 (UTC)

  That is not true. BLPPROD was not created by fiat because of "foundation policy" as you're wrongly implying. It was created after community consensus was found for it. Your first point doesn't make sense either. It is still uncontroversial PROD, if you object to any DPRODDED draft, then simply develop the draft to become meaningful article, move it to mainspace and remove the tag, the same way it is done for sources in BLPROD. –Ammarpad (talk) 07:06, 14 May 2018 (UTC)

• Oppose for drafts that, if they were articles, would not fall under BLPPROD; support ONLY for drafts on living people that would otherwise fail BLPPROD. There's absolutely no reason to apply a sticky PROD to all drafts, and as noted above it's fairly BITEy to users for whom English may not be a language they can communicate well in. (There have been a few instances in -en-help where users seeking help have "keyworded", missing most of what was being said and responding only to certain words in the message.) That said, biographical drafts do still fall under WP:BLP, and so those can and probably should be allowed to be sticky PRODded if they have absolutely no sources (or ELs that can be made into sources) whatsoever. —Jeremy v^_^v ^Bori! 03:11, 14 May 2018 (UTC)

  @Jéské Couriano: You missed the requisite points raised above. This is not meant to apply to all drafts. It is meant only for draft that:

  • is repeatedly resubmitted
  • with no improvements,
  • has no chance of being in mainspace, and appears to
  • has no sourcing for uninvolved editors to show notability. –Ammarpad (talk) 07:16, 14 May 2018 (UTC)

  To which I'm saying that those limitations are bullshit. In essence, I'm saying "apply BLPPROD standards to biographical drafts instead of making a sticky PROD standard for all drafts". Note that my argument in favour of MfD'ing unacceptable drafts above comes with caveats more along the line of those suggestions you just threw at me. I agree with the other Opposes in that this is something that seems too half-baked and, as pointed out below, the time period the grace period provides is ludicrously short, considering most drafts tend to get abandoned due to real-life concerns. The only sticky PROD debate we should be having is whether to apply BLPPROD to drafts, not whether to BITE newcomers who may not speak very good English or who (almost invariably) have real-world commitments that make this sort of PROD so bitey. —Jeremy v^_^v ^Bori! 08:48, 14 May 2018 (UTC)

• Oppose - 3.Once [a] draft is tagged with DPROD tag, then it cannot be removed unless if the person wishing to remove it has thoroughly rewrote the article and moved it to mainspace. is fairly self-evidently ridiculous, but I'll explain the fundamental flaw (among the many flaws): Deletion bar improvement should not be turned into a unilateral decision by a single editor but should remain a community decision that is made through a discussion to determine consensus. — Godsy ^(TALK_CONT) 04:47, 14 May 2018 (UTC)
• Oppose - Sticky and PROD don't belong together, especially not in draft which is supposed to be a safe space for article development. ~Kvng (talk) 12:57, 14 May 2018 (UTC)

Draft is for article development - you got that part right. Deletion procedure is for junk/promo that is not going to be an acceptable article. Legacypac (talk) 15:12, 14 May 2018 (UTC)

• Oppose for this to work it would have to have objective criteria, things like "no chance of being in mainspace" and no evidence of notability are very subjective. The process doesn't make any sense at all. If I take a draft which has been sticky PRODed and add two sources which demonstrate that the subject is notable then I can't remove the tag. Not unless I'm also prepared to completely rewrite the article and get it ready to move it to mainspace before the clock expires. Having recreations subject to G4 doesn't make any sense either, and we don't apply it to other types of PROD. MfD is not being inundated with deletions of hopeless drafts and if it was then something closer to normal PROD would make more sense. Hut 8.5 18:22, 14 May 2018 (UTC)
• Oppose. I appreciate the good intent of this idea, but I think it has the problem of setting a deadline for something that doesn't need a deadline. The main proposal above is in large part about the problem of drafts that keep getting resubmitted, but the proposal here is about drafts that are just sitting there. --Tryptofish (talk) 19:18, 15 May 2018 (UTC)
• Oppose draft means draft.--Paul McDonald (talk) 23:22, 24 May 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.

• Noting here for reference that I intend to question the detail of the close, with a view to challenge the close if it says the proposed text exactly has consensus to be locked in. It has problems. The exact text was not carefully considered by anyone that I can see. Main discussion at WT:Drafts. —SmokeyJoe (talk) 09:38, 11 June 2018 (UTC)

Remove default subject for "Email this user"

Moved to MediaWiki talk:Defemailsubject

Can we please remove the default "Wikipedia email" subject for "Email this user" and force editors to add their own custom subject? It would make my Inbox much easier to navigate and I imagine the same would be true for others. --NeilN ^{talk to me} 14:38, 11 June 2018 (UTC)

Follow up at MediaWiki talk:Defemailsubject. — xaosflux ^Talk 15:13, 11 June 2018 (UTC)

Proposal to change "on the article's talk page" for deleted articles

If one goes to Wikipedia: Articles for deletion, one can often see notices after a discussion has closed saying "The following is preserved as an archive of the debate. Please do not modify it". This notice then says that subsequent comments can be added to a deletion review or to the article's talk page. However, making comments on an article's talk page is difficult if the article has been deleted here. My proposal is that we change the wording if an article has been deleted. Vorbee (talk) 19:12, 6 June 2018 (UTC)

Conversely, the talk page is the single best place for subsequent comments if the article hasn't been deleted.

(I'm going to preemptively oppose any suggestion that Template:Afd top and Template:Afd bottom change to require additional parameters, either the article's name or whether it's been deleted. People do still close discussions with just the edit button.) —Cryptic 19:50, 6 June 2018 (UTC)

• If the article has been deleted, then the appropriate venue to go is Deletion review not talkpage and this has already been linked. Nothing requires change here. –Ammarpad (talk) 12:34, 7 June 2018 (UTC)
• Yes, we can go to Deletion review but that still means that the phrase "on the article's talk page" remains for deleted articles. All I am really proposing is that we remove this phrase if an article has been deleted, as it might confuse new users of Wikipedia. Vorbee (talk) 15:16, 7 June 2018 (UTC)

• Just for clarity, here is what it actually says: The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page. So no, it doesn’t just say to use the article’s talk page, it says to use th appropriate page, which may or may not be the article’s talk page. Beeblebrox (talk) 19:53, 11 June 2018 (UTC)

Proposed mergers

A discussion at the village pump in 2013 overwhelmingly concluded the current proposed mergers system (the process & templates) to be inadequate. A consequent discussion on implementation of an automated system similar to requested moves was archived after 2 months of inactivity. The latter discussion had 6 participants; no conclusion was reached. I would like to see if there is a change in consensus to see if we can reach a conclusion. — Preceding unsigned comment added by 75.67.58.188 (talk) 20:54, 11 June 2018 (UTC)

Minor visual update to access locks

Following a an old RFC, the current access lock scheme for CS1|2 template is

• (current) / /

The first icon is meant to convey open access, the second one is meant to convey limited access, the third one is meant to convey closed access. This scheme has as a few problems.

First, the red lock is not very recognizable as a lock. To fix this, I propose a more recognizable red lock

• (new1) / /

However, an additional problem is that Green/Blue/Red makes does not convey progression, and was picked over a more logical Green/Yellow/Red by a non-statistically significant 1 vote, mostly because the yellow didn't look very yellow. It also tends to get lost in the sea of blue, e.g. (JSTOR 01234 )

• (old1) / /

To fix this, I propose a better intermediate level lock: grey

• (new2) / /

Some people also didn't like the red, feeling it was too aggressive, so we could stick to green and grey:

• (new3) / /

The "new2" scheme only has advantages compared to the current scheme: It has more recognizable icons, better accessibility, and better conveys levels of access. "new3" loses easier distinctions between limited and closed access, but is also less aggressive.

Which of the proposed schemes should we use?

• new2 > old1 > new3 > new 1 > current. Headbomb {t · c · p · b} 02:45, 7 June 2018 (UTC)
• new2, failing that new1, failing that current. Both of these have sufficient distinction in color and shape, with grey as a more intuitive color progression than blue thus my preference for new2. Current is not particularly intuitive but the different symbols are nonetheless quite distinct and thus recognizable enough once their meaning is learnt. Not a fan of new3: these symbols are displayed at a small size and the two different grey symbols are sufficiently "similar-ish" (very similar shape, fairly similar ratio of grey-vs-white even if the *pattern* in which it is used differs) that I suspect they may be hard to distinguish for people with limited vision. AddWittyNameHere (talk) 03:04, 7 June 2018 (UTC)
• I'm going to rank these, if you don't mind, as well. I concur wholly with AddWittyNameHere. new2 looks best to me, though I really do object somewhat to the grey; then new1 and current, and finally, new3 (like AddWittyNameHere said, two grey locks are hard to distinguish, and that's bad for accessibility reasons). Great work, by the way! — Javert2113 (talk; please ping me in your reply on this page) 03:08, 7 June 2018 (UTC)
• new2, and failing that, new1. Gray and gray doesn't help distinguish anything, especially when there aren't three right next to each other. New red lock looks nice. ~ Amory (u • t • c) 10:29, 7 June 2018 (UTC)
• new2 looks fine. Grey conveys "no information really", which is right for the middle lock (once you require login, restrictions have an almost infinite granularity) but not when we know for sure that something is paywalled. --Nemo 10:44, 7 June 2018 (UTC)
• old1, new1, current, in that order, because progression/streetlights, and grey is more ambiguous than blue. ~ Tom.Reding (talk ⋅dgaf)  12:21, 7 June 2018 (UTC)
• new4, old1, new3 Some people will only be able to visually distinguish a single element; color, lock body (open, partial, filled) or intensity (light, shaded, dark) so each icon needs to be distinguishable by a single element. I would suggest a new4 which makes the distinction between the open, half-filled and filled body of the lock more crisp and varies the color intensity/tone in a noticeable way between the three. I would also suggest a slight increase in size since some will not be able to resolve the body of the lock; removing the dot in the 'open' making the body white; and removing the dot in 'locked' making it solid. This should result in a more crisp image which is easier to resolve. Jbh ^Talk 15:44, 7 June 2018 (UTC) Last edited: 15:55, 7 June 2018 (UTC)

The problem with is that it looks like an lowercase a. This is particularly bad when printed, or in grayscale. Headbomb {t · c · p · b} 18:44, 7 June 2018 (UTC)

You are right! Maybe using a different shaped lock body … like the keyed padlocks that are shaped more like an upside-down Ü See second and fourth pictures in gallery vs the first one at Master Lock. Jbh ^Talk 15:13, 8 June 2018 (UTC)

@Jbhunley: those get confused with HTML security locks like this one. Headbomb {t · c · p · b} 15:15, 8 June 2018 (UTC)

Ahh... I had not thought of that. Jbh ^Talk 15:19, 8 June 2018 (UTC)

• new1 - That's the only one I think is the best option, To me the gold lock doesn't convey "Limited access" and the grey ones could be confused with something being hidden ? ... Not sure on the that but yeah I prefer new1. –Davey2010^Talk 15:51, 7 June 2018 (UTC)
• new1 per Davey. --Ahecht (TALK
  PAGE) 18:15, 7 June 2018 (UTC)
• new 3. I don't think the red is necessary, and draws unwarranted attention. Natureium (talk) 18:20, 7 June 2018 (UTC)
• new 2, new 1, current (in that order). @Davey2010 and Ahecht: Doesn't limited access usually mean that it's partially hidden (such as you can view the first few paragraphs or something)? LittlePuppers (talk) 23:14, 7 June 2018 (UTC)

@LittlePuppers: The mouseover text says it means "free registration required". --Ahecht (TALK
PAGE) 23:27, 7 June 2018 (UTC)

Ah, okay, I see that now. Thanks, Ahecht! LittlePuppers (talk) 23:38, 7 June 2018 (UTC)

• comments: If this topic is supposed to be, or to act like, an RFC (as proposer described it here), shouldn't it be treated as if it were an RFC? Shouldn't proposer add {{RFC}} so that editors who don't watch this page can know that it exists?
  I question the notion that there is a problem here to be solved. Where is the evidence that readers are confused by the shapes/colors of the current lock definitions? So far, all we have is proposer's opinion that the the red lock is not very recognizable as a lock and that Green/Blue/Red makes does not convey progression and that some people also didn't like the red.
  Where is the evidence to show that the red lock with a transparent opening is more recognizable as a lock than the current red lock? GBR isn't necessarily intended to 'convey progression'; just difference. The individual locks could be any color as long as the chosen colors meet the accessibility guidelines against both white and black backgrounds. People are comfortable with GYR but shades of Y that are accessible against both white and black are rather more bilious than yellow so blue was suggested as a more palatable option. Doesn't seem like a problem that needs fixing. Yeah, so some people don't like the red; some people don't like the blue (the sea-of-blue argument) and some people don't like the bilious yellow. Ok, we will never please all of the people all of the time so without a significant uprising to indicate that the red is disliked by most people, doesn't seem like a problem that needs fixing.
  In the original RFC, Editor NMaia suggested emojis as a possible option. That suggestion wasn't taken up but, upon reflection, I think it should be. The emojis are standardized Unicode characters: U+1F513 🔓 OPEN LOCK, U+1F510 🔐 CLOSED LOCK WITH KEY, and U+1F512 🔒 LOCK. With a bit of css, these characters can be manipulated: Example title link⁠🔓. Further, because the emojis are characters, the no-wrapping issue for url access signalling might be resolved by the simple insertion of a word joiner character (&#8288; U+2060) between the url's marked-up title text and the emoji (see this discussion about why the current url access signals are allowed to independently wrap to the next line). —Trappist the monk (talk) 14:10, 8 June 2018 (UTC)

If you want data, I asked about 10-12 non-Wikipedian their opinions of the red lock, and about half recognized the dial-less lock as a lock. Everyone recognized the dial lock as a lock. Additionally every single one was confused by the Green/Blue/Red scheme ("why blue/what does blue mean", or made a comment "why don't you use yellow?"), but no one was confused by Green/Yellow/Red or Green/Grey/Red scheme. Headbomb {t · c · p · b} 14:17, 8 June 2018 (UTC)

• Building something off emoji may be the best idea. They are the most 'standard' icons and people across the world will be familiar with the iconography even if the visual details vary from implementation to implementation. Jbh ^Talk 15:18, 8 June 2018 (UTC)

I could support this idea, I think, so long as the free-to-read Unicode character could be differentiated somehow: maybe a white background? The opened lock might be hard to see. (As you can tell, I don't know anything about Unicode characters, or if they could be changed.) — Javert2113 (talk; please ping me in your reply on this page) 15:23, 8 June 2018 (UTC)

Emojis are by far the worst of ideas. Their appearances varies, they often look downright awful, and are often barely distinguishable, even to those with perfect vision, and aren't simply designed to convey information and meaning. And we also lose the association with the PLOS Open Access icon (this one meaning free to re-use). Headbomb {t · c · p · b} 15:24, 8 June 2018 (UTC)

Oh, and here I thought it was my terrible eyesight. Yeah, emojis might not be the best idea after all. — Javert2113 (talk; please ping me in your reply on this page) 15:40, 8 June 2018 (UTC)

• new1 ~★ nmaia ^d 14:33, 8 June 2018 (UTC)
• new2. I applaud Headbomb for conducting the study, which found that every one of the dozen or so participants were confused by the blue lock. We need more of this: ask the readers when you are making decisions that affect them. – Finnusertop (talk ⋅ contribs) 18:47, 8 June 2018 (UTC)
• Not new2 or new3; it doesn't particularly help to have two items the same color, whether two red (new2) or two grey (new3). I share the concern about "doesn't look like a lock"; why not just use the same padlock as we're currently using for ordinary pages? Or we could just abandon the locks-only system entirely. Use an open padlock, some sort of intermediate character, and a non-lock thing like a big X. Go to JSTOR and look for anything (example), and see their icon for "you can't access this resource". Nyttend (talk) 21:29, 10 June 2018 (UTC)

@Nyttend: new2 doesn't have two red icons. What are you talking about?Headbomb {t · c · p · b} 23:14, 10 June 2018 (UTC)

Aren't left and right the same color? They look the same to me. Nyttend (talk) 02:12, 11 June 2018 (UTC)

Only if you're red/green colorblind. But you'd see that in every other scheme as well. Headbomb {t · c · p · b} 02:21, 11 June 2018 (UTC)

Not every scheme. I designed the main chart at WP:CANCER to be red-green-colorblind-friendly after I realized that the original red/green (chosen by a previous editor) was a problem. --Guy Macon (talk) 02:35, 11 June 2018 (UTC)

every scheme above is green/something/red save for new3 which is green/grey/grey. Headbomb {t · c · p · b} 02:41, 11 June 2018 (UTC)

Maybe we could mix some blue and orange into those? It wouldn't be the worst idea: blue-green for open-access, orange-red for closed access. Not sure if it's been implemented already. —Javert2113 (Let's chat!) 02:42, 11 June 2018 (UTC)

If you did that, you'd lose the association between progression of access and progression of color for 95% of people. Headbomb {t · c · p · b} 03:44, 11 June 2018 (UTC)

Yes, I am red-green colorblind, and I see the same thing in every other scheme; I just thought I should respond to the new ones, since seemingly they're the only ones under discussion. Sorry for the disruption; I didn't realise that they weren't the same colors. Can't we just scrap the whole color issue and use completely different icons, and the colors either wouldn't matter or they'd all be the same? Use an open padlock for "you have access" (similar to the one next to "Get online access" at [1]), use a closed padlock for "you don't have complete access", and an X on background (like File:Octagon-warning.svg) for "you have no access at all". Nyttend (talk) 03:08, 11 June 2018 (UTC)

Well, that's the reason why the icons are different, empty body + open shackle, half body + half shackle, full body + closed shackle. An X would be very unclear in meaning (broken link? not working? disabled? don't go there? hide/close citation? hide/close identifier?), and could also be confused with the character X. Headbomb {t · c · p · b} 03:32, 11 June 2018 (UTC)

Yes, I'm worried about the semiotic differences between a closed shackle and an X. They're different, sure, but as Headbomb notes, folks might not be able to immediately distinguish the two, insofar as instant understanding of access to information is concerned. But that's not the proposal at hand, so please pardon my digression. —Javert2113 (Let's chat!) 03:46, 11 June 2018 (UTC)

By the way, what does "limited access" mean in this context? No authentication needed, but issues not related to authentication (e.g. technical issues; maybe the website goes down a lot) may prevent access? As far as "X", how would you ever get that confused with the letter X in running text? Who's going to confuse my proposed image with a simple character? Nyttend (talk) 23:33, 11 June 2018 (UTC)

See Help:Citation Style 1#Registration or subscription required (current blue locks [registered/limited]). Headbomb {t · c · p · b} 00:40, 12 June 2018 (UTC)

• old1 > new2 > new1 > current > new3. Old1 looks plenty yellow to me, but barring that, gray is fine — pythoncoder  (talk | contribs) 14:29, 11 June 2018 (UTC)

Nutshell templates

I am proposing that the nutshell templates be used in Wikipedia's encyclopedic articles to provide a quick summary about a particular subject. Please let me know what you think of this proposal.
Example: United States

--2601:183:101:58D0:B420:71FD:AA18:2464 (talk) 21:54, 3 June 2018 (UTC)

No. That’s what the lead section is for. Beeblebrox (talk) 22:29, 3 June 2018 (UTC)

The first sentence at United States reads: "The United States of America (USA), commonly known as the United States (U.S.) or America, is a federal republic composed of 50 states, a federal district, five major self-governing territories, and various possessions." We think our readers are capable of reading and comprehending a 33-word sentence; 10-year-olds are not our target audience. What reader benefit does your nutshell add that justifies the added clutter? ―Mandruss ☎ 22:31, 3 June 2018 (UTC)

Why do policy and guideline pages use the nutshell template? Why not use the first sentence of the article? --2601:183:101:58D0:B420:71FD:AA18:2464 (talk) 23:03, 3 June 2018 (UTC)

See WP:SHORTDESC. This is a project that does almost exactly what you are looking for. Bradv 23:28, 3 June 2018 (UTC)

Nutshell banners work well when the page is a lengthy set of instructions and the reader needs help to understand what they should do or focus on. For an encyclopedia article, what Brad noted. A database of 5 million short descriptions on any topic is quite useful on its own, can be used on mobile apps, book reading apps, Google search result page, etc.. but when landing on the encyclopedia page itself, it's redundant with the lead section. -- GreenC 14:04, 7 June 2018 (UTC)

• Many pages already have an info box that serve that purpose. A "nutshell" box across the top seems redundant.--Paul McDonald (talk) 21:35, 12 June 2018 (UTC)

American English Wikipedia

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.

---

Split American English Wikipedia (let's say american.wikipedia.org) and use British English on English Wikipedia as British English is the original dialect of English. That would solve all debates on which dialect of English should be used on which article. Erkinalp9035 (talk) 16:36, 18 May 2018 (UTC)

Articles currently in American dialect would be moved to American English Wikipedia. Articles written Australian, NZ and Indian varieties would be converted to British English. Erkinalp9035 (talk) 16:38, 18 May 2018 (UTC)

Extremely bad idea. Lots of work without any gain whatsoever. Also, Australian and New Zealand Englishes are perfectly legitimate and separate varieties of English. Mr KEBAB (talk) 16:40, 18 May 2018 (UTC)

@Erkinalp9035:, you may want to see this. The wild impracticality also applies equally to this. I also suggest reading the Manual of Style on English varieties. Good luck. Eggishorn (talk) (contrib) 16:43, 18 May 2018 (UTC)

WP:ENGVAR is already quite adequate to deal with it. Splitting projects would be a massively excessive "solution" to an already solved problem. Seraphimblade ^{Talk to me} 16:45, 18 May 2018 (UTC)

Sorry for necroposting, but MediaWiki already has a separate "en-gb" language option, so we could theoretically have a "en-gb.wikipedia.org". Lojbanist ^{remove cattle from stage} 23:29, 29 May 2018 (UTC)

It'd be better to have someway to convert articles between the two (actually all) English dialects within the same Wikipedia. I think that was originally planned for the Serbian Wikipedia (for ekavski and ijekavski dialects) using lookup tables or something.Details on that plan here. I'm pretty sure that part wasn't implemented and they only got the Latin/Cyrillic script converter. Anyway, the ekavski/ijekavski problem is a headache (go read about it) but doing English "dialects" should be really simple. Brightgalrs (/braɪtˈɡæl.ərˌɛs/)^[ᴛ] 15:38, 6 June 2018 (UTC)

There are some quirks that make it a non trivial exercise, but it could be done, it would be appreciated by some of our readers. I've argued in the past that we should go down the Chinese wiki route and let the readers choose the version of English they want displayed to them. But I now think we should first find out what proportion of English Wikipedia users would benefit. ϢereSpielChequers 11:24, 12 June 2018 (UTC)

Some words and idiomatic phrases are completely different (consider an article on torches, for example). Thus the onus would fall on editors to markup the source appropriately. I suspect this would face issues in practice. isaacl (talk) 16:17, 14 June 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.

Polling templates

I suggest including the polling templates on Commons to Wikipedia. It would look better on Requested moves, Articles for deletion, and Proposed mergers and other Wikipedia proposals.
https://commons.wikimedia.org/wiki/Category:Polling_templates
--192.107.120.90 (talk) 14:03, 7 June 2018 (UTC)

• You clearly need to read Wikipedia:Polling is not a substitute for discussion. IIRC these templates did exist here once but were deleted. 109.146.136.16 (talk) 15:01, 7 June 2018 (UTC)
• Agree Wikipedia: Polling is not a substitute for discussion should be the guiding force here. Vorbee (talk) 08:51, 15 June 2018 (UTC)

Making widely-used icons consistent and modern

There is no consensus to make any changes.

Cunard (talk) 00:35, 2 July 2018 (UTC)

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

---

Look into most used files. We have four different information icons in the top thirty images. Most of them are also really old designs with lots of details (which was a thing in mid 2000s but not anymore) and they don't scale down to the size that they are being used. Most used icons are mostly in three categories:

• Portal icons
• *-stub template icons
• *mbox templates

I hereby suggest using more modern set of icons that are more abstract (for example see Template:Astronomy-stub) or more specificity from these five sets: c:OOjs_UI_icons (icons used in the interface of mediawiki), Wikipedia 15 icons, c:Category:Material Design icons (because of the similarity), and c:Category:Emoji One BW (because of the diversity of the inventory). If not, at least putting some style guide for the icons. Ladsgroup^overleg 23:58, 26 May 2018 (UTC)

Yeah, I agree. Another icon-related thing: does anyone want Wikimedia to implement some form of HTML5 Canvas? Lojbanist ^{remove cattle from stage} 02:14, 27 May 2018 (UTC)

• While on the subject, I would really like a new set of icons for Portal:Contents to represent the categories, they all have to be SVG and the same size, so anything in the way of better / more modern CC0 / PD icons would be great. JLJ001 (talk) 14:36, 27 May 2018 (UTC)sockstrike Galobtter (pingó mió) 17:02, 3 June 2018 (UTC)
• All those icons look rather flat, one toned, and overall meh. —Farix (t | c) 16:30, 27 May 2018 (UTC)
• Whole-hearted support. Ladsgroup, I think you're a hero for proposing this. A lot of our visual iconography around here is a product of the trends early-2000s that birthed Wikipedia, and it's hugely overdue for a facelift. A flatter look like that represented by those material design icons would go a long way towards updating the look and feel. However, this is the most subjective matter imaginable, so I'm not sure how far this will get. But I'll with you all the way. A Train^talk 23:44, 27 May 2018 (UTC)
• This is something worth looking into, but of all the possible arguments in favor of changing some of the icons, saying that they're no longer fashionable is really the bottom of the barrel, in my opinion.
  Anyway, let's put together some examples of the icon set. To compare:

Some current icons:

Please stop disruptive blah blah blah.

Compared to icons from the proposed sets:

Please stop disruptive blah blah blah.

--Yair rand (talk) 03:09, 28 May 2018 (UTC)

The proposed icons are mostly horrible and not inline with the aesthetics of the project. The puzzle piece especially, which loses the Wikipedia logo entirely. I don't mind the new scales however. Do it on a case by case basis, but remember that most of the use of the 'bad' icons (like some assy .jpg version) is due to the substitution of old templates that have long been updated to look better. Headbomb {t · c · p · b}

I agree about the puzzle logo but other ones look way better. Specially having consistency in the look seems great to me. We can use more blue in the icons to give the sense of ink Ladsgroup^overleg 04:41, 28 May 2018 (UTC)

• I am with Headbomb here. Most the icons look crap on Wikipedia, but there are some improvements that can be made with the icons that do look good, so by all means. JLJ001 (talk) 19:42, 28 May 2018 (UTC)sockstrike Galobtter (pingó mió) 17:02, 3 June 2018 (UTC)

• Mixed - I would say the same - the new scales look nice, but the others are less so, especially the puzzle piece as noted. Consistency all well and good, but some consideration on whether the older or more modern design is better in each case would be advisable Nosebagbear (talk) 12:24, 29 May 2018 (UTC)
• Support. It should be noted that the French Wikipedia is attempting something similar. Lojbanist ^{remove cattle from stage} 23:26, 29 May 2018 (UTC)

• Ladsgroup, I genuinely have no opinion on this topic, but do you think it would be better to wait until this discussion is finished before changing all the icons? Primefac (talk) 16:59, 3 June 2018 (UTC) (please ping on reply)

  Primefac The last edit on the discussion was about four days ago and I mostly wanted to be bold and change things gradually (changing everything in one go would be complicated and I don't want to do that.) Ladsgroup^overleg 17:06, 3 June 2018 (UTC)

  Fair enough, guess I wasn't paying that much attention to the timestamps, more the fact that there's about 50/50 for/against so far. Primefac (talk) 17:10, 3 June 2018 (UTC)

  I don't think you should be changing the icons. I don't see a consensus for changing, with many complaining about the OOUI icons being flat/bad, and personally I don't like the new information icon that much; I don't hate it though, and could be convinced on it. Probably need an RfC if you want to change things; and IMO either use the new OOUI information icon or the old one, but mixing seems horrifying. At the very least, all the warning templates should use the same icon. I've reverted the changes since they don't seem to have any consensus. Galobtter (pingó mió) 17:16, 3 June 2018 (UTC)

  There is a design style guide that explains why icons have been designed this way. This is a good read. Let's make subsections to move forward Ladsgroup^overleg 17:25, 3 June 2018 (UTC)

  I've posted a link to this discussion at Template talk:Ambox. I think notices should probably be posted on talk pages of all templates that will have icons changed. --Yair rand (talk) 23:27, 3 June 2018 (UTC)

• Oppose I *do* think it's time to change the icons somewhat, and the proposed ones do look modern and nice, but I don't think these would be best for the message we're trying to send with these icons. Jjjjjjdddddd (talk) 16:08, 7 June 2018 (UTC)
• I support the general idea; this has long been overdue. I do not support some of the proposed replacements, because they might miss the point ("neutrality icon", see below). We should not blindly take these icons from a library. We should modify these SVGs (one reason why SVGs are awesome) to match our requirements. I'll go ahead with the black exclamation mark. Give me a few minutes, I hope. ~ ToBeFree (talk) 01:10, 10 June 2018 (UTC)
• Oppose: I agree with Jjjjjjdddddd and ToBeFree: it's time for a change, but let's not borrow these icons wholesale. We're Wikipedia, after all, and SVGs give us a chance to add our own mark to the icons and, perhaps more importantly, discuss the changes. (Mostly the discussion, I suppose, but I digress.) Moreover, the icons presented could use some modification to suit our needs, though I do like their sleekness. — Javert2113 (talk; please ping me when you reply) 01:27, 10 June 2018 (UTC)
• Oppose all. No need to change it all. Take it on a template per template basis. – Finnusertop (talk ⋅ contribs) 03:45, 11 June 2018 (UTC)
• Oppose: That puzzle piece looks terrible compared to the one we have now. - Knowledgekid87 (talk) 14:23, 11 June 2018 (UTC)
• Oppose all so far. The single-color ones are harder to discern with bad eyesight. Daß Wölf 19:36, 11 June 2018 (UTC)
• I use the desktop interface, and on that interface I don't see a need to change. If people using smartphones would benefit from the mobile interface displaying simpler icons then I have no objection to something that serves simpler icons on mobile or very low resolution display options. But if this is about replacing the fad of fifteen years ago for a current fad then please don't. Wikipedia has its own style and there is an advantage in being consistent in that, not doing change for the sake of change. ϢereSpielChequers 11:34, 12 June 2018 (UTC)
• Since it somehow didn't get mentioned below, Oppose the new version of the puzzle piece for the reason given by Headbomb.--Khajidha (talk) 14:28, 13 June 2018 (UTC)
• Late to the party oppose because there seems to be no need for what is being suggested. Happy days, Lindsay^Hello 14:54, 18 June 2018 (UTC)
• Oppose the suggestion of these specific icons, but a Strong Support for the general idea of a more unified icon system. Miss on execution, but I'd love to see a better formulated attempt at this suggestion. Lusotitan (Talk | Contributions) 18:10, 18 June 2018 (UTC)

Changing information icon

This is proposal to replace blue information icons ( ) with the OOjs one () Ladsgroup^overleg 17:27, 3 June 2018 (UTC)

• Support as proposer. Ladsgroup^overleg 17:27, 3 June 2018 (UTC)
• Oppose - this icon is less visible to me. --Khajidha (talk) 00:19, 5 June 2018 (UTC)
• Support: This is not a warning icon. It doesn't need to be big, red and visible. ~ ToBeFree (talk) 01:06, 10 June 2018 (UTC)
• Oppose: Admittedly, it may be my poor eyesight, but this icon is less visible to me, as well. The lack of a shadow effect, I believe, is what's causing this. Or the light effect. Not really sure how to describe it. — Javert2113 (talk; please ping me when you reply) 01:27, 10 June 2018 (UTC)
• Oppose - The ones we have now are more visible and get the job done. - Knowledgekid87 (talk) 14:20, 11 June 2018 (UTC)
• Oppose. I like the blue background. Maybe something like one of these (although ideally darker)? — pythoncoder  (talk | contribs) 19:23, 12 June 2018 (UTC)
• Oppose Less striking or visible or obvious. This seems like a solution in search of a problem. Happy days, Lindsay^Hello 14:54, 18 June 2018 (UTC)
• Oppose There is nothing wrong with the old one. We don't need to be changing things to one solid color MS paint-style icons that stand out less. Natureium (talk) 18:35, 18 June 2018 (UTC)

Changing alert icon

This is proposal to replace red alert icons ( ) with the OOjs one () Ladsgroup^overleg 17:30, 3 June 2018 (UTC)

• Support as proposer. Ladsgroup^overleg 17:30, 3 June 2018 (UTC)
• Oppose - the black ! stands out better than the red one. --Khajidha (talk) 00:20, 5 June 2018 (UTC)
• Oppose per Khajidha. Jjjjjjdddddd (talk) 16:05, 7 June 2018 (UTC)
• Only if implemented with a black exclamation mark, support. ~ ToBeFree (talk) 01:06, 10 June 2018 (UTC)
• Oppose: the black exclamation mark makes this stand out, and rightly so. — Javert2113 (talk; please ping me when you reply) 01:27, 10 June 2018 (UTC)
• Oppose per Khajidha. — pythoncoder  (talk | contribs) 14:23, 11 June 2018 (UTC)

New proposal

With a black exclamation mark and a darker red triangle: Change and to

• Support as proposer. ~ ToBeFree (talk) 01:39, 10 June 2018 (UTC)
• Weak support: I still like the lighting effects. — Javert2113 (talk; please ping me when you reply) 01:56, 10 June 2018 (UTC)
• Support: nice, clean separation between triangle and exclamation point. --Khajidha (talk) 10:52, 10 June 2018 (UTC)
• Only if other icons are changed to have a similar flat-coloring scheme — pythoncoder  (talk | contribs) 14:23, 11 June 2018 (UTC)
  • What is more important than style is having some amount of consistency. — pythoncoder  (talk | contribs) 19:24, 12 June 2018 (UTC)
• Neutral because there doesn't really seem (to me) to be any point to it; the original and the (second suggested) replacement are very similar, so why bother? As mentioned earlier, if this is about changing and old style for a new style/fad, it's not worth it. Happy days, Lindsay^Hello 14:54, 18 June 2018 (UTC)
• Oppose - I wouldn't be devastated, but the lighting/texture effect is pleasant on this one and I wouldn't say the new one is any nicer. While the proposal is clearest, the current ones are more than clear so I don't think any change is beneficial. Nosebagbear (talk) 15:11, 18 June 2018 (UTC)
• Oppose The new one looks less modern and more like the simplest shape someone could make on MS paint. The old one is already clean enough. Natureium (talk) 18:34, 18 June 2018 (UTC)

Changing scale icon

This is proposal to replace scale icons () with the emoji one version () Ladsgroup^overleg 17:33, 3 June 2018 (UTC)

• Support as proposer. Ladsgroup^overleg 17:33, 3 June 2018 (UTC)
• Oppose - this icon is used to signal a lack of neutrality, for that the unbalanced scale seems more appropriate. --Khajidha (talk) 00:22, 5 June 2018 (UTC)
• Oppose an unbalanced scale should be used to show lack of balance or neutrality. Graeme Bartlett (talk) 02:40, 5 June 2018 (UTC)
• Oppose per above. Jjjjjjdddddd (talk) 16:06, 7 June 2018 (UTC)
• Oppose per above: The replacement is missing the point. ~ ToBeFree (talk) 01:06, 10 June 2018 (UTC)
• Oppose per above. Not really what we need. — Javert2113 (talk; please ping me when you reply) 01:27, 10 June 2018 (UTC)
• Oppose per Graeme Bartlett. — pythoncoder  (talk | contribs) 14:03, 11 June 2018 (UTC)
• Snow Oppose The one we have now not only looks better but is also unbalanced as per above. - Knowledgekid87 (talk) 14:22, 11 June 2018 (UTC)
• Oppose Clearly, as pointed out above, the replacement is inferior. Happy days, Lindsay^Hello 14:54, 18 June 2018 (UTC)

Consistency

Please suggest replacements for the following icons as well.

• 
• 

Thanks ~ ToBeFree (talk) 01:06, 10 June 2018 (UTC)

Wouldn't the replacement for the orange information icon simply be the same as the blue one but with the color changed? And what is the point of having the hand up as well as the Stop sign? Wouldn't one part or the other be sufficient on its own? --Khajidha (talk) 13:21, 13 June 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.

Proposal for closing the Simple English Wikipedia

There is currently a proposal on Meta for closing the Simple English Wikipedia at meta:Proposals for closing projects/Closure of Simple English Wikipedia (3). All are invited to participate. TonyBallioni (talk) 17:29, 19 June 2018 (UTC)

Questionnaire for new users

When new users start using Wikipedia, how about giving them a questionnaire? This could have questions such as "Did you find Wikipedia easy to edit?" "Were you aware that you could look at the history of an article?" "Did you find the talk page useful?" "Were you aware of Wikipedia: Articles for deletion?" "Were you aware of Wikipedia: Requested articles?" In the long run, the goal of such a project would be to help to improve Wikipedia. Vorbee (talk) 20:03, 22 June 2018 (UTC) I appreciate that a problem with this suggestion could be working out where such a questionnaire would be. It could go on a new user's user-page. Vorbee (talk) 08:17, 25 June 2018 (UTC)

@Vorbee: See WP:User survey. --Ahecht (TALK
PAGE) 15:20, 25 June 2018 (UTC)

Website allows users to place any number of Wikipedia articles on timelines

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.

---

With minimal effort, this website allows anyone to create attractive and interactive timelines out of any Wikipedia articles.

http://wikitimelines.net

Thanks Jeffrey Roehl <email address redacted> Jroehl (talk) 20:11, 26 June 2018 (UTC)

When I click the link, I get nothing (using Firefox 60.0.2), so I assume this is spam of some kind? Matt Deres (talk) 21:48, 26 June 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 not spam. We love Wikipedia (who doesn't?)

We have not tested any other browser but Chrome at wikitimelines.net.

We are just trying to see if there is any interest in this sort of thing.

We will write a proposal if there is.

Thanks Jeff Jroehl (talk) 22:01, 26 June 2018 (UTC)

Wikipedia is a great socialistic project for all the people. Therefore, you will find the best reception using the non-profit people's browser, Firefox. Chrome is something I think of catching from a drive-by download like a computer virus, though I suspect Google Update uses more system resources than the average virus... Wnt (talk) 21:15, 1 July 2018 (UTC)

WP:NOTMEMORIAL Victim lists in mass tragedy articles - Round 2

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 issue of victim lists in mass tragedy articles was adressed before and the consensus was that these scenarios should be handled on a case-by-case basis. I believe the issue needs to be addressed again to finally reach global consensus due to the fact that each mass tragedy articles become a constant struggle amongst editors supporting or opposing the inclusion of a victim list. There is also another issue where outcomes of a consensus on a specific article does not count as consensus for later articles, so the back and forth edits and fights never end. Current RfC

Current language of WP:NOTMEMORIAL: Memorials. Subjects of encyclopedia articles must satisfy Wikipedia's notability requirements. Wikipedia is not the place to memorialize deceased friends, relatives, acquaintances, or others who do not meet such requirements.

I propose that we add a line to WP:NOTMEMORIAL that would either allow or prohibit listing individual victims of mass tragedies if they do not meet our notability guidelines and/or WP:BLP and they are covered in the media as part of the story of the mass tragedy event. This proposal, if approved, would also override any local consensus and precedents. Long lists containing more than 20 names should be contained in a collapsed section.

   Support = Will allow inclusion

   Oppose = Will prohibit inclusion

Cheers, --Bohbye (talk) 21:52, 23 May 2018 (UTC)

Memorial:Support

• Support as nominator. --Bohbye (talk) 21:53, 23 May 2018 (UTC)
• Support - I continue to say that the victims are notable in the context of the given event. This isn't just someone creating an article in order to remember their deceased loved one or friend. - Knowledgekid87 (talk) 04:04, 24 May 2018 (UTC)
• Support — I'm reading this proposal as "allow" not "require," since that's what it says. I don't expect adding a line to WP:MEMORIAL stating this will end all disputes over victim lists. However, right now these disputes often boil down to

Proponent: I think we should have a victim list due to X, Y, and Z.

Opponent: I don't think we should have victim lists because of WP:MEMORIAL

Proponent: That's not my reading of WP:MEMORIAL.

Admin closer: No consensus.

This is simply not a helpful pattern. If WP:MEMORIAL included something like the following it would help: "This policy does not prohibit the inclusion of lists of victims of tragic events, if they serve an encyclopedic purpose, appear in reliable sources, and are compliant with other Wikipedia policies. These lists should be written to provide relevant information, rather than memorialize the lives of the victims."--Carwil (talk) 18:46, 24 May 2018 (UTC)

• @Carwil:

Proponent: I think we should have a victim list due to X, Y, and Z.

Opponent: I oppose per WP:MEMORIAL.

Proponent: MEMORIAL says we can have the list if it serves an encyclopedic purpose, appears in reliable sources, and is compliant with other Wikipedia policies.

Opponent: I disagree that the list serves an encyclopedic purpose.

Uninvolved closer: No consensus. (or the closer counts votes and calls it a consensus) ―Mandruss ☎ 17:58, 11 June 2018 (UTC)

I think the revised conversation is better, since the opponent has to explain how it serves no encyclopedic purpose. Of course there will still be disagreements but there is room for compromise and consideration of the page at hand.--Carwil (talk) 22:53, 11 June 2018 (UTC)

It it easy to "explain how it serves no encyclopedic purpose" convincingly enough for your argument to count as much as any other in the eyes of the closer. Many editors have done exactly that. There is no clear Wikipedia definition of encyclopedic purpose. Therefore your suggestion would change nothing. ―Mandruss ☎ 23:06, 11 June 2018 (UTC)

Support as 2nd choice. A mandatory rule that overrides local consensus and past precedent is a horrible idea that will require absurd and illogical outcomes. However, if the community decides to create a mandatory rule, I’d prefer for it to be inclusion for two reasons. First, this is more in-line with common practice on Wikipedia (particularly with school shootings) and will require less clean-up. Second, many tragedies are notable because of the specific victims (such as the 1943 Gibraltar B-24 crash, which killed many leaders of the Polish Government in Exile). In these cases, it is incredibly important to know the names of at least some of the victims. Further, many notable people (particular those from non-English speaking countries) do not have articles, so we’d have to hold a pre-emptive AfD for many entries into the victim list. Spirit of Eagle (talk) 19:40, 2 June 2018 (UTC)

I realized that a mandatory inclusion rule would require victim lists for pandemics such as the 1918 flu pandemic (50 million deaths, minimum), natural disasters such as the 2004 Indian Ocean earthquake and tsunami (230,000 deaths, minimum), and genocides such as the Rwandan Genocide (500,000 deaths, minimum). Most commenters in this RFC agree that victim lists are appropriate in some articles but not others; the main dispute here is over the proportion of articles in which victim lists are appropriate, not whether they are appropriate period. I think this RFC would have been more helpful if it proposed a default rule that could be overruled with local consensus instead of a mandatory rule that must be obeyed even in illogical situations. Spirit of Eagle (talk) 20:47, 2 June 2018 (UTC)

• Support — if already in place, would have avoided so much drama in Troubles-related articles over the years. There is nothing to prevent inclusion of relevant lists, in collapsible boxes if necessary, and a list of names included on a WP:NOTPAPER WP article is not a "memorial." Bastun^{Ėġáḍβáś₮ŭŃ!} 08:55, 28 June 2018 (UTC)
• Support/Comment/Reject as Malformed - this looks like a dirty trick to me. I think most people are reading this to think that "support" means they have to include a victim list, and balking at that excessive outreach, when in reality "support", misleadingly, seems to have the effect of "allow", i.e. maintain the status quo. I insist that a change in policy should not be accomplished by getting a majority of Oppose votes on a "proposal" -- otherwise every wikilobbyist will be doing it. And for what it's worth, I "support" allowing the list of victims every time. I think Wikipedia made a mistake back in 2001 when it invented WP:NOT and abandoned the idea of hosting an enduring 911 memorial that tried to collect what was known about all the victims. Wnt (talk) 21:25, 1 July 2018 (UTC)
• Support since, as stated above, "support" means "allow", while "oppose" means a blanket prohibition. Davey2116 (talk) 04:07, 2 July 2018 (UTC)

Memorial:Oppose

• Oppose, policy is meant to be descriptive, not prescriptive. As it stands, this type of information gains consensus to be included in some articles and fails to in others, so there is clearly no consensus that this should always or never be added. Therefore, case by case discussion, as is current practice, is the proper way to settle it. Seraphimblade ^{Talk to me} 22:17, 23 May 2018 (UTC)
  • Seraphimblade, I'm not sure that your response matches the description above for what "oppose" is supposed to mean. WhatamIdoing (talk) 02:55, 24 May 2018 (UTC)
• Oppose, the victims of mass tragedies are (generally) not notable, they are simply the people who happen to be in the area when the event occurs. Even in the case of mass shootings (where this debate keeps popping up), most of the perpetrators are not targeting specific people, they are simply killing anyone in the way. Obviously there are some minor exceptions. The vulcanologist who was killed by the eruption of Mount St. Helens while collecting data, a newscaster who is blown away by a tornado while on air, a passenger on a jet who attempts to stop hijackers, a shooting victim who was called out by name in the perpetrator's manifesto. But notice that these are highly specific things. For most victims of these tragedies the story would have been exactly the same if anyone else had been there and their names give us no real extra data. --Khajidha (talk) 11:58, 24 May 2018 (UTC)
• Oppose but with appropriate exceptions. We should encourage editors to avoid these, unless there are reasonable circumstances, notably that if discussing the event that it is impossible to do so without mention some of these people. --Masem (t) 02:30, 25 May 2018 (UTC)

• @Masem: My understanding is that this is about complete lists of names and ages, not prose about selected notable victims. They are separate issues and I think most opponents of the former do not oppose the latter outright, although we might disagree on the meaning of "notable". In my opinion your !vote is the same as mine in the following subsection. ―Mandruss ☎ 02:36, 25 May 2018 (UTC)

• Oppose, lack of notability. — Preceding unsigned comment added by Edibobb (talk • contribs) 02:08, 27 May 2018 (UTC)
• Oppose, with appropriate exceptions per Masem and Khajidha. The status quo, however attractive it may seem to !vote for, has not served as well, and provides a justification for battleground that is really unnecessary. The wording should at least strongly discourage the practice of inclusion. No such user (talk) 13:35, 31 May 2018 (UTC)
• Oppose. For the normal reader it is an utterly meaningless and worthless list of names randomly pulled out of the phonebook (with my apologies to the family and friends of the deceased). For the normal reader, it serves absolutely no encyclopedic purpose. Name(s) should only be included where it provides some identifiable and distinctive purpose for a generic reader. If it's a relative of the perpetrator, or a celebrity who gets individualized news coverage, or one of Khajidha's examples, it makes sense to have a textual-discussion of those individuals. To make the point reducio ad absurdum, there's no reason we should treat the victims of a mass shooting any differently than the victims of 9/11. A list of 20 random names is just as useless as a list of 2,996 random names. Alsee (talk) 00:53, 1 June 2018 (UTC)
• Oppose - 2nd choice because there should be explicit provision for exceptions. Superior to status quo, however, per my comments elsewhere in this proposal. ―Mandruss ☎ 01:25, 1 June 2018 (UTC)
• Oppose a list of the names of non-notable people who were killed in an event has no point other than to memorialize the victims in question. While I feel for the people involved, that is not the point of an encyclopedia. Cataloging the victims of various of events is a noble pursuit, but is more suited to another venue. My conclusion would be to prohibit victim lists unless the victim meets general notability requirements. It is either that or we have to decide where to draw the line. Does every soldier who died during a battle get listed in an article about the battle? How about everyone killed by the Nazis at Auschwitz in it's article? The list could do on. {{u|zchrykng}} {T|C} 05:39, 5 June 2018 (UTC)
• Oppose, If for no other reason then who gets to decide what is deserving of such memorials? Victims of Terror, Mass shootings, collateral damage? Too much room for edit warring and POV pushing.Slatersteven (talk) 15:41, 6 June 2018 (UTC)
• General oppose including lists of nn individuals, as (indiscriminate amount of information). Victim lists should include those who are independently notable, i.e. blue-linked. There may be a section in the articles on the victims - covered as a group / individually, depending on the depth of sources for specific individuals. I find the exhaustive lists not only excessive, but also potentially disrespectful to the relatives. --K.e.coffman (talk) 01:00, 23 June 2018 (UTC)
• Oppose, in general for lack of notability and per WP:Memorial. Kierzek (talk) 19:54, 23 June 2018 (UTC)
• Oppose introduction of lists of non-notable victims as they are almost always un-encyclopedic and incompatible with the letter and spirit of NOTMEMORIAL. I am fine with an external link to an appropriate memorial website or list of victims. But such lists don't belong in articles. -Ad Orientem (talk) 19:37, 26 June 2018 (UTC)

Memorial:Alternatives

• Status quo Continue deciding ona case-by-case basis. Beeblebrox (talk) 01:38, 24 May 2018 (UTC)
• Status quo One-size-fits-all policies are rarely useful at Wikipedia. --Jayron32 02:28, 24 May 2018 (UTC)
• Status quo, since apparently "oppose" doesn't actually mean, well, "oppose", but I oppose making such a change. Policy is meant to be descriptive, not prescriptive. As it stands, this type of information gains consensus to be included in some articles and fails to in others, so there is clearly no consensus that this should always or never be added. Therefore, case by case discussion, as is current practice, is the proper way to settle it. Seraphimblade ^{Talk to me} 22:17, 23 May 2018 (UTC)
• Status quo - 2nd choice. - Knowledgekid87 (talk) 04:04, 24 May 2018 (UTC)
• Default to omit, exceptions by local consensus - There was a minor but distracting outcry of "Not this again!" when the list was disputed at Santa Fe High School shooting, and the RfC for that case is underway. If "Status quo" or "no consensus" is the result here, it must be stressed that "Not this again!" is inconsistent with that result and thus an invalid complaint. If the community kicks this decision down to article level, despite the fact that the relevant factors and circumstances are essentially the same in each successive case, then the community is saying it must be re-litigated at each successive case. I oppose that as a waste of editor time, and I support omission as default with provision for exceptions by local consensus. The difference between that and the simple "decide case-by-case" is that any arguments for exception would be required to show what is unusual about the case that justifies exception to the default. My rationale for supporting omission rather than inclusion as default is found here (first !vote). ―Mandruss ☎ 04:09, 24 May 2018 (UTC)
• Status quo. Continue deciding on a case-by-case basis. One-size-fits-all policies are rarely useful at Wikipedia. Case by case basis with no default rule. Some take WP:NOTAMEMORIAL way out of context. It is meant to shut down stand alone bios on deceased friends and family. It is not meant to exclude the mention of a murder victim name within the context of a page about a notable crime. Bus stop (talk) 05:38, 24 May 2018 (UTC)
• Omit excepting strong local consensus I'm not entirely sure what adding a comprehensive list of victims adds to an article, and as some users commented at the last RfC, it may be seen as disrespectful to mention people purely for how they died (WP:BLP1E). If some victims are notable for other reasons, sure it may make sense to list them. However, there may well be cases where listing all victims makes encyclopedic sense, and local consensus should be sovereign where it exists. Richard⁰⁶¹² 12:46, 24 May 2018 (UTC)
• Generally Support Inclusion I think generally murder victims names and often ages (which helps distinguish the victum from other people with the same name) are an important part of every murder story that are almost always covered by reliable sources repeatedly. We have almost always covered the victim names for other notable murders like Golden_State_Killer#Original_Night_Stalker There is a trend in the media to even deemphasize the killer's name and emphasize the victims for notoriety reasons. Some take WP:NOTAMEMORIAL way out of context. It is meant to shut down stand alone bios on deceased friends and family. It is not meant to exclude the mention of a murder victim name within the context of a page about a notable crime. Do to privacy and accuracy reasons I do not support releasing victim names before they are released by law enforcement and published in RS or the listing of all wounded victims, which needs to be considered on a case by case basis. If child Mary Jones is shoot in the leg and survives she does not need to be named on wikipedia but if Jane Smith gets shot and earns an award for heroism we may well name her. Legacypac (talk) 12:48, 24 May 2018 (UTC)
• Status quo. The current wording, which in general would appear to prohibit the mass listing of names, but would allow for it if there were a good reason (mainly notability), seems fine.  — Amakuru (talk) 12:59, 24 May 2018 (UTC)
• Status quo - Case by case basis with no default rule. I have supported inclusion on the two most recent mass shooting pages I have participated in, but I see examples where it was decided to exclude the names, and if there is another situation where that is what the consensus is decided to be I have no problem with it. WikiVirusC^(talk) 13:22, 24 May 2018 (UTC)
• Status quo - Should be done on a case-by-case basis, Seems the logical answer..... –Davey2010^Talk 14:10, 24 May 2018 (UTC)
• Status quo - There are some cases where setting notability as a threshold would be a good idea. But, there are other cases, like where there are seven or so victims, and one notable person among them, when including the names of all killed would be a fine idea. Overall, having a guideline to cite isn't very good when that guideline has lots of good exceptions. RileyBugz^{私に叫ぼう}_私の編集 20:13, 24 May 2018 (UTC)
• Status quo I'd suggest that it mostly depends on the number of names, if there are only a handful then it makes some sense to include them, if there are hundreds then it probably isn't a good idea. There are other factors that could affect the decision though. Hut 8.5 20:30, 24 May 2018 (UTC)
• Default to include, allow exclusion per local consensus After every major shooting, we seem to have the exact same debate about whether to include a list of victims. The debatealmost always centers around the same general arguments rather than the details of the specific shooting. Having to debate the same point again and again is a waste of time and is starting to ware on the nerves of many editors. Establishing a default rule instead of continuously debating the same point would be in the best interest of Wikipedia. I would prefer for the default rule to be inclusion of the lists for the reasons I explain here [2]. Spirit of Eagle (talk) 01:51, 25 May 2018 (UTC)
• Status quo These are the type of articles where the need for editorial judgement is the greatest. Drawing lines in the stand is rarely useful. Cullen³²⁸ Let's discuss it 07:32, 25 May 2018 (UTC)

• These local discussions are never about the characteristics of the case. They are regurgitations of the same general arguments about victim lists, over and over. The result depends merely on the mix of the editors involved in the local decision. And there are always many editors who !vote based largely on precedent, as if that showed a community consensus, when in fact it does not. If there were such a community consensus, it would be affirmed in discussions like this one. The status quo is a mess, and the only way to resolve it is to reach a community consensus for something other than status quo. ―Mandruss ☎ 08:09, 25 May 2018 (UTC)

• Status quo Bearing in mind that WP:BLP1E still applies in the "breaking news" phase. I know that's aimed at articles, but the last thing I want to happen is for us to repeat an innaccurate list, potentially causing great distress to an affected family. There are some articles that a list of the victims just doesn't make any sense - e.g. The Holocaust. At the same time, sometimes it makes sense. ∰Bellezzasolo✡ Discuss 20:03, 2 June 2018 (UTC)
• Status quo Going to squeeze in just under the wire to note that a case-by-case basis simply seems the most logical to me. — Javert2113 (talk; please ping me in your reply on this page) 18:43, 6 June 2018 (UTC)
• Depends. Do what the historical secondary sources say — if they report a list of names, that's reasonable, but if not, don't. And don't go advocating the fringe theory that news reports are secondary sources: I'm talking secondary sources as defined by professionals. Nyttend (talk) 02:17, 9 June 2018 (UTC)
• Status quo, Proposal options are inappropriately Procrustean. Allow listings only when they are demonstrably encyclopaedic or significantly clarify an encyclopaedic point. Burden on the editor wishing to include to show this is the case. Decision by standard talk page consensus. · · · Peter (Southwood) ^(talk): 14:48, 22 June 2018 (UTC)

• Status quo A case-by-case basis is best. As noted below, there are many cases when a list is appropriate, and good reasons why me might decide to limit or omit a list. Hawkeye7 (discuss) 21:41, 1 July 2018 (UTC)

• Status quo, use existing guidelines WP:LISTBIO and WP:LONGSEQ already provide guidance that exhaustive lists should not be used if the same items would not be accepted if written as prose. Lists are a form of presentation, not an excuse to mention trivial items.—Bagumba (talk) 09:44, 2 July 2018 (UTC)

Memorial:Neutral

Memorial:General discussion

The two suggested "votes" may be confusing people. The options might be better framed like this:

1. Require victim lists (if verifiable; WP:SPLIT to a stand-alone list if large)
2. Decide separately for each article (permitted with consensus; status quo)
3. Prohibit (no lists, except in extraordinary situations)

If people can be clear about what they mean in their comments, that would probably be more helpful than "support" or "oppose". WhatamIdoing (talk) 03:05, 24 May 2018 (UTC)

Victim lists have long been an issue. I was involved in a related local discussion nearly 5 years ago which had some interesting points raised. Cesdeva ^(talk) 11:47, 24 May 2018 (UTC)

Well it appears that nothing has come out of this discussion, the issue is going to continue to be fought out and re-discussed to death. Sorry if I sound pessimistic here but I have seen it play out now many times from both sides presenting the same arguments. Why would one school shooting for example be different than another with the same talking points presented? - Knowledgekid87 (talk) 17:28, 29 May 2018 (UTC)

Remarkably, at least one editor—an editor with extensive experience—has declined to help form a consensus with the rationale that there is no consensus. Apparently, avoiding pointless expenditure of editor time is seen by many as an improper use of community consensus. ―Mandruss ☎ 23:48, 29 May 2018 (UTC)

Are you seeing something above that implies anything other than the status quo (no change)? This has been discussed in one way shape or form for years now, something is going to have to give eventually. - Knowledgekid87 (talk) 17:42, 4 June 2018 (UTC)

@Knowledgekid87: I'm not sure I understand the question. If you're asking how I read the consensus to date, of course it leans toward status quo. If the trend holds, I know WP:how to lose and I'm resigned to the continued waste of time, but I will respond negatively to further "Not this again!" protests at article level. This will be the clear will of the community, and every editor should respect it. ―Mandruss ☎ 18:21, 4 June 2018 (UTC)

I suggest the closer apply extra care evaluating individual responses. We have a striking situation where there are !votes in three different sections all saying the exact same thing: names can be included if they serve an encyclopedic purpose. People are just coming at it from different angles. If we get stuck with yet another RFC on this same question I suggest extra effort to more clearly articulate that position. The current drafting looks too much like "Always include all names" vs "Never include any names". Alsee (talk) 01:08, 1 June 2018 (UTC)

Agree that the framing is poor, as might be expected from a very-low-time editor. I offered to collaborate on framing and my offer was ignored. But to me the drafting looks like "prohibit lists" (Oppose) vs "don't prohibit lists" (Support). In any case, I think it was clear from the start that the question is about complete lists of names and ages; that's what "victims list" means. It is not about prose about selected notable victims, and I'm pretty sure that some !voters have missed that essential point. It certainly is not about lists of names and ages of selected notable victims with no explanation for what makes them notable; that should never be on the table for obvious reasons. ―Mandruss ☎ 01:47, 1 June 2018 (UTC)

@Alsee:, @Mandruss:: I think Alsee has the correct read of responses posted here and Mandruss has the correct read of the proponent's intent in writing the RfC. Above, I tried to offer a succinct clarification of the policy that summarizes when victim lists are appropriate: ""This policy does not prohibit the inclusion of lists of victims of tragic events, if they serve an encyclopedic purpose, appear in reliable sources, and are compliant with other Wikipedia policies. These lists should be written to provide relevant information, rather than memorialize the lives of the victims." I could offer this as the basis for a future RfC, or we could refine it here, and then have an RfC about it. What do people think?--Carwil (talk) 19:30, 12 June 2018 (UTC)

Most of the opposition to victims lists is that they inherently do not "serve an encyclopedic purpose", so I don't know what that would accomplish. Victims lists either generally serve an encyclopedic purpose or they generally do not, and that is something that can and should be decided, at community level, for all victims lists in mass killing articles (with provision for rare exceptions).
Further, closers cannot read the minds of the participants, and forgive me for believing that many supporters whose desire was to memorialize the victims would say that their aim was to serve an encyclopedic purpose, if that's what it took to get a list included. Ends justify means, very often. ―Mandruss ☎ 20:24, 12 June 2018 (UTC)

Carwil if the closer has trouble extracting a clear result here, then I agree with your suggested followup RFC. However I think your text needs adjustment. When writing policies&guidelines it's often key to write for the audience who is motivated to not-find the answer we're trying to provide. You essentially wrote that uncontroversially-good content is permitted, and an over-enthusiast-list-maker can argue that your text says nothing against their list. I suggest starting with a default that victim names are generally inappropriate, then add "unless..." to allow names with a genuine purpose. I think consensus is that, in a disputed case, the person adding names is expected to offer a credible rationale beyond "listing victims". Alsee (talk) 01:35, 13 June 2018 (UTC)

Agree with Mandruss. The entire point is that these lists of names are not encyclopedic content. Individual names may serve an encyclopedic purpose, but the burden of proof should be to show that mention of each name (individually) serves an encyclopedic purpose. --Khajidha (talk) 15:53, 14 June 2018 (UTC)

Agree with Khajidha on specifics directly above. Have not examined all of Mandruss' arguments sufficiently to form a definite opinion on them, but those just above look rational and to the point. · · · Peter (Southwood) ^(talk):

@Pbsouthwood: This comment is interesting considering that your "status quo" !vote is diametrically opposed to both mine and Khajidha's. ―Mandruss ☎ 01:15, 23 June 2018 (UTC)

The proposal options are so badly expressed as to be inappropriate. Status quo is the default option. In Afrikaans there is nn expression "Kak vraag, vra oor", which basically rejects the question and requests rephrasing to make it answerable. Cheers, · · · Peter (Southwood) ^(talk): 17:06, 23 June 2018 (UTC)

@Pbsouthwood: Agreed, but I don't think the community would respond favorably to another run at this at this time, or most likely for another two years minimum. In my experience the community's attitude in such situations is: "You botched it? Too bad. We're tired of discussing it." The #Memorial:Alternatives section at least appears to free responders from the chosen framing if they don't like it. ―Mandruss ☎ 19:52, 23 June 2018 (UTC)

• I think that the Oppose voters are right that a list of names is of relatively little use, "like a phonebook". Not no use, since it is still a way to cross-reference some facts, but yes, I want more. I think these articles should routinely cover published details about the victims the same way they cover published details about the shooters. I don't at all get the people who claim that the shooters deserve Wikipedia coverage because they were an "active party" whereas the victims, being just "passive", should be effaced and forgotten. The victims played as much a role as the shooter - their biographical details are just as important to understanding the scope of the tragedy - and they have a damn sight more sympathy from the readers. Wnt (talk) 21:31, 1 July 2018 (UTC)

What we usually do, in practice

I'm feeling a little tired of this particularly perennial discussion topic, so while my already-delayed lunch is getting delayed a little longer, let me see if I can shed a little light on what happens, in practical reality.

We include lists when:

1. The list of victims is short. A "mass killing" can mean as few as four victims to be named. When there are just a handful of victims, it's weird to write 5,000 words about the event but only mention the perpetrator by name. Most notable mass tragedies do not have a victim list that runs even into the dozens, much less hundreds or thousands.
2. The victims' identities are relevant. There is a victim list in the very first sentence of Execution of the Romanov family. In more ordinary cases, we will have victim lists that read like "He killed his ex-girlfriend Grace, her new boyfriend Bob, and Larry Law, a police officer who responded to the emergency call. Her parents, Alice and John, survived their injuries".
3. Some of the victims are independently notable. This may be a partial list ("230 victims, including Alice Expert, Joe Film, and Paul Politician") or it may be complete (four notable victims and a non-notable junior-level staff member or the non-notable emergency personnel who died trying to save them – when a complete list is feasible, it's inhumane to say that only a small fraction is too unimportant to name).
4. Naming the victims makes it easier to keep track of the tragic events (e.g., Colonel Mustard first killed Miss Scarlet in the library, and then Mrs White in the kitchen. The next day, he killed Prof. Plum in the study, and Mrs Peacock in the ballroom).
5. Naming (some or all of) the victims helps explain subsequent events and people, e.g., why a "Smith and Jones Families Memorial Scholarship Fund" was created, or why all the sources keep talking to Mary Mother.

We don't normally include lists when:

1. The list of victims is long.
2. The victims were largely innocent victims/random targets.

Does that feel about right, when you think about the breadth of articles we write? WhatamIdoing (talk) 20:59, 21 June 2018 (UTC)

Sorry, but who's "we"? Clearly we've participated in different subsets of the whole. I and other editors that I have observed don't see it that way at all. In my subset experience, a large majority of editors either want the lists in all mass killings articles, or none, with some editors allowing for rare exceptions. If you want to propose the above usage, then propose it, but please don't frame it as an unwritten community consensus. I would oppose the proposal. ―Mandruss ☎ 21:13, 21 June 2018 (UTC)

Point by point: 1) Seems perfectly normal to me to not name people who have no notability beyond being the ones who just happened to get killed (as opposed to being specifically targeted), 2) These are targeted deaths, so yes they belong, 3) A partial list would be appropriate, but your "inhumane" is simply another way of saying "We must memorialize them" and that is against policy, 4) seems like "the perpetrator killed one person in the library, then another in the kitchen. The next day, he killed someone else in the study and a fourth person in the ballroom." is just as clear, 4) the namesakes of such a fund would be notable, but Mary Mother should just be "the mother of one of the victims". --Khajidha (talk) 13:28, 22 June 2018 (UTC)

Let me second WhatamIdoing's general rubric, which strikes me as strong. As I've said before, names are the easiest way of keeping track of victims, motives, and involvement in a complex event where the deaths were anything other than simultaneous and indiscriminate. In cases where the shooter targeted certain individuals and avoided targeting others. These are encyclopedic details best indexed by naming the victims involved. Note that when deaths are simultaneous and/or indiscriminate, these reasons don't apply.

Here's the nub of our disagreement about "memorializing"… When the victim list is short and several people are individually notable, and demographic characteristics are part of reliable source coverage, it's best to just use names and basic characteristics to record the whole list. In my understanding, WP:MEMORIAL prohibits eulogizing the dead unduly, not listing them where it is relevant and/or clarifying.--Carwil (talk) 04:24, 26 June 2018 (UTC)

"In cases where the shooter targeted certain individuals and avoided targeting others." But do we actually know that certain individuals were targeted or is it just that only certain people happened to be killed in an area? If I go into an office and yell out "Spacely! I'm coming for you!" that is one thing, if I go into an office and fire one shot that happens to kill Mr. Spacely that is another. Without explicit confirmation from the shooter (words spoken at the time, manifesto written beforehand, or statement given after the fact) I don't think we can assume that someone is targeted, even if they were the only one killed in that area. "When the victim list is short and several people are individually notable, and demographic characteristics are part of reliable source coverage, it's best to just use names and basic characteristics to record the whole list." Nope. Un uh. Record individuals who are notable outside of the event, record individuals who were specifically targeted, and say something like "18 others, including 5 women and 4 children under 12 were killed. Victims included a wide variety of ethnicities." THAT is much clearer and avoids any emotionalism or personal attachment. --Khajidha (talk) 15:09, 26 June 2018 (UTC)

I also find it telling that everyone arguing for inclusion keeps going back to mass shootings. It seems people can accept that most deaths are just deaths if it's a flood, fire, earthquake, etc, but can't seem to accept that most of the people killed in one of these shootings weren't targets and didn't matter to the shooter. They were just the chunk of matter that happened to be in the pathway of the bullet. --Khajidha (talk) 15:24, 26 June 2018 (UTC)

They're more than "chunks of matter", they're people and they matter. If somebody gets swallowed up by a crack in the earth or run over by a self-driving golf cart or shot by the township's newest blind police officer, we want to know who it was. And if there were three or ten or fifty somebodies, we want to know as much about them as is practical to collect. Because it matters whether the people shot were moms watching their kids at the mall or drunk frat boys out on the town, whether the lovers were just engaged or going to be married next week. It gives a sense of the scope and purpose and purposelessness and tragedy and beauty of life. But most importantly, it's reliably sourced and some editor cared to source it, or it's not here! And that by itself should be enough to want to keep it. Wnt (talk) 21:36, 1 July 2018 (UTC)

All of which is just another way of saying "we should memorialize them". Sorry, no. As far as their participation in these tragedies go, they generally aren't "people". The deaths did not target them personally and individually. They just happened to be there at a bad time. Who they were is no more relevant than who the people who were killed in the ancient eruption of Vesuvius were. And we also have a policy that being reliably sourced is necessary, but not sufficient for inclusion. --Khajidha (talk) 23:12, 1 July 2018 (UTC)

No, I don't agree.

The reason that we keep going back to mass shootings, rather than natural disasters, is that the list of victims tends to be short, and the killer usually does target the victims personally and individually (or at least representatively). That means that both #1 and #2 in the "include" factors will get considered.

When a volcano kills hundreds of people in a given area, what you need to know, to really understand that event, is that hundreds of people in a given geographic area were killed. Ideally, you would learn something more about who survived and who didn't (e.g., this group survived because they were out of town, rich people could drove away before the hurricane hit, poor people were locked in the bottom of the sinking ship), but that's a classic example of when we don't usually include a victim list: it's long, and the victims are more or less random. By contrast, when a mass murderer killed the five newspaper employees recently – well, it turns out that they didn't "just happen to be there at a bad time". They were killed because of a particular aspect of their identity.

Here's the thing: most mass killings aren't just random victims. Most killings involve a small number of people who are connected to the killer. In fact, to get away from mass killings to everyday individual murder, if you encounter a murdered woman in the US, you can, without knowing anything else at all, safely bet that murderer was a current or recent boyfriend (or husband). You don't even need to know whether she ever had a boyfriend before you place your bet. That's how rare random murder is. WhatamIdoing (talk) 06:36, 2 July 2018 (UTC)

They were killed because of a particular aspect of their identity Right, and that aspect was that they worked at that newspaper, which can be conveyed without listing their names and ages. In fact, their names and ages say exactly nothing about where they worked.
The same principle applies to most school shootings. At Stoneman Douglas, for example, the only connection all victims had to the shooter was that they all attended Stoneman Douglas at one time or another. Again, names and ages have nothing to do with that connection. I've seen no information that he even knew any of the victims beyond a passing-in-the-hall "acquaintance", let alone singled anybody out. Even if they single out some victims, that is no reason to list names and ages of all of them, which is the issue under discussion here. ―Mandruss ☎ 07:04, 2 July 2018 (UTC)

Exactly, Mandruss. --Khajidha (talk) 09:22, 2 July 2018 (UTC)

@Khajidha: You say "The deaths did not target them personally and individually". To the contrary, the deaths absolutely did target them personally and individually; nobody else died in their place. Possibly the killer didn't intend them specifically to be his victims -- though we don't really know that. But they sure as shit didn't intend the psycho to be their killer, so does that mean he isn't worth mentioning in the story? If victims are a dime a dozen, so are spree killers! I mean, it just seems like common sense that if you're writing a story about a murder you tell about the killer and you talk about the victim ---- just like our reliable sources do. Wnt (talk) 16:01, 2 July 2018 (UTC)

If a person walks into a room and fires 17 bullets at random, then, no, the people that those bullets kill were not targeted personally and individually. And without explicit statements from the killers, that's the situation all of these school shootings fall into. The killer is an agent, he DID something. The dead had something done to them. --Khajidha (talk) 16:06, 2 July 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.

Throttle edits adding excessive disambiguation links

In my long experience as a disambiguator, I have observed that the larger the number of disambiguation links added in a single edit, the more problematic that edit is likely to be in other respects as well, such as containing copyvios, overlinking, creating a sea of non-notable red-links, adding walls of text, or indiscriminate data dumps. I think an edit that adds more than, say, links to twenty different disambiguation pages should probably at least bring up a notice advising the editor to review Wikipedia's policies and MOS and consider whether they need to adjust their writing before saving the edit. I will add that, out of the hundreds of thousands of edits made on Wikipedia per day, only a handful have this characteristic. Nevertheless, it would quite often save a lot of work if the editor adding the disambiguation links (and likely other issues) would get a heads up, rather than other editors needing to puzzle them out afterwards. bd2412 T 03:36, 28 May 2018 (UTC)

bd2412, that sounds like an excellent idea. The next step would be to put in a request on phabricator. If that doesn't get results, drop me a line on my talk page and I will create a proposal and push them until I get a yes or no answer. --Guy Macon (talk) 08:30, 30 May 2018 (UTC)

• This is in the same vein as various semi-perennial proposals for alerting users before they save certain types of edits: ones that introduce unsourced text, spelling mistakes, etc. In fact, there was a proposal in 2016 for similarly alerting editors when their contributed text contains links to dab pages. To rehash in the current context some of the reasons why these have all failed: 1) they introduces additional hoops for good-faith new editors to jump through (not good in the context of declining new editor numbers), 2) the presence of many dablinks by itself is only a minor problem that can easily be fixed afterwards, and 3) the real problem is the presence of copyvios etc, and these might or might not come along with the type of edit that would get picked up: the software will have no way of telling which edits are problematic and which aren't.
  Also, worth remembering that articles with more than 8 dablinks get swiftly tagged by DPL bot, which places them in Category:Pages with excessive dablinks (which currently has three members), where they can be examined by experienced editors. And the user who introduced any number of dablinks will promptly receive a talk-page notification (unless their edit count is below 100 or they have specifically opted out). – Uanfala (talk) 22:26, 30 May 2018 (UTC)
  • The previous proposal was to throttle the addition of any new dab links. This is for edits adding a relatively high number. To add one or two disambiguation links in an edit is easy. To add more than ten takes a special kind of absence of forethought. I would add that very frequently the sort of editors who add masses of text laden with disambiguation links are the sort who have fewer than 100 edits. Suppose for the sake of argument we were to say that we would do this for edits adding 20 new links to disambiguation pages? Or 50? Or 100 (since I have seen that happen on rare occasion)? bd2412 T 11:52, 31 May 2018 (UTC)
    • I have a lot of sympathy this goal, but AIUI throttling can only be done through the edit filter, which means that it has to be computed on every single edit at the time of saving, and that's expensive (slow) for every single edit. I don't think that the rest of the community would love having every single edit slowed down. WhatamIdoing (talk) 19:42, 8 June 2018 (UTC)
      • Isn't that what the edit filters are already doing? bd2412 T 16:51, 10 June 2018 (UTC)
        • Yes, and that's why we need to do as little of it as we can. Each additional thing to check slows down editing even more. WhatamIdoing (talk) 21:14, 21 June 2018 (UTC)
          • How about a bot that reverts edits with more than 20 dab links in them, and tags edits with more than 10 dab links in them? --Guy Macon (talk) 21:45, 3 July 2018 (UTC)
      • Also, can we at least do something to catch obvious disambig-linking vandalism like this? bd2412 T 16:10, 11 June 2018 (UTC)

Warn on move to protected title

Tracked in Phabricator
Task T85393

I am an admin. If I start to create an article on a title which has been salted so only admins can create, I receive ample warning of what I am doing. But if I move a page on to such a title, I get no warning whatsoever. I have seen several titles where valid protection has been removed in this way. There ought to be some sort of warning, preferably a confirm page showing the block log and with a tick box saying "I realise that this move will remove the existing protection from this title". — RHaworth (talk · contribs) 17:20, 2 July 2018 (UTC)

Presumably, titles are protected because they are unsuitable topics for articles but have been repeatedly created regardless. If you are moving a page to that title, there must be a reason you want to have an article with that title, so why does it matter if the page were salted? Natureium (talk) 17:26, 2 July 2018 (UTC)

Scenario: You're plugging along through a backlog at the AFC review queue, see what looks like a reasonably well-sourced page, and move it into mainspace... over a title that's been deleted at AFD, and then speedied an additional four times as verbatim G4 re-creations in the last month, and then protected from creation for a year, and the draft you just moved in is no improvement. Even if you notice it immediately, it's entirely too easy to forget to reprotect after either deleting the page or moving it back to draftspace. —Cryptic 01:58, 4 July 2018 (UTC)

See (not nearly a complete list): Wikipedia:Village pump (technical)/Archive 42#Moving over a salted page, Wikipedia:Village pump (technical)/Archive 135#Moving over a salted page (redux), Wikipedia:Village pump (technical)/Archive 146#Warning message when moving to a salted title?, Wikipedia:Administrators' noticeboard/Archive267#Warning for admins moving pages to create=sysop pages, phab:T85393. —Cryptic 19:51, 2 July 2018 (UTC)

Guilty as charged:/ DMacks (talk) 19:57, 2 July 2018 (UTC)

@RHaworth: does phab:T85393 address what you would like to see sufficiently? Note, it has been stalled for years pending someone to want to work on it. — xaosflux ^Talk 01:26, 3 July 2018 (UTC)

Revise WP:NPOL so that someone who wins primary qualifies for more information in Wikkipedia

In any election, the incumbent has a great advantage over a challenger. Wikipedia's NPOL policy means that incumbent is by default notable but challenger isn't. As a service to our readers, instead of just re-directing from name of challenger (who at least in the US got some coverage running in primary election) to district race URL, could we not give more information about the race as exemplified for example here?[3] I understand reasoning behind our current model. I do not propose that, after general election, we continue to host info on challengers who are not otherwise notable. I do not propose to change notability criteria for any other categories such as NACTOR etc. But I think we can do better for general elections. What do others think? HouseOfChange (talk) 19:35, 27 May 2018 (UTC)

"I do not propose that, after general election, we continue to host info on challengers who are not otherwise notable." That seems to make the proposal a WP:NOTNEWS violation. We don't temporarily host information just to make races more fair; that's simply not Wikipedia's thing. Huon (talk) 19:39, 27 May 2018 (UTC)

(ec)In an article on the race you can say as much as sources and WP:DUE allow about any candidate, and balanced coverage is good. As to biographical articles, you seem to be suggesting a form of temporary notability, which we don't do. Johnbod (talk) 19:42, 27 May 2018 (UTC)

OK so for example, if you search for Texas candidate Lizzie Pannill Fletcher you end up at page for Texas 7th district, which has zero info about challenger Fletcher but a link to incumbent she will challenge. I am suggesting that such a page (for election) has a section for some links or info about positions of both candidates. I agree with Huon that it will be unnecessarily tricky to create a new category of "temporary notability." I am searching for a way to benefit our readers without requiring painful contortions of Wikipedia principles. HouseOfChange (talk) 20:03, 27 May 2018 (UTC)

The best solution in such a situation is to add neutral, well-referenced information about each of the candidates to the redirect target, describing the race neutrally. Articles about unelected candidates tend to start out as campaign brochures masquerading as encyclopedia articles, and then are often loaded up with cherry-picked negative information added by supporters of rival candidates. It is a mess. Cullen³²⁸ Let's discuss it 20:08, 27 May 2018 (UTC)

I agree 100% with the lively description of Cullen³²⁸ about articles of politicians. Cullen, if you can give an example, on any page you like of what and WHERE such info might go, that would be a great help. Sleepily, from Sweden, HouseOfChange (talk) 20:15, 27 May 2018 (UTC)

In the current case, HouseOfChange, the information can go in the District 7 section of United States House of Representatives elections in Texas, 2018. If you look at sections for other districts, you will see that some have information about various candidates. There could be 36 neutral spinoff articles about the races in all 36 Texas Congressional districts. Cullen³²⁸ Let's discuss it 20:28, 27 May 2018 (UTC)

Thanks, Cullen³²⁸, I do not propose to write 36 spinoff articles, but I will try to wrie one or 2 and see what reception is for them. HouseOfChange (talk) 21:07, 27 May 2018 (UTC)

• Comment generally there haven't been stand-alone articles on US House races, but based on the discussion at Wikipedia:Articles for deletion/California's 39th congressional district election, 2018 it seems that it is permitted, at least for races that generate national-level coverage (normally well-correlated with competitive races).
  As far as notability of candidates: I'm not happy with the current system, but don't see a better alternative yet. Notability is not temporary, and proposals that suggest current candidates are notable but will not be notable after the election are exceptionally unlikely to find consensus. Some candidates (Kara Eastman, Mark Walker) have been kept at AfD recently.
  Finally, as a procedural note, this is a fairly good time to have this discussion; there's enough time before any election that there's no obvious benefit for any political group associated with any policy change, but enough activity to give specific examples rather than hypotheticals. power~enwiki (π, ν) 22:35, 27 May 2018 (UTC)
• Oppose In the case of the U.S. House of Representatives, there are very few competitive seats in any election cycle. Cook estimates that less than 100 of 435 seats are competitive [4] in 2018, for instance. That means that in three-quarters of all U.S. congressional races, the general election challenger candidate will often be either a perennial candidate or someone simply running as a party standard-bearer with no hope or intent of election and no organized campaign. Over the next six years, that means we could potentially accumulate hundreds of biographies of individuals notable for no other reason than they once spent 15 minutes filling out a certificate of candidacy. Further, many general election candidates for congressional office already are usually able to meet notability standards absent this proposal as they will frequently be former state legislators who are inherently notable, or in some other way pass the WP:GNG. Candidates for competitive house seats are rarely unknowns. Chetsford (talk) 04:56, 5 June 2018 (UTC)
• Credible candidates in competitive House races are usually notable—Rather than try to generate a temporary rule, I want to suggest that in a polarized political environment, virtually every credible candidate in a swing district is getting "significant coverage in reliable sources that are independent of the subject of the article." Shortly after the primary, you should be able to defend them using the GNG, which NPOL specifically directs you to do.--Carwil (talk) 19:43, 12 June 2018 (UTC)
• Oppose. I understand the intent is good... so I apologize in advance... but I'm about to cast this in the ugliest light possible. The proposal here is for Wikipedia to give non-notable individuals temporary free campaign advertising, because Wikipedia wants to alter the outcome of elections. I know, the intent is to be "more fair", but I subscribe to a rather purist view of Wikipedia policy. We write policies for strictly encyclopedic purposes, not trying to fix issues out in the world. Individuals who are already notable^{(Donald Trump cough cough)} have an inherent advantage in elections. That is true no matter what we do. We shouldn't screw up our policies trying to fight that inevitable fact. The world isn't fair, we can't solve that. We're also already overloaded with work to do without having to try to manage a highly politicized category of "temporary" articles, especially when they lack the sort of sourcing we require to handle them properly. In some cases we'd have little more than campaign-adverting&attack-counter-advertising as sources to work with. We don't want to cross those streams. It would be bad.^{(Try to imagine all life as you know it stopping instantaneously, and every molecule in your body exploding at the speed of light.)} Alsee (talk) 02:25, 13 June 2018 (UTC)
• Oppose Wikipedia is not in the business of being a voter's guide. Winning a primary is a pretty low bar, and it is not much higher if, in the US, you restrict that to the two main parties' primaries. In the best of times these articles would be partisan battlegrounds and an attractive nuisance for off-wiki trolls and partisans. In short, if they were not notable enough for an article before then simply being successful in their party's selection process does not make them more so. Jbh ^Talk 02:54, 13 June 2018 (UTC)
• Hopefully not needed per Carwil. It really is concerning that Wikipedia might be magnifying the advantages of incumbency (the concern is not so much "fairness" to individual challengers as it is having a realistic prospect of dismissing incumbents). But as others have noted, as encyclopedists per se, that's not really our problem. But hopefully GNG will suffice. --Trovatore (talk) 03:07, 13 June 2018 (UTC)
• Oppose - as a one-time major party nominee myself, I feel this is falsifying our concept of notability. Think of it as the political equivalent of BLP1E. --Orange Mike | Talk 03:14, 13 June 2018 (UTC)
• Oppose per all of the above, and biasing our rules to advantage subjects from one country is flat-out not acceptable. This proposal is tailored to suit the peculiarities of the US election system, and that makes it prima facie unacceptable, this website is not the Yankopedia. Roger (Dodger67) (talk) 15:24, 18 June 2018 (UTC)
• Comnent I don't believe we should change policy. What we need to do is actually follow what's written. Many editors seem to discount any national coverage about unelected candidates as not being able to satisfy GNG, though that's not anywhere in the official guidelines. I believe the regular GNG requirements are already specific enough to determine whether unelected political candidates are notable. I can understand desiring some amount of non-local coverage for unelected candidates, but I disagree with the idea that well sourced and useful national coverage about candidates should be deleted just because the person is unelected or loses their election. It would be far more difficult to fully document elections and get a complete view of the election when all the coverage for the losing side always gets deleted. We had an extremely widely covered district attorney race recently, and the information about the losing candidate is historically important to understand the race and some of the actions of the winning candidate, even if the loser never does anything else notable. Second, I can understand that Wikipedia shouldn't be used as a campaign brochure, but I think the regular policy guidelines are enough to fight cases like that. Third, it seems against the purpose of Wikipedia to delete well sourced information and national coverage about candidates right as people are looking for and need that information the most. Lonehexagon (talk) 22:24, 20 June 2018 (UTC)

• Oppose I'm more familiar with the Canadian system where we have 3-5 "major" party candidates selected by the local party members, but in most races really only one party or maybe two have a shot of winning. A national election is a collection of local elections and the standard bearers of the parties without a chance, and even the runners up simply are not usually notable and fade back to obscurity. Arguably some of the winners do nothing notable in 4-5 years but being elected makes a very clear bight like everyone can verify. Legacypac (talk) 01:02, 25 June 2018 (UTC)

• Comment. These specialty notability guidelines are a plague on Wikipedia. Far too often they are interpreted to be restricting notability rather than expanding it, even though the text could not be plainer about that point. WP:GNG is the main criterion; NPOL just allows a hypothetical incumbent who fails GNG to have an article anyway. Which is Never Gonna Happen. I can't support the original proposal because it would mean any bozo can file a form to get in an election and be guaranteed his own temporary Wikipedia article. But I don't think it would ever have been made if people weren't abusing a guideline that has no real use in the first place. Wnt (talk) 16:06, 2 July 2018 (UTC)
• Oppose A candidate who has won a primary is sort of like a football player who hasn't played for a professional team yet. I believe WP:NPOL exists to disqualify sources that would otherwise pass WP:GNG, similar to the notability restrictions for sports players, as a high school sports player may receive lots of local and even national coverage but shouldn't necessarily qualify for a Wikipedia article (and WP:GNG is inclusive enough for the exceptions). Similarly, I believe politicians must either pass the WP:NPOL guideline, or pass WP:GNG using sources not directly related to their campaign, due to concerns of recentism, WP:NOTNEWS, WP:BLP1E, WP:PROMO, and the problem that notability is not temporary, which here means you don't get to keep an article because you're a candidate only for us to delete it when you lose once your fifteen minutes of fame are up (also noting the ten year rule). There are many politicians who would win a primary but wouldn't receive enough coverage for WP:GNG. Furthermore, primaries are tailored to the U.S. system of elections. I'm familiar with preselections, but someone preselected doesn't automatically qualify for a wikipedia article. Strong oppose. SportingFlyer talk 21:22, 3 July 2018 (UTC)
• Strong support, but with some conditions:

They must meet 1 of these 2 criteria:

1. There is (be/have been) a credible chance that they (can win/could have won) the general election, or
2. The office in contention should be well-above NPOL inherent notability standards

• And MUST meet the following criterion:

1. Coverage of them must go further than NEXIST (in other words, no permastubs).

This addresses the concerns above. The OP probably has United States elections in mind, but the NPOL guideline applies to any election in the world including elections in nations that are extremely underrepresented on this wiki, such as Iran, Guatemala, Botswana, and Thailand that may not even have an article on the highest ranking member of the legislature. However, my proposal is almost close to what should have been the status quo, but because of the problem Wnt mentioned, many people are inappropriately using NPOL to restrict and not to expand.  — Mr. Guye (talk) (contribs)  01:12, 5 July 2018 (UTC)

• Addendum: I also oppose the "temporary notability" portion of your proposal. — Mr. Guye (talk) (contribs)  01:17, 5 July 2018 (UTC)

• Strong Oppose Mostly per above. To the extent that candidates for public office get a lot of temporary news coverage it falls under BLP1E unless they win. Beyond which the project is constantly being buried with articles about candidates that tend to be disproportionately thinly (and in some cases not so thinly) disguised adverts for the candidate. There has been a longstanding and very strong consensus within the community that we don't allow articles about unelected candidates unless they have a very clear claim to notability independent of their candidacy. Far from weakening NPOL I have been seriously considering proposing stronger language to codify what has been the normative practice at AfD and carve out a clearly defined exception to GNG/BASIC. -Ad Orientem (talk) 01:27, 5 July 2018 (UTC)
• Oppose per Chetsford and others.  — SMcCandlish ☏ ¢ 😼  01:47, 5 July 2018 (UTC)

Proposal to make Uw-Unsourced warning more user friendly Suggestion

I have been posting (subst'ing) this message User:DBigXray/ref as a Twinkle Welcome message for newbies who are not aware how to add sources. I have posted this on hundreds of talk pages of newbies and several editors have copied this subst and modified this to their own version with this image, I propose to update the Template:Uw-unsourced1 with a screenshot image and text as as below. Based on my experience and positive feedback I have recieved, I believe this will help Wikipedia's acute problem of unsourced editings. --DBigXray 12:11, 14 June 2018 (UTC)

(updated) proposed text and the image to be added at the end of the template

Just follow the steps 1, 2 and 3 as shown and fill in the details

Adding a well formatted references is very easy to do.

1. While editing any article or a wikipage, on the top of the edit window you will see a toolbar which says "cite" click on it
2. Then click on "templates",
3. Choose the most appropriate template and fill all relevant details,

Discussion of Uw-Unsourced

I wouldn't support fill as many details as you can, but I'd support fill all relevant details. Also, the toolbar should support other {{cite xxx}} templates and order them alphabetically. Headbomb {t · c · p · b} 13:38, 14 June 2018 (UTC)

• The proposal is open to any Copy Editing of the said text, if others feel it can be improved. I had written as many so that at least the Title publisher dates etc are available for a google search in case of WP:LINKROT. --DBigXray 14:12, 14 June 2018 (UTC)
• I have updated the text with your suggestion --DBigXray 17:12, 14 June 2018 (UTC)

• The main question I have at this point is is the RefToolbar enabled by default?, especially for IPs and the like? Otherwise we'd be giving a screenshot of something they don't have access to. I do like the idea though. Headbomb {t · c · p · b} 18:13, 14 June 2018 (UTC)

• @Headbomb: Did a quick check from a different browser, where I'm not logged in, and it appears to be at least enabled for IPs on desktop. Don't know about new accounts or mobile, though. AddWittyNameHere (talk) 18:34, 14 June 2018 (UTC)
• @Headbomb: I am quite sure, it is also enabled for the newbies. I am saying this from the confidence of experience, None of the hundreds of newbies who got this template from me ever complained about not seeing the refToolbar. I did recieve many thanks from them. Since it is enabled for IPs it is safe to say it is also enabled for new users. --DBigXray 20:52, 14 June 2018 (UTC)

If it's on by default, then there's no possibility of confusion. So I say add it to the warning. Headbomb {t · c · p · b} 21:51, 14 June 2018 (UTC)

Note that we have lots of editors that a user can potentially encounter, not just WikiEditor 2010. Also note that the reftoolbar is currently not supported by a single person, so any changes will require it finds a new maintainer. —TheDJ (talk • contribs) 09:37, 15 June 2018 (UTC)

• WikiEditor 2010 by its name now appears to be 8 years old. Do you have any wise estimation or numbers of users editing wikipedia and not using WikiEditor 2010. I believe those numbers will be far less in comparison to users of WikiEditor 2010. This proposal does not need any source code edits in the Reftoolbar. Just a suffix in the warning template is all it needs. The image is self explanatory and does need any reading of wikilinks or policy pages. The links would still be there for people interested to know more on policies. Based on my experience we cannot slap the template and then expect the said newbie or IP to go through the wiki policies and understand HTML tags so that he can make a sourced edit. --DBigXray 16:38, 16 June 2018 (UTC)

I tried to get the numbers you ask for a while ago, and it appears that the answer depends – far more than any reasonable personw would guess – on exactly what you mean by "number of users", "editing", "Wikipedia", and "not using". Here are a few things that I have learned:

• There are too many mw:Editors.
• At the English Wikipedia, half or more of all edits are semi-automated or fully automated changes made via scripts (like Twinkle, HotCat, and AWB) and bots (e.g., ClueBot). An unfortunate proportion of these script-based edits aren't tagged or labeled in a way that would let you find out which tools an editor is using.
• The "number of edits" and the "number of users" are significantly different issues. Thousands of humans (across all the wikis) use the visual editor; sometimes, a single editor makes a thousand edits at just one wiki on one day. You probably care about the proportion of humans using a given editing environment, rather than proportion of actions taken by those humans.
• New editors are more likely to use the visual editor exclusively than others; people who have been editing for a decade are more likely to use a wikitext editor exclusively. You probably care more about new/learning editors than about experienced editors.
• The proportions also change by namespace. You probably care about the proportion of mainspace edits, which has a lot more edits via the visual editor (VisualEditor's visual mode) and the mobile editors, compared to talk pages or template pages (where, e.g., the visual editor is disabled).
• Desktop users [like me] make more edits than mobile editors.
• When you look specifically at what I'll call "fully manual" edits in the mainspace, about 7% of all edits (not humans) are made using the mobile editors.
• Sometimes, it's hard to figure out how to classify something. For example: if you have WikEd enabled, and you use HotCat to make several changes, which editing environment did you use? I'd like to see that get a Special:Tag for both HotCat and WikEd, but WikEd is an overlay on one of the old wikitext editors, so maybe it should get a tag for that editor as well. Also, a lot of straight-up reversions happen. The Undo button leads to an older wikitext editor. But did you really "use" it?

Sorry that I don't have any simple answers, but I think you would do well to be cautious about assuming that the people who need to hear your message are working in the same editing environment that you prefer. That said, among less-experienced editors, the most common alternatives to the 2010 WikiEditor are always tagged server-side. You could make up three or four screenshots, check their contributions to see which tags are attached to their edits, then post the relevant screenshot. Whatamidoing (WMF) (talk) 22:26, 21 June 2018 (UTC)

Support in principal. I'm sure the debate about what screenshot to use can be resolved. — BillHPike (talk, contribs) 23:06, 17 June 2018 (UTC)

• Support in principle At WP:MEDHOW we explain how to use both main editors to add a reference. The above does not take into account VEDoc James (talk · contribs · email) 15:41, 22 June 2018 (UTC)
• Support in principle per proposer. Darylgolden^(talk) Ping when replying 05:28, 1 July 2018 (UTC)
• Support - This is a good idea, and if the template wording and diagram can be made even clearer, that would be even better. - MrX 🖋 13:52, 2 July 2018 (UTC)
• Sopport, with that copyedit about "as many details as you can" being replaced with "all relevant details" or something to this effect. I don't buy the concern about about mw:Editors and maybe they're using some tool not compatible with the instructions; if they're a new editor, they don't even know about these tools. If they're not a new editor and are using a tool, they're also experienced enough a) to know they should be citing sources, and b) to understand the template is a notice about sourcing not about interface elements they don't use at present.  — SMcCandlish ☏ ¢ 😼  01:52, 5 July 2018 (UTC)