Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Primefac (talk | contribs) at 20:12, 10 June 2018 (→‎RfC: Deletion of drafts: clarification about other proposals). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


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

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

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)[reply]
  • 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)[reply]
    • User:MER-C, the resubmitters are never told “no”. Have a look at some. —SmokeyJoe (talk) 22:04, 11 May 2018 (UTC)[reply]
      • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    @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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    • 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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose, per Kvng. This proposal comes across as a punitive measure, too. --Doncram (talk) 19:52, 11 May 2018 (UTC)[reply]
    • 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)[reply]
    • @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)[reply]
      • 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)[reply]
  • 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)[reply]
    • @Eggishorn: Can you provide some details about this "practical AfC data"? ~Kvng (talk) 00:41, 12 May 2018 (UTC)[reply]
@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)[reply]
@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)[reply]
  • (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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • (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)[reply]
@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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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. –Davey2010Talk 21:05, 11 May 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
In that case you'd better send this to RfD ;) Kudpung กุดผึ้ง (talk) 22:53, 11 May 2018 (UTC)[reply]
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)[reply]
  • 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)[reply]
    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)[reply]
    @Legacypac: See above your comment to SoWhy re ad hominem. --Izno (talk) 12:13, 13 May 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support. We are WP:NOTWEBHOST for material unsuited to our project. Sandstein 07:46, 12 May 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

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)[reply]
At MfD we can discuss and save if the AfC reviewers are wrong Legacypac (talk) 08:01, 13 May 2018 (UTC)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support - this seems like a measured solution to the problem. Richard0612 13:47, 12 May 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
if that is true for a draft that can be discussed at MfD. Legacypac (talk) 08:01, 13 May 2018 (UTC)[reply]
  • Support - a measured proposal that doesn't try to go too far. — Insertcleverphrasehere (or here) 23:04, 12 May 2018 (UTC)[reply]
  • 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)[reply]
  • 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 (TALKCONT) 00:21, 13 May 2018 (UTC)[reply]
If they get repeatedly resubmitted they never get to G13 Galobtter (pingó mió) 06:35, 13 May 2018 (UTC)[reply]
  • Support - per User:Robert McClenon Smallbones(smalltalk) 15:09, 13 May 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • @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)[reply]
"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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support per Tony and K.e.coffman. Could not have said it better myself. JTP (talk • contribs) 15:41, 31 May 2018 (UTC)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • Support per above. Seems sensible, and already appears to be the case at MfD anyways. -FASTILY 23:05, 7 June 2018 (UTC)[reply]

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

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)[reply]
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)[reply]
'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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
(edit conflict) I also endorse GoodDay's comment. Ivanvector (Talk/Edits) 19:20, 11 May 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
Userspace. —SmokeyJoe (talk) 21:44, 11 May 2018 (UTC)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
    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)[reply]
      • 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)[reply]
        • 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)[reply]
  • 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)[reply]
  • 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)[reply]

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

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


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

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

  • 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)[reply]
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)[reply]
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)[reply]
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 (TALKCONT) 04:57, 14 May 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
    @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)[reply]
    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)[reply]
  • 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 (TALKCONT) 04:47, 14 May 2018 (UTC)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose draft means draft.--Paul McDonald (talk) 23:22, 24 May 2018 (UTC)[reply]
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.

American English Wikipedia

No. TonyBallioni (talk) 16:47, 18 May 2018 (UTC)[reply]

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

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

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

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

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

Memorial:Support

  • Support as nominator. --Bohbye (talk) 21:53, 23 May 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]

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

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

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)[reply]
  • 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)[reply]
  • 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)[reply]
  • @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)[reply]
  • Oppose, lack of notability. — Preceding unsigned comment added by Edibobb (talk • contribs) 02:08, 27 May 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

Memorial:Alternatives

  • Status quo Continue deciding ona case-by-case basis. Beeblebrox (talk) 01:38, 24 May 2018 (UTC)[reply]
  • Status quo One-size-fits-all policies are rarely useful at Wikipedia. --Jayron32 02:28, 24 May 2018 (UTC)[reply]
  • 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)[reply]
  • Status quo - 2nd choice. - Knowledgekid87 (talk) 04:04, 24 May 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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. Richard0612 12:46, 24 May 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Status quo - Should be done on a case-by-case basis, Seems the logical answer..... –Davey2010Talk 14:10, 24 May 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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. Spirit of Eagle (talk) 01:51, 25 May 2018 (UTC)[reply]
  • 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. Cullen328 Let's discuss it 07:32, 25 May 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

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

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

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

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

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

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

Making widely-used icons consistent and modern

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. Ladsgroupoverleg 23:58, 26 May 2018 (UTC)[reply]

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)[reply]
  • 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)[reply]
  • All those icons look rather flat, one toned, and overall meh. —Farix (t | c) 16:30, 27 May 2018 (UTC)[reply]
  • 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 Traintalk 23:44, 27 May 2018 (UTC)[reply]
  • 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:

Warning icon Please stop disruptive blah blah blah.


Compared to icons from the proposed sets:

Warning icon Please stop disruptive blah blah blah.

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

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 Ladsgroupoverleg 04:41, 28 May 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support. It should be noted that the French Wikipedia is attempting something similar. Lojbanist remove cattle from stage 23:26, 29 May 2018 (UTC)[reply]
  • 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)[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.) Ladsgroupoverleg 17:06, 3 June 2018 (UTC)[reply]
    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)[reply]
    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)[reply]
    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 Ladsgroupoverleg 17:25, 3 June 2018 (UTC)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

Changing information icon

This is proposal to replace blue information icons ( ) with the OOjs one () Ladsgroupoverleg 17:27, 3 June 2018 (UTC)[reply]

  • Support as proposer. Ladsgroupoverleg 17:27, 3 June 2018 (UTC)[reply]
  • Oppose - this icon is less visible to me. --Khajidha (talk) 00:19, 5 June 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]

Changing alert icon

This is proposal to replace red alert icons ( ) with the OOjs one () Ladsgroupoverleg 17:30, 3 June 2018 (UTC)[reply]

New proposal

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

Changing scale icon

This is proposal to replace scale icons () with the emoji one version () Ladsgroupoverleg 17:33, 3 June 2018 (UTC)[reply]

Consistency

Please suggest replacements for the following icons as well.

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

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

"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)[reply]
(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)[reply]
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)[reply]
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. Cullen328 Let's discuss it 20:08, 27 May 2018 (UTC)[reply]
I agree 100% with the lively description of Cullen328 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)[reply]
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. Cullen328 Let's discuss it 20:28, 27 May 2018 (UTC)[reply]
Thanks, Cullen328, 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)[reply]
  • 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)[reply]
  • 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 [2] 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)[reply]

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

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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
        • Isn't that what the edit filters are already doing? bd2412 T 16:51, 10 June 2018 (UTC)[reply]

RfC: Delete IABot talk page posts?

A previous RfC halted new talk page posts by InternetArchiveBot.

This RfC is to see if there is consensus to delete the posts. It affects about 1 million talk pages. An example post that would be deleted.

There are two options for deletion:

#1 - a bot edits the 1 million pages deleting posts. Archived talk pages will be left alone. Bot operator User:GreenC has volunteered.
#2 - the wording of the post is modified to give users permission to delete posts if they want to. Since talk page posts normally can't be deleted by other users, it would remove that restriction. The wording can easily be changed via the {{sourcecheck}} template, it would not require every page be edited.

Please !vote support or oppose. Clarify choice of method #1 and/or #2 in order of preference.

- Rod57 (talk) 16:02, 29 May 2018 (UTC)[reply]

Survey

  • Support as nominator. Prefer #1 but would be happy with #2 - Rod57 (talk) 16:02, 29 May 2018 (UTC)[reply]
  • Oppose for now, as the nominator has not explained what benefit (if any) there would be in doing this. —Compassionate727 (T·C) 16:14, 29 May 2018 (UTC)[reply]
Because the posts clutter talk pages and confuse editors. They won't be archived in most articles, most have no automatic archiving or enough traffic to warrant archiving. If you still oppose why not support choice #2? -- GreenC 18:23, 29 May 2018 (UTC)[reply]
  • Oppose making another million edits here. Looks like these mostly all use {{sourcecheck}} - just add some verbiage there. — xaosflux Talk 16:47, 29 May 2018 (UTC)[reply]
Choice #2 says this. Are you then in support of #2? -- GreenC 18:17, 29 May 2018 (UTC)[reply]
I'm pretty indifferent to option 2, just strongly opposed to option 1. If going for option 2, certainly need to check if there are other uses outside of this use case that could lead to unintended impacts. — xaosflux Talk 19:42, 29 May 2018 (UTC)[reply]
  • Option 2 per the {{sourcecheck}} argument. Just change the text. In most cases it'll get archived anyway. — AfroThundr (t•c) 17:05, 29 May 2018 (UTC)[reply]
Choice #2 says this. Are you then in support of #2? -- GreenC 18:17, 29 May 2018 (UTC)[reply]
  • Comment - See choice #2  :-) -- GreenC 18:26, 29 May 2018 (UTC)[reply]
  • Oppose everything — literally not a single reason to make a million edits to remove once-useful things. Unless there's a good reason, we need not retroactively remove material. I don't see a need to change the template to encourage folks to delete them, they're not hurting? What's the need here? ~ Amory (u • t • c) 19:45, 29 May 2018 (UTC)[reply]
  • Support deletion Option #1 or any deletion plan is fine. This text is spam and information pollution which wastes huge amounts of time by continually distracting users to read this text. It is of no use to anyone. This text never should have been posted and for as long as it persists it is actively spoiling the Wikimedia user experience. At least archive it all; preferably delete it outright. Blue Rasberry (talk) 19:59, 29 May 2018 (UTC)[reply]
  • Oppose option #1 as something that could cause more harm than good, especially if a new bot has to be designed to handle this workload. I just don't think it's worth the time and effort just to create more page revisions that don't do anything constructively. I would be okay with rewording, per option #2, but again, I don't see a need to do it retroactively to past posts. Surely, if anyone cared, I'm sure after rewording the post others would interpret that as being safe to remove past posts if they wish, and no one would find a problem with that. Red Phoenix talk 21:44, 29 May 2018 (UTC)[reply]
  • Oppose The posts get archived on active talk pages and lend meatiness to article talk pages that otherwise have seen little activity. I've actually used IABot's messages to do some close checking and don't want to see my work deleted, if it still exists where it hasn't been archived. Dhtwiki (talk) 21:55, 29 May 2018 (UTC)[reply]
  • Oppose option 1, indifferent on 2 as long as the template isn't used elsewhere. That said, this seems to be a solution in search of a problem - has the fact that the messages exist been raised as a problem before now? ƒirefly ( t · c · who? ) 22:15, 29 May 2018 (UTC)[reply]
@Firefly: Yes, below in the discussion, I have raised the existence of the messages as a problem. Blue Rasberry (talk) 22:51, 29 May 2018 (UTC)[reply]
@Blueraspberry: You say that the messages 'consume human time', but what evidence is there for this, or for this being a problem? Tone doesn't come across well in text, so please rest assured that I'm genuinely interested in this - do you have any data to back up that such messages eat up reader time (unnecessarily), or are they just scrolled past in a second or two. ƒirefly ( t · c · who? ) 23:01, 29 May 2018 (UTC)[reply]
@Firefly: This is spam. Spam consumes small amounts of time and attention from large groups of people giving benefit to almost none. Which of these premises do you dispute? - there are millions of these messages, tens of thousands of people read them, they have a life of years, the talkpages show tens of millions of views, there is a body of research publication which describes how spam / advertising consumes time and spoils an environment, these messages ask for minutes of time from all readers, people prefer to moderate their environment's level of spam, this kind of messaging is unprecedented in Wikimedia projects. Most people scroll past in 2 seconds but even that is unacceptable multiplied times millions. Many people read the messages the first few times and some people actually respond. Blue Rasberry (talk) 13:11, 30 May 2018 (UTC)[reply]
  • Oppose all Please do not edit one million pages (or even one hundred pages) without a clear benefit. The watchlist turmoil alone is not worth it. A worse problem is the wasted effort as puzzled editors check what happened on the talk pages they monitor. I would scratch my head if I saw a bot modify another bot's message. Johnuniq (talk) 23:09, 29 May 2018 (UTC)[reply]
  • Option 2 requires editing ONE page. Not a million. Can you re-evaluate Option 2? -- GreenC 18:25, 30 May 2018 (UTC)[reply]
  • Please make a proposal with precise wording, preferably brief. However, you don't need an RfC to edit a single template. I don't see a need to add a "you have permission to delete this" message. If someone is too inexperienced to know they can delete a bot's message if it's a nuisance they should not be fiddling with talk pages. Johnuniq (talk) 00:52, 31 May 2018 (UTC)[reply]
  • @Johnuniq: I agree that permission isn't actually needed on any given single article, but Rod57 initially proposed something roughly reflecting your position on the template's talk page and ended up running this RfC at least in part because I asserted that mass removal of the messages, regardless of whether done by bot or by encouraging human editors to do so, is something that would require community approval (mea culpa). Even (especially?) experienced editors are indoctrinated to never ever mess with others' talk page comments, so I think adding such a message to the (already transcluded) template would have an effect beyond just "stating the obvious". I suspect the "precision" you find missing in the framing of this RfC is due to an attempt at brevity and neutrality from someone who has never constructed an RfC before. I hope that tradeoff won't make necessary restarting it entirely. --Xover (talk) 06:16, 31 May 2018 (UTC)[reply]
  • oppose; per above. This has the potential to waste users time by alerting them to the automated change. Also possible is wasted editing hours as people discuss the issue during the fallout. In any case, particularly with regard to the example given above, we would almost certainly appreciate a human user leaving such a TP summary after making a non-minor edit affecting sourcing, why should a bot's contribution be less valid/useful. Agree with discussion points below - that brevity should be considered and would support improved brief messages if they can be shortened. Edaham (talk) 08:25, 30 May 2018 (UTC)[reply]
  • Oppose Solution 1 per cost benefit; would
  • Weak Support number 2 per User:GreenC . GenQuest "Talk to Me" 11:46, 30 May 2018 (UTC)[reply]
  • Oppose making edits to every talk page with such a message, there's no point in flooding watchlists for that. Don't care if the solution is changing the wording of a transcluded template, as implied might be the case in option 2. Anomie⚔ 12:17, 30 May 2018 (UTC)[reply]
  • Oppose Option 1, meh for Option 2. Don't see the point in removing the notices systematically, especially many of those were made at a time when IABot wasn't super reliable. I've removed IABot messages before myself, so if you want to add a message to a template IABot used to mentioned this is an option, sure. I don't think it's going to make much of a difference, but I'm not oppose to that. Headbomb {t · c · p · b} 12:34, 30 May 2018 (UTC)[reply]
  • Support Option #2 and Would not oppose Option #1. I manually remove these on "my" articles if they happen to annoy me (clutter), and see no reason why others should not feel free to do the same, with or without "permission" from the template message. Changing the message to explicitly allow this (subject to normal local consensus), provided it is backed by community consensus in this RfC, has effectively zero cost and mainly reaffirms the status quo. Mass removing them by bot seems excessive for the problem: they're just a bit of clutter, and we have a ton of that in various other forms. Better to avoid the watchlist noise and potential for wikidrama such mass edits can engender. I would not, however, be opposed if consensus was to bot-remove them: I just don't think it's a big enough deal either way to feel strongly about it. (PS. Kudos to Rod57 for setting up this RfC. It's good to have a community consensus as guidance, either way.) --Xover (talk) 13:11, 30 May 2018 (UTC)[reply]
  • Support #2, neutral on #1 I hear the arguments against 1 on the basis of the many edits, although I'm not sure how much of a problem it would be. However, it would be sensible to allow users to remove notices in areas where they constitute clutter. Tamwin (talk) 16:42, 30 May 2018 (UTC)[reply]
  • Oppose Option 1 and Support Option 2 which pretty much lets sleeping dogs lie. The posts are spam and were a nuisance when made, but make further nuisance only to those readers who read old posts. Waking this sleeping dog will make a new, similar nuisance to my fellow talk page stalkers. Yes, my opinion is based on a guess that the new nuisance will be bigger than the remaining nuisance value of the old spam posts. No use complaining when other guesses lead to other opinions. Jim.henderson (talk) 18:46, 31 May 2018 (UTC)[reply]
  • Support option 2: the messages are useless, but not worth the trouble of performing a million of edits. Option 2 seems like a good choice in addressing the perceived issue. --K.e.coffman (talk) 20:26, 31 May 2018 (UTC)[reply]
  • Oppose All - There is no benefit to editing over a million pages just to delete a bot message ..... They can and will be archived eventually, I and others archive talkpages and most talkpages have the archive bot .... if they're not archived then who cares ? ..... The proposal IMHO does not in any way, shape or form help with the goals of Wikipedia. –Davey2010Talk 20:53, 2 June 2018 (UTC)[reply]
  • Oppose option 1, indifferent to option 2 I'm just not seeing the problem with letting old Archivebot messages stick around: they aren't causing any harm and they'll eventually go away on their own through talk page archiving. I strongly oppose option 1 since it will require a ton of work for little benefit. Option 2 only requires a single edit, so I have no objection to it. I don't think it will accomplish much, but if the community wants it I won't oppose. Spirit of Eagle (talk) 23:11, 2 June 2018 (UTC)[reply]
  • Support option 2, to clarify that one doesn't really need to check the bot's edits nor to edit any talk page template. Those requests were just terrorism imposed by users who didn't believe in the success of the bot. Neutral on option 1: the whole message should have been a template, but the subst-worshippers would have opposed that; the real solution for the future is to avoid adding so much text in talk pages, changing Wikipedia:Substitution if necessary, to make it clear that it's vastly better to insert boilerplate text via templates. --Nemo 07:01, 3 June 2018 (UTC)[reply]
  • Oppose option 1 - the benefit doesn't justify the volume of talk spam. No opinion on Option 2; I have WP:OneClickArchiver enabled which can remove them from the talk page already. power~enwiki (π, ν) 23:52, 4 June 2018 (UTC)[reply]
  • Oppose both options. This is unnecessary, will clutter watchlists and history, and remove slightly useful posts. Graeme Bartlett (talk) 02:50, 5 June 2018 (UTC)[reply]
  • I will add that option 2 will be much worse than the original posting of messages on the talk page, since all the talk pages will be changed, and will waste so much time in people finding out what happened, for no benefit at all. Graeme Bartlett (talk) 22:57, 6 June 2018 (UTC)[reply]
  • Oppose both options, per Davey2010 and Johnuniq. — Javert2113 (talk; please ping me in your reply on this page) 21:50, 5 June 2018 (UTC)[reply]
  • Oppose Option 1 because mass edits like that would be immensely unnecessary but support Option 2, so that the messages can be removed where they are actually an obstruction. BegbertBiggs (talk) 15:04, 9 June 2018 (UTC)[reply]

Discussion

The persistence of advertising and spam messages consume a huge amount of human time and attention and bring no benefit. The Wikipedia community currently does not anticipate or measure the costs of mass messaging millions of discussion posts to hundreds of thousands of readers. If a message has a life of years, then if great numbers readers spend their time considering great numbers of messages, then this wastes hundreds of hours of Wikimedia community time in an unsatisfying user experience. We have to keep Wikipedia clean of unproductive distractions! See my previous rants on this topic:

No bot should be allowed to consume hundreds of human hours about its automated activities! Remove these messages immediately and avoid ever allowing this again! Blue Rasberry (talk) 21:47, 29 May 2018 (UTC)[reply]

No evidence any significant amount of time is spent on these. They were turned off precisely because everyone just ignores them. On active talk pages they'll be archived quickly, on inactive pages they won't get seen. ~ Amory (u • t • c) 00:46, 30 May 2018 (UTC)[reply]
I'm in general agreement with Bluerasperry on the principle, but must note that I consider the concern somewhat overblown on this particular instance of the issue. In general we should strive to be mindful of editor attention, including both article and user talk page messages, and "noise" in people's watchlists; but not to the exclusion of useful functionality or information. There is certainly wasted attention caused by these messages, but they are not entirely devoid of compensating value (how much is a subjective call). And excessive effort expended on them, relative to all the other more pressing issues the project faces, is likewise not a good use of the same limited resource (editor attention). --Xover (talk) 13:00, 30 May 2018 (UTC)[reply]
@Xover: I really appreciate your acknowledgement that editor attention is a limited resource. I can understand and accept that different people will calculate cost/benefit in time in different ways, but I find it challenging to understand how anyone could say that the cost is zero or immeasurable. Thanks for the reply. Blue Rasberry (talk) 14:08, 31 May 2018 (UTC)[reply]
No one said the cost was zero, just that what the exact cost is is at best a guess that depends on a lot of assumptions, which ultimately yields little to no insight on anything. Headbomb {t · c · p · b} 17:11, 31 May 2018 (UTC)[reply]
@Bluerasberry: Per Headbomb, I don't think anyone is asserting that the cost of editor attention is zero. But they may disagree that leaving the old messages in place affects (uses) editor attention to any degree worth mentioning, or they may care so much more about the editor attention wasted by noise in watchlists and possibly discussions and wikidrama arising from the removal as to consider the other to be insignificant. Or they just think other factors are more important. An RfC !vote is the distilled result of the conclusion drawn after considering the various factors and assigning them your particular relative merit: it is not an expression of ignorance of, or active dismissal of, other concerns. It's "Here's what I think is important", not "What you think isn't important", if you'll pardon the simplification. --Xover (talk) 05:19, 1 June 2018 (UTC)[reply]
I would not criticize others. For myself, I fail to understand the other side, and for myself, I feel a lack of ability to express what I see in a way that makes me feel understood. Thanks for the encouragement. Blue Rasberry (talk) 10:35, 1 June 2018 (UTC)[reply]
I'll note that we have a reasonably accurate proxy of the attention gains by the bot's activity, namely clicks on its userpage. --Nemo 07:19, 3 June 2018 (UTC)[reply]
  • Can they at least be put under 1 <h2/> tag titled == "External links modified" == and then each time the bot runs it just adds the date as an <h3/> (===6 June 2018===)?  Nixinova  T  C  04:28, 6 June 2018 (UTC)[reply]

Discussion at Wikipedia talk:Manual of Style/Portals#RfC: Adopt as a MoS guideline

 You are invited to join the discussion at Wikipedia talk:Manual of Style/Portals#RfC: Adopt as a MoS guideline . - Evad37 [talk] 03:00, 31 May 2018 (UTC)[reply]

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

No. That’s what the lead section is for. Beeblebrox (talk) 22:29, 3 June 2018 (UTC)[reply]
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)[reply]

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

See WP:SHORTDESC. This is a project that does almost exactly what you are looking for. Bradv 23:28, 3 June 2018 (UTC)[reply]
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)[reply]

A discussion about the Main Page

A discussion about changing the Main Page is being held here. Please weigh in so that a rough consensus may emerge. Thanks122.163.93.250 (talk) 03:26, 4 June 2018 (UTC)[reply]

Background: please see this discussion started by Jimbo Wales on his talk page.

I propose that a site-wide banner be displayed through June 20, 2018, on all language Wikipedias including the English Wikipedia, when geolocation indicates that the reader is in an EU jurisdiction, explaining the upcoming June 20 European Parliament vote on the copyright law changes being considered there which could severely impact all Foundation projects, including a link directly to https://saveyourinternet.eu/

Note that the Wikimedia Foundation already has an official position on this issue: https://blog.wikimedia.org/2017/06/06/european-copyright-directive-proposal/ Doctorow (talk) 03:13, 6 June 2018 (UTC)[reply]

Background information

Collated information on the effects of the law on Wikipedia

Filtering proposal

(taken from @Doctorow:'s message on Jimmy's talk page)

  • Sites that make material available to the public are required to filter according to rightsholder-supplied lists of copyrighted content
  • Even if they do filter, they are still liable if infringing material is uploaded and made available
  • If you believe that you have been unfairly blocked, your only remedy is to contest the block with the host, who is under no obligation to consider your petition
  • There are no penalties for falsely claiming copyright on material -- I could upload all of Wikipedia to a Wordpress blocklist and no one could quote Wikipedia until Wordpress could be convinced to remove my claims over all that text, and Wikimedia and the individual contributors would have no basis to punish me for my copyfraud
  • There was a counterproposal that is MUCH more reasonable and solves the rightsholders' stated problem: they claim that they are unable to convince platforms to remove infringing material when the copyright rests with the creator, not the publisher (e.g. Tor Books can't get Amazon to remove infringing copies of my books because I'm the rightsholder, not them); under this counterproposal, publishers would have standing to seek removal unless creators specifically objected to it
  • There is a notional exception for Wikipedia that carves out nonprofit, freely available collaborative encyclopedias. This does get WP a lot of latitude, but Article 13 still has grossly adverse effects on WP's downstream users -- anyone who mirrors or quotes WP relies on the safe harbours that Article 13 removes. Think also of all the material on EU hosts that is linked to from Wikipedia References sections -- all of that could disappear through fraud or sloppiness, making the whole project (and the whole internet) more brittle

Position of Wikimedia organisations

Questions?

Please post any questions about the law and how it might affect Wikimedia projects:

  • Do we currently make use of copyrighted material in a way that would be affected by being in violation of this "law"?Slatersteven (talk) 18:26, 7 June 2018 (UTC)[reply]
    • @Slatersteven: yes, "it could also require Wikipedia to filter submissions to the encyclopedia and its surrounding projects, like Wikimedia Commons. The drafters of Article 13 have tried to carve Wikipedia out of the rule, but thanks to sloppy drafting, they have failed: the exemption is limited to "noncommercial activity". Every file on Wikipedia is licensed for commercial use." ref.
    • @Slatersteven: No, no direct impacts on Wikimedia projects as the text currently stands in both Council and Parliament. All non-for-profit projects would be excluded, which means all our projects. If our content is used commercially this would happen on another, non-Wikimedia service. That being said, the wording is not final and sloppily written, so no guarantees it will stay this way. But there is a clear political will to exclude all Wikimedia projects. --dimi_z (talk) 20:20, 7 June 2018 (UTC)[reply]
Supplementary
I asked how we would be in violation of it, maybe I was not clear. If this rule was in place now what do we do that would mean we would could be prosecuted for being in breach of it (assuming that it does not have an exemption)?Slatersteven (talk) 09:21, 8 June 2018 (UTC)[reply]
  • What effect would this law likely have on sources Wikipedia uses for references? E.g academic journals and newspapers. John Cummings (talk) 18:31, 7 June 2018 (UTC)[reply]
    • "Under Article 11, each member state will get to create a new copyright in news. If it passes, in order to link to a news website, you will either have to do so in a way that satisfies the limitations and exceptions of all 28 laws, or you will have to get a license."refJohn Cummings (talk) 19:44, 7 June 2018 (UTC)[reply]
  • What effect would this law likely have on websites that Wikipedia sources open license media content from? e.g Flickr John Cummings (talk) 18:31, 7 June 2018 (UTC)[reply]
    • Flickr would have to filter all uploads. --dimi_z (talk) 20:20, 7 June 2018 (UTC)[reply]
  • Does this law effect Wikimedia Commons? John Cummings (talk) 19:13, 7 June 2018 (UTC)[reply]
    • Yes, see answer to question 1.
    • No it doesn't affect Commons, as commons is also a non-for-profit service (but compromises not final).--dimi_z (talk) 20:20, 7 June 2018 (UTC)[reply]

Discussion

  • Support as proposer. EllenCT (talk) 23:20, 4 June 2018 (UTC)[reply]
  • Oppose for similar reasons as not doing anything about net neutrality and not coming off as political. TonyBallioni (talk) 23:24, 4 June 2018 (UTC)[reply]
  • Oppose. No using banners to advocate for or against political policies unless there's an existential threat involved. --Yair rand (talk) 23:30, 4 June 2018 (UTC)[reply]
    Further, even if this is an existential threat, the correct way to act against it would not be to link to an external site, and certainly not one like that. "The European Commission and the Council want to destroy the Internet as we know it and allow big companies to control what we see and do online." That's not a sentence Wikipedia can be associated with. --Yair rand (talk) 00:23, 5 June 2018 (UTC)[reply]
  • Oppose As with the last time someone suggested a political banner, I see no reason that this is appropriate for wikipedia. Natureium (talk) 23:36, 4 June 2018 (UTC)[reply]
  • Apparently there is an existential threat, see the post by Doctorow at 19:44, 4 June 2018 here. This proposal should not have been made without clear information. Johnuniq (talk) 23:39, 4 June 2018 (UTC)[reply]
The first link in this section includes that description. I agree it certainly does represent an existential threat to the freedom of content re-use, even if the exception for encyclopedias was carved out to prevent direct legal attacks on the existence of the wikipedias. Other projects such as Wikisource would certainly be directly at risk, but they don't reach as many EU citizens as enwiki banners would. EllenCT (talk) 23:47, 4 June 2018 (UTC)[reply]
--Guy Macon (talk) 23:43, 4 June 2018 (UTC)[reply]
  • Support. According to [3], "France, Italy, Spain and Portugal want to force upload filters on not-for-profit platforms (like Wikipedia) and on platforms that host only small amounts of copyrighted content (like startups). Even if platforms filter, they should still be liable for copyright infringements of their users under civil law, just not under criminal law." There is a time to panic, and unless someone can come through and show that all this is not true, then this is that time. If the EU enacts this, we should immediately and permanently block all access to Wikipedia from the EU, globally lock EU-linked editors on all WMF projects, and disband all EU Wikimedia chapters and liquidate any assets there. For a start. We should do that in two weeks. Or we can do a banner now. Your choice. Wnt (talk) 23:53, 4 June 2018 (UTC)[reply]
    European chapters have no legal responsibility whatsoever for Wikimedia sites, IIRC. Does the WMF even need to listen to European copyright laws at all? What we need now is an analysis by WMF Legal on what the ramifications of this would be. Panicking isn't helpful. --Yair rand (talk) 23:57, 4 June 2018 (UTC)[reply]
    There is a duty of care. If the above comes to pass, anyone participating in a European chapter would be subject to very extensive legal harassment and it is not reasonable to pass that responsibility on to them. Johnuniq (talk) 00:07, 5 June 2018 (UTC)[reply]
  • Comment It's not reasonable to claim that the WMF is not subject to EU law and thus action is not necessary. I'm skeptical about some of the claims made by opponents of this measure, but if they are accurate I would support an EU-wide blackout in response. I'd like to hear whether the WMF or their lawyers have an opinion before !voting. power~enwiki (π, ν) 00:06, 5 June 2018 (UTC)[reply]
  • It may not appear reasonable, but it is the case the the WMF servers are in the US, and US opyright law is controlling, not EU copyright law. There may be personal risk for individual editors, but there's no more risk to the WMF's projects than if China changed its copyright laws, or Melanesia. Beyond My Ken (talk) 01:28, 5 June 2018 (UTC)[reply]
    • Beyond My Ken: I’m going to take the opportunity to point out that Wikimedians are already individually liable for every action we take on WMF projects, so if the concern here is that individuals will be held more accountable for stealing the intellectual property of others, well, good for the EU in my book. If there is actually an existential threat to the WMF, I’m sure their legal team would be on it. TonyBallioni (talk) 01:46, 5 June 2018 (UTC)[reply]
    • US copyright law is (fortunately for us) not all-controlling. Local copyright law is also important. WMF does need to comply. The point is the opposite; individual editors are not affected; WMF is. But it's not complaining. Hawkeye7 (discuss) 02:28, 5 June 2018 (UTC)[reply]
  • I think you have it backwards, but I'm not prepared to mount a detailed exegesis. My understanding is as my comment above. Beyond My Ken (talk) 04:25, 5 June 2018 (UTC)[reply]
  • Support This has wide-ranging implications for the sources WP relies on, for downstream users of WP, and for WP itself. It's an unworkable and dangerous proposal that it antithetical to WP and any future project founded on similar principles. [Wikimedia has already taken an official position in opposition to this https://blog.wikimedia.org/2017/06/06/european-copyright-directive-proposal/] a year ago when the proposal was first mooted. Now it's on the brink of passing and it's actually gotten worse in the intervening year. Note that I'm a consultant to the Electronic Frontier Foundation which has opposed this since the start, so I'm hardly impartial, but WMF and EFF are on the same side here, and I think Wikipedians should be too. This is a real problem for the whole project and needs to be averted. Doctorow (talk) 00:19, 5 June 2018 (UTC)[reply]
  • Comment added to Template:Centralized discussion. Holding off on a !vote per Power. TeraTIX 01:19, 5 June 2018 (UTC)[reply]
  • Support absolutely flabbergasted with the mountain of oppose votes solely on the grounds of "political bias". The proposed law has wide-ranging implications, which at worst could mean closing Wikipedia in the EU. It doesn't help that the proposal was made so soon after the net neutrality one was closed. Net neutrality was arguably harmless, but I just can't see how this law could possibly not have substantial negative effects on Wikipedia. We can't afford to gamble on Wikipedia exceptions being added to the final bill. The one political cause we should campaign for is our own. TeraTIX 23:30, 8 June 2018 (UTC)[reply]
  •  Question: Is there a Wikipedia article on this topic? Thanks. Mike Peel (talk) 01:28, 5 June 2018 (UTC)[reply]
I've created Directive on Copyright in the Digital Single Market. It's fairly difficult to find "neutral" sources here, and I'm not even sure how the EU makes legislation. Hopefully the magic of collaboration will improve it. power~enwiki (π, ν) 06:16, 5 June 2018 (UTC)[reply]
  • Oppose per TonyBallioni's concerns about being perceived as politically biased. — BillHPike (talk, contribs) 01:31, 5 June 2018 (UTC)[reply]
  • Oppose Unless the WMF is supporting such a banner (Jimbo != WMF) we have generally decided that politically-oriented banners are not appropriate. If the WMF want to enforce one, if they feel the issue is significant enough, they have ways to push that themselves. --Masem (t) 01:49, 5 June 2018 (UTC)[reply]
  • Oppose: While I'm sympathetic to the arguments here, I am somewhat weary of requests for politically-oriented banners. If the Foundation wishes to do it themselves, they can (and, by all means, they should, if they feel that strongly about this issue), but the voters of Europe have made their choices, and it's not our place, as a worldwide community of editors, to browbeat, cajole, or even attempt to persuade them otherwise, through the usage of Wikipedia. So, just as I voted on net neutrality (twice), I vote again: please, no more political banners/alerts/whatever on Wikipedia. — Javert2113 (talk; please ping me in your reply on this page) 02:40, 5 June 2018 (UTC)[reply]
  • Oppose for many of the reasons stated above. While I can see the harm to the wider internet if this passes, I'm not convinced that this poses an existential threat to Wikipedia which I believe is the only case where such banners are appropriate. Winner 42 Talk to me! 02:55, 5 June 2018 (UTC)[reply]
    • @Winner 42: this article outlines the direct threats of the law to Wikipedia, thanks, John Cummings (talk) 19:54, 7 June 2018 (UTC)[reply]
      • Wow, that reads like it was written in response to this thread. I did find one factual error though. Doctorow states, "Every file on Wikipedia is licensed for commercial use." A relatively large amount of copyrighted content is already used under fair use doctrine and is not licensed for commercial reuse. That said, this hardly rises to an existential threat. Worst case, some European sources get harder to find. I think Wikipedia could reasonably ignore most of what this is because it is US based and I seriously doubt that Europe has the political capital to block or fine Wikipedia. Winner 42 Talk to me! 17:18, 8 June 2018 (UTC)[reply]
  • Oppose any political banners, as always. — Godsy (TALKCONT) 03:44, 5 June 2018 (UTC)[reply]
  • Oppose As above and echoing the oppose votes for net neutrality banner further up. We should be careful with political banners. doktorb wordsdeeds 04:38, 5 June 2018 (UTC)[reply]
  • Oppose per TonyBallioni and oppose Political banners and this is a political issue and feel there other fora are better for this.Pharaoh of the Wizards (talk) 05:49, 5 June 2018 (UTC)[reply]
  • Oppose Though I'm sure the proposal is with good intent, ultimately this is an encyclopedia and not a campaign rally. Chetsford (talk) 07:27, 5 June 2018 (UTC)[reply]
  • Oppose and suggest some plan to formally document somewhere that generally politically-themed banners from any country will not be run, to save editors time in discussions like this. It is all evident from recent proposals, that consensus cannot be reached on issues like this. –Ammarpad (talk) 07:35, 5 June 2018 (UTC)[reply]
  • Oppose. I don't think we should be in the business of championing political causes, and adding a guideline to that effect sounds like a good idea. If the WMF decided this was a threat to the movement and wanted to campaign against it, that would be a different matter. That is part of their job, after all. – Joe (talk) 10:59, 5 June 2018 (UTC)[reply]
  • Oppose. On June 11, net neutrality will be adopted as official U.S. policy, and if internet can survive in America, it can survive in Europe too. wumbolo ^^^ 11:48, 5 June 2018 (UTC)[reply]
  • Oppose, at this point we should ask WMF for more information and advice about this situation instead of speculating based on opinion pieces and advocacy sites (such sites may very well be correct, but they do not offer an unbiased perspective on controversial topics). Also, as already pointed out by others: it would be helpful to discuss a more general guideline about prohibiting political (and other) advocacy on English Wikipedia and to clarify the handling of possible exceptional cases (if any). GermanJoe (talk) 12:27, 5 June 2018 (UTC)[reply]
  • Comment Not an existential threat as Wikipedia can easily exist without the EU, see also the Turkey block. While bad for editors in the EU (including myself), if this comes to pass we might as well fork the encyclopedia, it seems a saner strategy at this point. I find it interesting btw. how people point at WMF whereas WMFs strategy has been to ask the community. Seems a bit circular. :) —TheDJ (talk • contribs) 14:01, 5 June 2018 (UTC)[reply]
    • Sure, for that matter Wikipedia can continue existing even if tomorrow a biological attack kills the entire humanity. It just won't have any user. --Nemo 21:09, 5 June 2018 (UTC)[reply]
      • Well it's clear that the community is fine with that, isn't it ? The ideals have eroded to the point where we effectively ARE the Encyclopaedia Brittanica that we replaced. —TheDJ (talk • contribs) 10:19, 6 June 2018 (UTC)[reply]
  • Support, we need to be able to address laws that directly affect Wikipedia. (Note that I am not thrilled by the not very informative nature of https://saveyourinternet.eu/ ). We regularly have banners claiming Wikipedia will die if users don't donate -- the potential threat from bad legislation seems worse than two years without donations. —Kusma (t·c) 14:07, 5 June 2018 (UTC)[reply]
  • Oppose, the community is here to build an encyclopedia, not for political campaigning. Proposals like this are on their way to WP:PERENNIAL. – Finnusertop (talk ⋅ contribs) 18:45, 5 June 2018 (UTC)[reply]
  • Support compared to net neutrality, this appears to actually have a direct and major effect on wikipedia in the EU, closer to WP:SOPA. Hope to get a statement from the WMF on how exactly this would affect us though. Galobtter (pingó mió) 21:05, 5 June 2018 (UTC)[reply]
  • As Galobtter and Kusma say, this is legislation which directly affects our copyleft and wiki model: not only it directly affects Wikipedia, but of all possible topics in the world it's the one where we can't avoid having an opinion and can't avoid being the most competent to talk (copyleft is the third pillar, folks). On the other hand, it's a bit hard for a community like ours to give a clear and short message among stacks of open letters signed by hundreds of organisations, piles of papers by hundreds of academics, hundreds of competing amendments. Realistically, the true menace will be clear after the JURI vote and the final call to arms will be before the vote in the European Plenary, like last time. After the committee vote, it's certainly too late to have a good law, but it won't be too late to stop a bad one. If we use all our bullets now, we will be harmless when the lobbies come up with yet another trick against Wikipedia. --Nemo 21:30, 5 June 2018 (UTC)[reply]
  • Support great idea. Nocturnalnow (talk) 21:45, 5 June 2018 (UTC)[reply]
  • Oppose yet ANOTHER PROPOSED WIKI-BANNER CRYING WOLF about the end of civilization as we know it. When can these well-intentioned—but badly conceived proposals—and the accompanying Wiki lawyering, just stop? If the WMF speaks out on the issue, ping me... GenQuest "Talk to Me" 23:17, 5 June 2018 (UTC)[reply]
Ping. This is highly relevant for everyone to read.--Jimbo Wales (talk) 14:04, 7 June 2018 (UTC)[reply]
  • Oppose per all the oppose comments - Exactly as the opposition to the US net neutrality banner. Also this would mean identifying from cookies/IP adresses the location of our users/readers. Our encyclopedia is international and it must remain apolitical. Kudpung กุดผึ้ง (talk) 07:42, 6 June 2018 (UTC)[reply]
@Kudpung: "Also this would mean identifying from cookies/IP adresses the location of our users/readers" eh. we already do that for almost every single banner.. Since at least 2009. —TheDJ (talk • contribs) 10:24, 6 June 2018 (UTC)[reply]
TheDJ, I have no idea. I'm an editor not an IT expert. Kudpung กุดผึ้ง (talk) 14:23, 6 June 2018 (UTC)[reply]
Apolitical? LOL. I have a list of articles I would like you to make apolitical.... HiLo48 (talk) 08:12, 6 June 2018 (UTC)[reply]
HiLo48 then as a Wikipedia editor there are things you can do about it. Hope your list is not too long...Kudpung กุดผึ้ง (talk) 14:23, 6 June 2018 (UTC)[reply]
Kudpung Some I can work on. Give me time. Some are owned by unprincipled Admins who would rather see me banned forever. There is no hope there. (For those articles or those Admins, and maybe Wikipedia.) HiLo48 (talk) 21:48, 6 June 2018 (UTC)[reply]
  • Oppose Not appropriate to push that POV, even though many of us might agree with it. HiLo48 (talk) 08:14, 6 June 2018 (UTC)[reply]
  • Oppose per GenQuest. Wikipedia is not for righting great wrongs, in articles or otherwise. --Joshualouie711talk 15:13, 6 June 2018 (UTC)[reply]
  • Oppose We are not a forum, and that must just as much apply to this as anything else. Wikipedia must not and should not engage in advocacy. Once we do that then any claim of neutrality goes out of the window, we play into the hands of those who say we are not neutral.15:17, 6 June 2018 (UTC)Slatersteven (talk)
  • Support. Like the net neutrality proposal, this is not inherently political. Like net neutrality, this also has to do with something that threatens the very premise of WMF's purpose. But unlike net neutrality, this law may prevent EU users from accessing Wikipedia because Wikipedia doesn't pay the appropriate fees to news sources for using short snippets of text, and so forth.
    I initially thought this was about the image copyright law that banned images of certain structures in the EU, but this is much, much worse. Talk about heavy-handed... epicgenius (talk) 15:58, 6 June 2018 (UTC)[reply]
  • Support: this law will have very serious consiquences for Wikimedia projects as outlined by the proposer, Julia Reda, WMF, WMDE and others. John Cummings (talk) 15:48, 7 June 2018 (UTC)[reply]
  • Oppose – Wikipedia is not a soapbox, whether political or not. But wait, why would we think this is a bad idea anyway? Isn't a robust and effective filter to prevent copyright violations one of the things we've repeatedly asked the Foundation for in the various community wishes consultation exercises? Isn't it exactly what we desperately need and want for this project, instead of relying on a script written by a user and the one dedicated admin who monitors it? Since the vote is imminent, can we take it that the WMF has already dedicated substantial human and financial resources to preparing an effective filter in case it turns out to be needed? Will it be ready in time? Justlettersandnumbers (talk) 17:17, 7 June 2018 (UTC)[reply]
  • Support Before it is too late. Yann (talk) 20:42, 7 June 2018 (UTC)[reply]
  • Strong oppose - Copied from the recent proposal for a Net Neutrality banner, after reading much of this discussion (I can't say it any clearer than this). I'll note that something does not need to be "partisan" to be political by my understanding and use of the word. First definition at m-w.com: "of or relating to government, a government, or the conduct of government".
    Wikipedia is an encyclopedia, not a platform for political statements supported by a majority of the few editors who happen to show up in a discussion on this page. That's regardless of the merits of the issues or how Wikipedia might be affected by them. We are Wikipedia editors, not political activists (although each of us is free to be a political activist off-wiki). In my view, this proposal should go the way of the proposal to show an anti-Trump statement before the U.S. presidential election. Furthermore, I think we should consider an explicit policy against using the encyclopedia as a platform for political statements. ―Mandruss ☎ 21:13, 7 June 2018 (UTC)[reply]
  • Support per Guy Macon and Wnt. Jc86035's alternate account (talk) 06:43, 8 June 2018 (UTC)[reply]
    • I will abstain from voting. But just to point out that if we do it, we should have our own banner, as we did on de.wp and bg.wp. We are in a particular situation where Wikimedia projects have been carved out from the proposal as the text currently stands. We need to explain why we still worry with a little bit more nuance, at least on the landing page. --dimi_z (talk) 08:22, 8 June 2018 (UTC)[reply]
  • Support Wikimedia projects and the Wikimedia commununity get involved in any political issue which is an existential threat to Wikimedia projects. There is a preponderance of evidence that this political issue is an existential threat to Wiki and for that reason it is fine for us to take a political position. It is true that Wiki is "neutral" but neutrality is relative and rational and aligns with an ethical code. Our ethic code includes values like "publishing an encyclopedia" and "making the encyclopedia accessible". I feel that we have met an appropriate standard of evidence in this case, and I agree that WP:reliable sources say that Wikimedia projects are facing an existential threat with this political issue. It is fine for us to advocate, lobby, and demand our right to develop and provide access to the encyclopedia we are sharing. I also feel that it is not necessary to settle any political controversy around this issue. I am willing to acknowledge the legitimacy of critics' concerns about our incomplete information on the law and lack of total certainty that this law is bad. For me, it is enough that we are diligent to cite reliable sources which confirm that some authorities have identified a danger.
I see "oppose" !votes which suggest that Wikipedia should avoid reacting to any country's legislative process as a way of achieving neutrality. I feel that this is misguided, because while Wikipedia is neutral about many topics, we always take a position that every country should allow Wikipedia, access to information, and the educational resources we provide. I will not entertain anyone's arguments that restricting access to Wikipedia should be part of the Wikipedia mission. There is no reason why we should expect that the law of every country is best for Wikipedia. It is fine for us to say that Wikipedia is basically good, and to expect that the laws conform to the existence of Wikipedia. Citizens like us make laws for the public good. People do not exist to conform to laws which fail to consider the public good. It is right to start with the assumption that Wikipedia is good and that good laws will encourage its development. Blue Rasberry (talk) 21:31, 8 June 2018 (UTC)[reply]
  • Strong support A lot of the oppose votes seem to come from editors who won't be affected by this legislation, which makes me question if they truly understand the potential consequences. Speaking as someone who will be, from what I understand of it (correct me if I'm wrong), it will make it nigh-on impossible to do anything more than trivial edits. We would no longer be able to upload fair use images, cite web sources, or even quote copyrighted material. How on Earth are we supposed to write decent articles with those restrictions? This could be detrimental to Wikipedia and those in the EU who wish to edit it. The WMF may not be bound by this legislation, but my ISP will be. This is not just a political crusade. Adam9007 (talk) 22:03, 8 June 2018 (UTC)[reply]
  • Comment: Then do something about your law makers. Do you understand the current legislative actions affecting internet, copyright law, and legality of use for our users in China? How about Turkey? Spain? Thought so. Wikipedia is here for people to access—or not. They can do so, as best they can from the countries they live in. These are countries where they have –politically– elected the officials who then propose, debate, and enact the laws they deem necessary. We are not here to advocate for or against any such laws, any such country, or any such lawmakers. That's politics. We're here to build an encyclopedia. Period. GenQuest "Talk to Me" 00:13, 9 June 2018 (UTC)[reply]
Remember that proposed copyright legislation a few years back? It would have made many, many free images used here subject to copyright. We had a banner about that, because it would have directly and adversely affected us. I don't see how this is any different. Adam9007 (talk) 15:23, 9 June 2018 (UTC)[reply]
Yep. And I was against that action too, but consensus was against me. I stopped editing for about year afterwards, too, because I saw that these kinds of political actions would become perennial requests. Judging from, counting this one, three discussions so far just this year, I guess I wasn't far wrong. GenQuest "Talk to Me" 16:57, 9 June 2018 (UTC)[reply]
  • Conditional moot. This discussion will probably be closed after 20 June 2018. Steel1943 (talk) 22:38, 8 June 2018 (UTC)[reply]
  • Oppose - Just like the net neutrality discussion we had a while back: I'm sympathetic to the ideals, but I'm opposed to Wikipedia being used as a political platform regardless of ideology. Unless of course, the Wikimedia Foundation itself decides to release a statement themselves, but in any case, there are alternative outlets for statements like these to be expressed. Narutolovehinata5 tccsdnew 23:18, 8 June 2018 (UTC)[reply]
  • Strong oppose Direct advocacy on a political matter is about the farthest you can get from maintaining neutrality. "Please do not add commentary, your own point of view, or your own personal analysis to Wikipedia articles", to quote {{uw-npov2}}. Go start a blog if you want to publicize your opinions about political matters, whether in your own country or another. Nyttend (talk) 22:58, 8 May 2018 (UTC) This is intentionally copy/pasted from my vote on net neutrality. Nyttend (talk) 02:20, 9 June 2018 (UTC)[reply]
  • Strong support. The oppose voters must be missing the fact that a major part of fair use methodology that is absolutely essential for Wikipedia's functioning will be rendered effectively illegal unless Wikipedia tithes to every news source it cites and quotes. If we're not going to protest for the sake of the internet, then do it for the sake of Wikimedia's budget. Daß Wölf 02:37, 9 June 2018 (UTC)[reply]
  • Support. If the legislation passes, it would almost certainly be illegal to access most Wikipedia articles from the EU, and Wikimedia and/or individual contributing editors might be found liable for copyright violation. Certainly downstream commercial users would be found liable if they did not block access from the EU, even if Wikipedia and individual contributors were exempt. We need a banner within 3 days. — Arthur Rubin (talk) 04:48, 10 June 2018 (UTC)[reply]
  • Support: SOPA is a precedent, but this actually is much worse. Wikipedia is a name synonymous with open content online, and if they try to assert the "it applies to any website which serves European users regardless of where its being run from" card like GDPR is, this is an existential threat that goes much farther than just Wikipedia. ViperSnake151  Talk  15:28, 10 June 2018 (UTC)[reply]

WAIT, how is this political?

WAIT. before you oppose on 'not-political' grounds, be aware that this is not something that it politicised in the EU, it is something that has not been reported on in the media, and the public are largely not aware of. This EU proposal is far more dangerous than any of the net neutrality debates, in a direct way to Wikipedia. Net Neutrality doesn't directly affect Wikipedia, but the changes to copyright that article 13 contains may make it impossible for Wikipedia to operate in the EU; the 'link tax' might completely shut down access to Wikipedia in Europe if enforced, and the rules for copyright basically eliminate fair use, making all the European branch language Wikis largely impossible. That is way more of a big deal than a bit of political activism. Please do not bandwagon this one, THINK. I was against the other net neutrality banners, but this is NOT THE SAME THING. I urge you guys to please reconsider, because this is not a partisan political issue in the EU, and that this is actually a potentially huge existential threat to Wikipedia itself. Even Jimbo Wales has said so over on his talk page.​​​​​​​​​​​​​​​ — Insertcleverphrasehere (or here) 20:39, 5 June 2018 (UTC)[reply]

  • It is being done through the political process, thus it is political. The WMF isn't worried about it, so why should we be? TonyBallioni (talk) 21:01, 5 June 2018 (UTC)[reply]
Where have you been told that the WMF isn't worried about it? It is not a partisan issue like net neutrality, so Wikipedia wouldn't be 'taking sides'. This is trying to be snuck through the political process with nobody noticing. — Insertcleverphrasehere (or here) 21:09, 5 June 2018 (UTC)[reply]
Regardless, if this is a threat to the WMF model, then the WMF should be clearly issuing a statement against it and/or issuing something to say they support a message. (WMF supported the Protests against SOPA and PIPA). If we had this, I would see no problem then including a banner message to warn about this. --Masem (t) 21:16, 5 June 2018 (UTC)[reply]
Err, they already did: wmfblog:2017/06/06/european-copyright-directive-proposal/. Judging from the statement, WMF seems rather worried about article 13, which would probably make the WMF subject to some kind of liability. The European users and associations originally cared about other things, necessary for our copyleft wikis: freedom of panorama, public domain, orphan works. But then, maybe that's considered "political" too. --Nemo 21:17, 5 June 2018 (UTC)[reply]
  • I detest hidden pings; if you're going to ping me, at least make it so I can see my name. Anyway, I agree with Tony and Masem; if it's an existential threat in the view of the whole of the Foundation, not just Jimbo, something will be done. Moreover, it's not our place to attempt to sway the minds of voters regarding the proposed policies of their lawmakers. (Hint: contact your lawmakers and spread the word about this.) — Javert2113 (talk; please ping me in your reply on this page) 21:22, 5 June 2018 (UTC)[reply]
@Javert2113:Sorry about the hidden ping, I pinged everyone that had made a 'political' oppose above, and it was a long list of names. — Insertcleverphrasehere (or here) 21:51, 5 June 2018 (UTC)[reply]
It's fine. I'm just a bit grouchy today, to be honest. Thank you for the ping; I probably wouldn't have seen this otherwise. — Javert2113 (talk; please ping me in your reply on this page) 21:52, 5 June 2018 (UTC)[reply]
  • Whether or not the WMF is worried about it, or whether or not I'm personally worried about it, I still oppose. While I understand the proposed banner would not be encyclopedic per se, I think the general spirit of WP:NPOV should still apply to publicly-facing content and the proposed banner - linking to a site that says a specific piece of legislation "threatens everything you do" - is not in line with that. That said, I appreciate the spirit in which the banner is proposed. Chetsford (talk) 22:11, 5 June 2018 (UTC)[reply]
  • I think your guess is probably a good one. I'd be opposed to any type of persuasive banner regardless of the specific words used or the topic referenced. Chetsford (talk) 22:35, 5 June 2018 (UTC)[reply]
  • I think the issue is that it isn't clear exactly what consequences this might have, particularly for Wikipedia. Article 13 is pretty broad in its language, which makes it a bit unclear where it will be enforced and where it won't. When similar laws passed in Spain I know that google news shut down in that country (at least linking to Spanish publishers). A lot of these links are pretty fearmongery, and I am not sure anyone really knows what consequences this might actually have. Everyone seems to agree that it will be bad to some degree however. If a Lawyer from the WMF could give us confirmation on this (can someone ping somebody?) that would be the best. I'm not sure if wmfblog:2017/06/06/european-copyright-directive-proposal/ represents a WMF position on the topic or not... — Insertcleverphrasehere (or here) 22:44, 5 June 2018 (UTC)[reply]
  • The worst case scenario, it seems, is that Wikipedia in the EU goes the way Google News did in Spain. That, in the future, Wikipedia will be inaccessible to EU citizens. However, I oppose the persuasive banner regardless of the consequences. If the citizens of the EU, acting through their MEPs, decide WP is not welcome in the EU we should respect their decision, not chain ourselves in the guest bedroom and demand to stay. Again, though, I do appreciate the spirit in which the banner is proposed and agree it would be unfortunate if the worst came to pass. Chetsford (talk) 22:52, 5 June 2018 (UTC)[reply]
  • Meh, the WMF is not worried about it. They are insulated by being (as an entity) based in the US, the material based in the US etc. This will not impact Wikipedia or any of the major encyclopedias in any significant manner. It will be an issue for editors in the EU but as to how much - that remains to be seen. What it is highly likely to totally fuck right up is Wikia - a site that routinely (and is in fact built around) violates copyright. And since Wikia is a for-profit cash-generating machine of a certain someone, who happens to live in the EU and so is subject to EU law, its not surprising they are 'concerned' about legislation that will directly impact that. Only in death does duty end (talk) 10:10, 6 June 2018 (UTC)[reply]
  • Oppose We are not a forum, and that must just as much apply to this as anything else. Wikipedia must not and should not engage in advocacy. Once we do that then any claim of neutrality goes out of the window.Slatersteven (talk) 14:58, 6 June 2018 (UTC)[reply]
    • Too late. clpo13(talk) 17:06, 6 June 2018 (UTC)[reply]
      • The whole point of the project and the foundation is advocacy for free and open knowledge, for everyone to contribute, share and make money off. A highly radical concept in 2001 and still in most parts of the world. —TheDJ (talk • contribs) 19:33, 6 June 2018 (UTC)[reply]
        • Completely wrong. Not right at all. 100% wrong and 0% right. The point of the project is to provide that free and open knowledge. Not to advocate for it, or for anything else whatsoever. --Trovatore (talk) 19:36, 6 June 2018 (UTC)[reply]
  • Support although I doubt a proprosal on en-wiki can affect all other language wikis, so probably just here. I'm quite flabbergasted whenever I hear the "we shouldn't be doing advocacy"-line. Obviously we shouldn't be advertising for political parties or recommending the next big dietary supplement, but there's absolutely nothing wrong with telling our readers whenever a proposed policy would severely **** with our editing model. I wonder if one would get the same reaction if the proposal was more obviously authoritarian. It's also incorrect that the WMF hasn't said anything about this as explained above, and various elements of the WMF-affiliate ecosystem has been working against this, such as the WM EU-group (full disclosure, WMDK, which I'm a part of, has done so as well). Despite the carveouts for online encyclopedias in the proposal, it would still impact some of our other projects, as well as the general free-knowledge infrastructure, such as forced remuneration. Sincerely, InsaneHacker (💬) 16:28, 7 June 2018 (UTC)[reply]
I absolutely agree. This is not just a vague human rights thing, this is something that may well have direct financial consequences for WMF. On that bases I'd go as far as to support WMF overriding whatever consensus happens here to make the blackout happen. Daß Wölf 02:49, 9 June 2018 (UTC)[reply]

Julia Reda AMA

For those few interested, tomorrow Julia Reda (one of the few defenders of the Internet within the EU politics), is doing an AMA tomorrow at 12:00 CEST on reddit https://www.reddit.com/r/europe/ —TheDJ (talk • contribs) 14:03, 5 June 2018 (UTC)[reply]

Looks like it has started: https://www.reddit.com/r/europe/comments/8oywxz/i_am_mep_julia_reda_fighting_to_saveyourinternet/ --Nemo 11:29, 6 June 2018 (UTC)[reply]

Article outlining the threats of the law to Wikimedia projects

Cory @Doctorow: has written an article for Electronic Frontier Foundation that outline the threats posed by the law to Wikimedia projects and what can be done to oppose it:

— Insertcleverphrasehere (or here) 21:31, 7 June 2018 (UTC)[reply]

Wikipedia article on the subject

Directive_on_Copyright_in_the_Digital_Single_Market has been started, it is currently not very comprehensive, please help expand it. John Cummings (talk) 21:20, 8 June 2018 (UTC)[reply]

According to the (fairly critical) de:Leistungsschutzrecht für Presseverleger Germany has already such legislation, maybe that is something worth inspecting? Jo-Jo Eumerus (talk, contributions) 21:34, 8 June 2018 (UTC)[reply]
Germany already has the link tax aka article 11, see Google News (it failed miserably, so the EU lobbies are now proposing an even worse version). The biggest danger for Wikimedia is probably article 13 (mandatory upload filters and liability). --Nemo 08:31, 9 June 2018 (UTC)[reply]

How to/should we add a Wikidata item link to Authority control

Currently, there is no link from the {{Authority control}} navbar template to the Wikidata item page, where the information displayed is gathered. The Wikidata item page is where an editor may add/remove/correct authority information on a person/entity. A common complaint against {{Authority control}} is that the template (and thus Wikidata) contains information on the wrong subject, or that the links are useless, or the associated link is broken, or frustration from how/where to correct it (there are other complaints as well, but they are outside the scope of this discussion). This proposal/survey seeks to allow editors to more easily access the Wikidata item linked to the Wikipedia page to make such additions/removals/corrections. While gaining some support, it has been suggested at Template talk:Authority control#Adding Wikidata item link to aid navigation to poll a larger audience, so voilà.

A 'Wikidata item' link exists on the left hand margin of any Wikipedia page which currently has a Wikidata item associated with it, similar to commons, wikiquote, wikisource, wikispecies, etc. Also similar is our placement of a 2nd link to commons, wikiquote, wikisource, wikispecies, etc. at the bottom of the page in the external links, to aid navigation and visibility. So the addition of a 2nd link to Wikidata would be in line with current behavior.

This will not affect dormant transclusions of {{Authority control}}; i.e. those which do not display on the page.


Option 1 - RHS in-line 'Wd: Q2144892' links as the first item:

Pros: it's short, so the chances of adding an extra vertical increment to the height of the {{Authority control}} template is also small. After scanning all ~690k transclusions, 59.5% of {{Authority control}} templates display 3 or fewer links from Wikidata, and 90% display 7 or fewer, so at least those 60% would very likely retain their current height. Also, parameter suppression of some kind will probably happen in the next 1-few months, making even more templates 1-liners.
Cons: it's lumped together with the other authorities so it (Wikidata) might run the risk of being misidentified as an authority (which it isn't), but I've only seen this concern raised once (part of the reason I'm here). This hasn't been a problem with a sister template, {{Taxonbar}}, which has about ~50% of the transclusions of {{Authority control}}.


Option 2 - LHS 'Q2144892' link on a separate line:

Pros: less chance of being misidentified as an authority, and more obvious linkage to the corresponding Wikidata item than Option 1.
Cons: will force all {{Authority control}} templates that are 1 line tall (~50%) to be 2 lines tall.


Option 2Wd - LHS 'Wd: Q2144892' links on a separate line:

Pros: lowest chance of being misidentified as an authority, and more obvious linkage to the corresponding Wikidata item than Option 1 and Option 2.
Cons: same as Option 2, and slightly wider.


Option 2Q - LHS 'Q2144892' links on a separate line (stylistic variant of Option 2Wd; Q and 2144892 link to different pages):

Pros: same as Option 2, plus the additional link describing what Wikidata is, and is "cleaner looking" than Option 2Wd.
Cons: same as Option 2.


Option 2Wikidata - LHS 'Wikidata' link & RHS links display ID names instead of numbers:

Pros: same as Option 2, but much more reader friendly, and LHS is constant width regardless of Q# size, and the RHS (with this example) is slightly shorter than any Option 2.
Cons: same as Option 2.


Option 2pencil - LHS ' Edit this at Wikidata' link:

Pros: same as Option 1, and widespread use elsewhere, so intuitive.
Cons: less descriptive than Option 2Wikidata, and hard to see for users who invert browser colors.


Option 2edit - LHS '[edit on Wikidata]' link:

Pros: same as Option 2 and Option 2Wikidata, and widespread use elsewhere, and maximally intuitive.
Cons: possibly too enticing?


Option 3 - any of the above.

Pros: various.
Cons: various.


Option 4 - no change.

Pros: status quo.
Cons: less mobility to Wikidata, and thus less potential for editors to add/remove/correct information.

AC Wikidata item link survey

  • Option 2edit, 2Wikidata, 2pencil, 2Wd/2Q, 2, 1, in that order, as nom.   ~ Tom.Reding (talk ⋅dgaf)  23:18, 5 June 2018 (UTC)[reply]
  • Option 2Wikidata, if not, 2Wd, failing that, 2. I feel 2Wd is the best here, or failing that option 2. 2Q is bad and confusing. Option 1 is baaaaad. Personally, I'd just add the full Wikidata:Q2144892. The objectings (below) to this are silly, since it makes editing what is presented harder if there are errors, and presents Wikidata as authoritative.Headbomb {t · c · p · b} 23:52, 5 June 2018 (UTC)[reply]
  • Options 2edit/2pencil, 2Wikidata, 2Wd, and 2, in order. We shouldn't add it to the authority field, so option 1 is a no-go, and 2Q is confusing for the user. Option 2Wd gives the best indication of what the Q link is for, although just calling it "wikidata" would suffice. Option 2edit is probably the most clear, but the pencil reduces the template back to one line, which is nice. — AfroThundr (u · t · c) 00:47, 6 June 2018 (UTC)[reply]
  • Options 2 or 2Wd in that order. Oppose 1 as very bad. Oppose 2Q as too difficult for mobile users to navigate. I also oppose 2pencil and 2edit. IMO we should not be including calls to action such as "edit this" or "edit that" since it seems to encourage the least competent drive-by readers to start editing things and, while WMF projects do not demand much in the way of competence, Wikidata is not a good jumping off point. Chetsford (talk) 02:40, 6 June 2018 (UTC)[reply]
By that reasoning, the "V · T · E" in every navbox template should also be removed. There haven't been significant issues of navboxes getting messed up because of the edit links being displayed. We need to give readers some indicator of where the data is drawn from and how to make corrections or additions. — AfroThundr (u · t · c) 20:24, 8 June 2018 (UTC)[reply]
"V · T · E" isn't an overt call to action since none of those abbreviations will necessarily be obvious to the drive-by reader. "Edit" or "Edit here" or "Edit this" are all calls to action; it's an announcement to the reader that we want them to edit it. I don't really want every rando reader to start editing a Wikidata entry. "This Can Be Edited" would be a descriptive indicator that was not a call to action but space considerations would obviously preclude that. Chetsford (talk) 23:19, 8 June 2018 (UTC)[reply]
  • Option 4. There is no need for a WikiData link, especially since we now transclude most from WD (at least up to 22 per subject are transcluded, up to 43 possible). WD is NOT an authority, and anyway it is already linked from the toolbox. There is no ‘one size fits all’, on many articles, both the in-AC link ánd the link in the toolbox will be visible at the same time on one physical computer landscape oriented screen. No objection agains a ‘sisterlink’ like template at long articles (but no standard inclusions there either, it does need merit). —Dirk Beetstra T C 04:05, 6 June 2018 (UTC)[reply]
    • As it is relevant here, today I did this. The link to Commons is in the toolbox, anddisplaying it so prominently in this case suggests that there is more to get on Commons. However, commons in this case has just three other cropped immages of the same as in the article - nothing to ADD. For much of WD (we are set to transclude 43, we sometimes display up to 22), the WD link has NOTHING TO ADDin terms of authority control (and there are enough requests to have more parameters to be added ...). The inclusion at the bottom should be a choice, not a standard for the 10s of thousands of articles that have an AC. If WD really has more to offer, include a sister link. —Dirk Beetstra T C 00:12, 7 June 2018 (UTC)[reply]
    • On a short page like David H. Sanford the link in the lefthand box ánd on the AC would be almost next to each other, hence there is no easier access. —Dirk Beetstra T C 10:21, 8 June 2018 (UTC)[reply]
  • Option 4. The reason given as a "con" is actually a "pro". We don't have the WD link in other templates that are filled way too often from Wikidata (official website, commons cat, ...). AC is already a poorly designed reader-unfriendly template, and efforts are under way to drastically change it. Adding yet another link and another undecipherable code after a meaningless abbreviation is not the way to go. If not option 4, then whatever, but definitely not option 1. We shouldn't put IDs from unreliable wikis into our "authority control" templates (not just Wikidata, but also musicbrainz and so on). If any option 2 is chosen, then don't add the Q-number, just add "Wikidata", so readers have a better chance of knowing what the link means (something that should be done for all the others as well, give the short "name" of the site instead of the meaningless ID, so people know that they are looking at a link to a Czechian, Swedish, US, ... repository). Fram (talk) 06:56, 6 June 2018 (UTC)[reply]
    • I've added the 2 - names to give an idea of what I mean. Fram (talk) 07:07, 6 June 2018 (UTC)[reply]
      • I've renamed Option 2Names to Option 2Wikidata following convention & updated subsequent references to it.   ~ Tom.Reding (talk ⋅dgaf)  11:23, 6 June 2018 (UTC)[reply]
  • Option 4 per Beetstra and Fram. To be honest, I'd be quite happy if Wikidata folded but since that is unlikely to happen any time soon, the less connection there is, the better. - Sitush (talk) 07:12, 6 June 2018 (UTC)[reply]
  • Option 3 Adding the Wikidata link/ID is useful. Option 1 has the benefit of (almost) matching what is used in this template on other wikis (e.g., commons). I quite like the last Option 2Wikidata with the full display of the names rather than the acronyms and numbers. But any of the options would work aside from option 4. Thanks. Mike Peel (talk) 09:51, 6 June 2018 (UTC)[reply]

  • "No link to Wikidata" is painful. I think we've generally established that a template pulling from Wikidata should provide in the context of the template a way to edit the content at Wikidata (this is how Module:Wikidata functions broadly). OTOH, I don't think any of the options above provides the call to action in the way that Module:Wikidata does presently (the little pencil icon). I would prefer to see that here rather than the Wikidata ID or even the nomenclature for Wikidata.

    Regarding the specific proposals: Some Pencil Icon Version > 2Wikidata > 2. I'm partial to 2Wikidata for a non-Wikidata-specific related improvement. That said, I believe the intent is for the template to provide the links internally so that people who are curious about any particular identifier can understand (with some level of encyclopedicity) what it is they would end up looking at without taking up oodles of space with the template where it is provided (by use of the abbreviations). I'm not sure if those links are so valuable in fact or not, and I might suggest the general link to authority control/help:authority control suffices for "hey, what is this template doing? what are these links here for?" rather than specific links to each of the authority controls. That leaves me somewhere in the realm of option 2 as a last resort. Flat rejects: 2Wd for previous comments, 2Q per sea of blue rationale, 4 per first paragraph, 1 per con listed, and 3 because I have a specific preference. --Izno (talk) 13:14, 6 June 2018 (UTC)[reply]

  • Option 2pencil (per Izno) or Option 2edit . This has become the standard way of indicating "edit this on Wikidata". All of the presented options betray into thinking that Wikidata is one of the authority control files. It's not (is it?). The problem this proposal wants to fix is not that readers want to use Wikidata as an authority control; it's that editors can't find how to edit the actual authority files stored on Wikidata. – Finnusertop (talk ⋅ contribs) 16:23, 6 June 2018 (UTC)[reply]
I think you're the first person to enter this conversation that was aware (or at least vocal) about such standards!
I guess Option 2edit needs to be made for "[edit on Wikidata]"?   ~ Tom.Reding (talk ⋅dgaf)  18:04, 6 June 2018 (UTC)[reply]
  • Anything but 2Q Option 2pencil I disagree with the arguments for Option 4 that another wikidata link would be redundant, as it's not obivious in any way that the wikidata link in the sidebar had any connection to the data presented in the authority control template. The only option I am really opposed to us 2Q. It seems like an WP:EASTEREGG, is likely to be confusing when editors don't realize why they're not always being sent to the page they expected, and the single-character "Q" link is a small target to hit. --Ahecht (TALK
    PAGE    ) 16:46, 6 June 2018 (UTC)[reply]
  • Option 4 Per Sitush. Only in death does duty end (talk) 12:04, 7 June 2018 (UTC)[reply]
  • Option 4 - we already have a wikidata link in the toolbox. I agree with Sitush here. Ealdgyth - Talk 13:05, 7 June 2018 (UTC)[reply]
    • Then we should eliminate {{commons}}, {{wikiquote}}, {{wikisource}}, {{wikispecies}}, etc. too.   ~ Tom.Reding (talk ⋅dgaf)  13:42, 7 June 2018 (UTC)[reply]
    • The links to commons, wikiquote, wikisource, wikispecies etc are NOT STANDARD in the toolbox, as opposed to WikiData. As I said above, I did this. That template did, on that page, not ADD anything (not even in the toolbox). On most pages where AC is transcluded it does not necessarily add anything (especially since we have up to 22 identifiers transcluded, what is it supposed to do, even more identifiers to be found?). And I would not necessarily oppose careful use of a sister link to WD where it adds something. A blanket transclusion with AC is distinctly different from having a chosen sisterlink. —Dirk Beetstra T C 15:15, 7 June 2018 (UTC)[reply]
      • If the only concern against adding a WD link to AC is the presence of the same link elsewhere on the page, then it's an irrelevant concern due to the ubiquitous existence of the above templates, as described in the opening paragraphs of this proposal. Please read them.   ~ Tom.Reding (talk ⋅dgaf)  15:26, 7 June 2018 (UTC)[reply]
      • I'd also argue that "I don't like Wikidata, and/or I want it to go away, and/or I don't want to do anything to improve it nor Wikipedia" is antithetical to all involved Wikis, and also not a valid point, unless there are plans to dismantle the project.   ~ Tom.Reding (talk ⋅dgaf)  15:34, 7 June 2018 (UTC)[reply]
  • Option 4: per Beetstra and Fram; but Sitush raises the best argument. I've never seen the use of Wikidata, to be frank. But that's a conversation for elsewhere. — Javert2113 (talk; please ping me in your reply on this page) 15:50, 7 June 2018 (UTC)[reply]
    • I've never seen the use of Wikidata, to be frank. This is precisely what this proposal seeks to improve.   ~ Tom.Reding (talk ⋅dgaf)  16:10, 7 June 2018 (UTC)[reply]
      • Unless you meant figuratively seen, which I now suspect was the case, then yes, a conversation for elsewhere.   ~ Tom.Reding (talk ⋅dgaf)  16:14, 7 June 2018 (UTC)[reply]

AC Wikidata item link discussion

Please keep the discussion focused on the merits of the available options.   ~ Tom.Reding (talk ⋅dgaf)  23:18, 5 June 2018 (UTC)[reply]

I added some text to clarify 2Q. Johnuniq (talk) 23:34, 5 June 2018 (UTC)[reply]

Can we please promote this to an RfC, that attracts more editors and will get independent closure with a bit mere authority? —Dirk Beetstra T C 04:09, 6 June 2018 (UTC)[reply]

Why are the options confusingly numbered 1, 2, 2Wd, 2Q, 2, 3, 4? Could we change to having them as 1, 2a, 2b, 2c, 2d, 3, 4 - or something else that's more straightforward? In particular, we shouldn't have two that are just "option 2"! Mike Peel (talk) 09:53, 6 June 2018 (UTC)[reply]

I renamed the second option 2, that was my mistake. Fram (talk) 10:03, 6 June 2018 (UTC)[reply]

Pinging Headbomb & Chetsford, just to inform you that Option 2pencil and/or Option 2edit were created after your vote (and since you didn't vote Option 3 nor Option 4), in case you wish to amend. The available options appear stable now...   ~ Tom.Reding (talk ⋅dgaf)  11:32, 8 June 2018 (UTC)[reply]

Misleading opening statement

@Tom.Reding: you state: A 'Wikidata item' link exists on the left hand margin of any Wikipedia page which currently has a Wikidata item associated with it, similar to commons, wikiquote, wikisource, wikispecies, etc. Also similar is our placement of a 2nd link to commons, wikiquote, wikisource, wikispecies, etc. at the bottom of the page in the external links, to aid navigation and visibility. So the addition of a 2nd link to Wikidata would be in line with current behavior.

There s NO STANDARD LINK to commons, wikiquote, wikisource, wikispecies, etc. There IS a standard link to WikiData on all pages with an associated WikiData item. But as a list of non-exhaustive examples:

All have A WIKIDATA LINK in the toolbox, and NO LINK to commons, wikispecies, wiktionary, wikitravel etc.

At the time of my removal here, the article Giovanna Fletcher had a commons link at the bottom (IMHO useless as it did not provide significant material), and NO link to commons in the toolbox at the left.

Adding this link leads, by definition, to duplication, as opposed to other ‘sisterlinks’. —Dirk Beetstra T C 05:50, 8 June 2018 (UTC)[reply]

And anyway, also for those sisterlinks - since they can now be linked from the toolbox, barring exceptions those templates are, in my opinion, then excessive and should be removed, but that is not for here. —Dirk Beetstra T C 05:58, 8 June 2018 (UTC)[reply]

Just so we clearly understand the argument: we had sisterlinks in the document (e.g. through {{commons cat}}). Through WikiData coding that now sometimes results in duplication on the page as a second link to e.g. commons appears in the left hand box. Now, because we duplicate commons at the bottom in the article ánd in the top-left box, it is argued here that the duplication of the existing WD link in the left hand top box is fine. —Dirk Beetstra T C 07:34, 8 June 2018 (UTC)[reply]

@Beetstra: A link is shown in the sidebar to commons, wikispecies, etc. in the left-hand side-bar where it is available (defined as an interwiki link in the Wikidata entry, or as a manual interwiki). There is a large overlap between those links being shown and the sister project templates also being included (far from 100%, since there are many cases where those templates have not been added even if the link does exist, and there are templates that provide a link where it's not an interwiki on Wikidata). Of course, if a link doesn't exist, then it can't be shown, which is the case in the examples you have given here. Meanwhile, nearly every Wikipedia entry has a corresponding Wikidata entry, so you see that link in the sidebar far more often. So there is nothing wrong or misleading with the opening statement here. Mike Peel (talk) 11:09, 8 June 2018 (UTC)[reply]
P.S. a commons link now appears for the first item in your list as I just created it. Up to you if you want to add the photo that's on commons into the article. Mike Peel (talk) 11:19, 8 June 2018 (UTC)[reply]
Be careful, the photo is clearly of a different person than the subject of the article.--Ymblanter (talk) 14:25, 8 June 2018 (UTC)[reply]
If a commons cat exists for the page, a link will appear in the margin. If a Wikispecies entry exists for the page, a link will appear in the margin. If a Wikidata item exists for the page, a link will appear in the margin. Lo, if a <another wiki> entry exists for the page, a link will appear in the margin. If there's Wikidata item associated with the Wikipedia page (and no forced params in {{Authority control}}), then both the template and the link in the margin are 'dormant'. You've done an excellent job at finding variation on this theme, but not to prove the point you think you're making. The example pages above have Wikidata entries associated with them, but none of the other Wikis. Clearly you've misunderstood the system and need to reevaluate.   ~ Tom.Reding (talk ⋅dgaf)  11:12, 8 June 2018 (UTC)[reply]
No, I did not misunderstand. Your argument is still that duplication is fine because we do that elsewhere. I disagree, I would even oppose the other duplication - especially in cases where the corresponding commons cat does not add anything extra over what is already in the article, or just has limited content. —Dirk Beetstra T C 11:35, 8 June 2018 (UTC)[reply]
I would say we should get rid of {{commonscat}}, especially since it pulls data out of Wikidata anyway.--Ymblanter (talk) 14:30, 8 June 2018 (UTC)[reply]
@Ymblanter: I was indeed considering that we could get rid of all sisterlinks-type cats, as they are all in the tools. It is just duplication. —Dirk Beetstra T C 14:46, 8 June 2018 (UTC)[reply]
I personally would be fine with that, but I know some people feel very strongly about the sister links.--Ymblanter (talk) 15:01, 8 June 2018 (UTC)[reply]
I can see arguments for some cases to be there, but not general. There are indeed strong feelings there, would likely need an RfC. —Dirk Beetstra T C 15:11, 8 June 2018 (UTC)[reply]

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

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

RFC for an Altered Main Page Design

Following on from the discussion on the issue linked to above (point 16), a full RFC has been launched on the proposed style which is accessible here.

Please give your opinions on the new design. Nosebagbear (talk) 19:22, 6 June 2018 (UTC)[reply]

Minor visual update to access locks

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

  • (current) Freely accessible / Free registration required / Paid subscription required

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) Freely accessible / Free registration required / Paid subscription required

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 see of blue, e.g. (JSTOR 01234 Free registration required)

  • (old1) Freely accessible / Free registration required / Paid subscription required

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

  • (new2) Freely accessible / Free registration required / Paid subscription required

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

  • (new3) Freely accessible / Free registration required / Paid subscription required

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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
@Jbhunley: those get confused with HTML security locks like this one. Headbomb {t · c · p · b} 15:15, 8 June 2018 (UTC)[reply]
Ahh... I had not thought of that. Jbh Talk 15:19, 8 June 2018 (UTC)[reply]
  • 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. –Davey2010Talk 15:51, 7 June 2018 (UTC)[reply]
  • new1 per Davey. --Ahecht (TALK
    PAGE    ) 18:15, 7 June 2018 (UTC)[reply]
  • new 3. I don't think the red is necessary, and draws unwarranted attention. Natureium (talk) 18:20, 7 June 2018 (UTC)[reply]
  • 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)[reply]
@LittlePuppers: The mouseover text says it means "free registration required". --Ahecht (TALK
PAGE) 23:27, 7 June 2018 (UTC)[reply]
Ah, okay, I see that now. Thanks, Ahecht! LittlePuppers (talk) 23:38, 7 June 2018 (UTC)[reply]
  • 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)[reply]
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)[reply]
• 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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • new1 ~★ nmaia d 14:33, 8 June 2018 (UTC)[reply]
  • 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)[reply]

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

RfC on the enforceability of logged voluntary editing restrictions

There is currently a discussion at Wikipedia:Requests for comment/Enforceability of logged voluntary editing restrictions, all are invited to participate. TonyBallioni (talk) 14:07, 7 June 2018 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=845291235"