Jump to content

Wikipedia:Village pump (proposals): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
→‎Watchlist-message on a sister project proposal: Support, but no interlanguage notices
→‎Remove "suspected perpetrator" field in Template:Infobox civilian attack: closing discussion, per a request on the closing board
Line 38: Line 38:


== Remove "suspected perpetrator" field in [[Template:Infobox civilian attack]] ==
== Remove "suspected perpetrator" field in [[Template:Infobox civilian attack]] ==
{{atop|{{nac}} Consensus exists to remove the "susperps" parameter from [[Template:Infobox civilian attack]]. The rationale is based off of [[WP:NOTNEWS]], and concerns about BLP. In the aftermath of tragic incidents, news sources often rush to name suspected perpetrators, but can be wrong or sensationalist. Consensus is that WP should not unduly promote attackers, or possibly defame those wrongfully accused. Unless a perpetrator is known with a relative level of certainty, they should not be named in the infobox. In cases where a perpetrator is suspected, but not known, they should be discussed in prose only {{endash}} if at all. Discussion took this a step further and asked if the "perpetrator" param should be changed to "convicted", but there was consensus not to. I leave it to a template editor to make the appropriate change. [[User:CaptainEek|<span style="color:#6a1f7f">'''Captain Eek'''</span>]] <sup>[[User talk:CaptainEek|<span style="font-size:82%"><span style="color:#a479e5">''Edits Ho Cap'n!''</span></span>]]</sup>[[Special:Contributions/CaptainEek|⚓]] 04:54, 19 August 2019 (UTC) }}

(Discussion moved from [[Template talk:Infobox civilian attack#Suspected perpetrator field?]] on recommendation to gain full consensus.) I struggle to see the benefit of listing a "suspected perpetrator" in an infobox, especially when a suspect is part of an ongoing case and will be either removed or moved to "perpetrator" when that is complete. Looking at [[Christchurch mosque shootings]] and the contention over how prolific suspect Brenton Tarrant's name should be (see [[Talk:Christchurch mosque shootings#RfC about keeping suspect's/suspects' name in lead|ongoing RfC about keeping suspect's/suspects' name in lead]]), I don't think his name in an infobox offers any encyclopedic value (officially and legally, as little doubt as there is over his guilt, it has not been proved yet) and if anything only unduly promotes his name which we should also avoid. When a suspect is proven to be a perpetrator, they become part of the historical/encyclopedic record of the attack rather than the subject of a current matter/desire for notoriety. Christchurch is one particular case, but I don't think it's unique in this regard. I suggest this field be removed. [[User:U-Mos|U-Mos]] ([[User talk:U-Mos|talk]]) 03:28, 22 March 2019 (UTC)
(Discussion moved from [[Template talk:Infobox civilian attack#Suspected perpetrator field?]] on recommendation to gain full consensus.) I struggle to see the benefit of listing a "suspected perpetrator" in an infobox, especially when a suspect is part of an ongoing case and will be either removed or moved to "perpetrator" when that is complete. Looking at [[Christchurch mosque shootings]] and the contention over how prolific suspect Brenton Tarrant's name should be (see [[Talk:Christchurch mosque shootings#RfC about keeping suspect's/suspects' name in lead|ongoing RfC about keeping suspect's/suspects' name in lead]]), I don't think his name in an infobox offers any encyclopedic value (officially and legally, as little doubt as there is over his guilt, it has not been proved yet) and if anything only unduly promotes his name which we should also avoid. When a suspect is proven to be a perpetrator, they become part of the historical/encyclopedic record of the attack rather than the subject of a current matter/desire for notoriety. Christchurch is one particular case, but I don't think it's unique in this regard. I suggest this field be removed. [[User:U-Mos|U-Mos]] ([[User talk:U-Mos|talk]]) 03:28, 22 March 2019 (UTC)
:<small>(Comment copied from original discussion)</small> I concur. There's no reason for this parameter to exist – when the identity is known and certain, the appropriate parameter is "perpetrator", and when it is not, it doesn't belong in the infobox at all to begin with. [[User:TompaDompa|TompaDompa]] ([[User talk:TompaDompa|talk]]) 08:17, 22 March 2019 (UTC)
:<small>(Comment copied from original discussion)</small> I concur. There's no reason for this parameter to exist – when the identity is known and certain, the appropriate parameter is "perpetrator", and when it is not, it doesn't belong in the infobox at all to begin with. [[User:TompaDompa|TompaDompa]] ([[User talk:TompaDompa|talk]]) 08:17, 22 March 2019 (UTC)
Line 70: Line 70:
*Not sure if this means it's still open for votes, but if so '''support''' per [[WP:NOTNEWS]], etc. Any time it's actually warranted can be covered in article prose. &ndash; [[User:John M Wolfson|John M Wolfson]] ([[User talk:John M Wolfson|talk]] • [[Special:Contributions/John M Wolfson|contribs]]) 23:35, 18 May 2019 (UTC)
*Not sure if this means it's still open for votes, but if so '''support''' per [[WP:NOTNEWS]], etc. Any time it's actually warranted can be covered in article prose. &ndash; [[User:John M Wolfson|John M Wolfson]] ([[User talk:John M Wolfson|talk]] • [[Special:Contributions/John M Wolfson|contribs]]) 23:35, 18 May 2019 (UTC)
* Assuming it's still open for votes, I also '''support''' per Wolfson's reasoning, above. [[User:Gimubrc|Gimubrc]] ([[User talk:Gimubrc|talk]]) 18:46, 13 August 2019 (UTC)
* Assuming it's still open for votes, I also '''support''' per Wolfson's reasoning, above. [[User:Gimubrc|Gimubrc]] ([[User talk:Gimubrc|talk]]) 18:46, 13 August 2019 (UTC)
{{abot}}
<!-- [[User:DoNotArchiveUntil]] 05:14, 26 May 2029 (UTC) -->{{User:ClueBot III/DoNotArchiveUntil|1874466896}}
<!-- [[User:DoNotArchiveUntil]] 05:14, 30 August 2019 (UTC) -->{{User:ClueBot III/DoNotArchiveUntil|1874466896}}


== RfC: Add 'create an article' option in the interface ==
== RfC: Add 'create an article' option in the interface ==

Revision as of 04:55, 19 August 2019

 Policy Technical Proposals Idea lab WMF Miscellaneous 

New proposals are discussed here. Before submitting:



Remove "suspected perpetrator" field in Template:Infobox civilian attack

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.


(Discussion moved from Template talk:Infobox civilian attack#Suspected perpetrator field? on recommendation to gain full consensus.) I struggle to see the benefit of listing a "suspected perpetrator" in an infobox, especially when a suspect is part of an ongoing case and will be either removed or moved to "perpetrator" when that is complete. Looking at Christchurch mosque shootings and the contention over how prolific suspect Brenton Tarrant's name should be (see ongoing RfC about keeping suspect's/suspects' name in lead), I don't think his name in an infobox offers any encyclopedic value (officially and legally, as little doubt as there is over his guilt, it has not been proved yet) and if anything only unduly promotes his name which we should also avoid. When a suspect is proven to be a perpetrator, they become part of the historical/encyclopedic record of the attack rather than the subject of a current matter/desire for notoriety. Christchurch is one particular case, but I don't think it's unique in this regard. I suggest this field be removed. U-Mos (talk) 03:28, 22 March 2019 (UTC)[reply]

(Comment copied from original discussion) I concur. There's no reason for this parameter to exist – when the identity is known and certain, the appropriate parameter is "perpetrator", and when it is not, it doesn't belong in the infobox at all to begin with. TompaDompa (talk) 08:17, 22 March 2019 (UTC)[reply]
  • I agree. This gets into NOTNEWS territory. We have to be aware that a reported “suspect” can be falsely accused (for example: the reports that Richard Jewell was a suspect in the bombing that took place during the Atlanta olympics). At a minimum, we need to wait until a “suspect” is actually charged with the crime before we report names. Blueboar (talk) 12:59, 22 March 2019 (UTC)[reply]
  • I also agree. If suspects are to be named in the article then we can word things to make it clear that they are only suspects, and to say whether they have been charged or prosecuted, but an infobox entry is too blunt an instrument for such sensitive content. Phil Bridger (talk) 13:33, 22 March 2019 (UTC)[reply]
  • The idea makes sense, but I know from how less experienced editors see infobox fields and if you took out the suspected perp field, they will want to fill the name in on the actual perp field because they feel it would complete the infobox (unaware of the implications of this towards BLPCRIME). --Masem (t) 13:36, 22 March 2019 (UTC)[reply]
    • Well, that gets us into the murkier question of what fields should be included in an infobox in the first place. Perhaps we shouldn’t even have a “perpetrator” field. Indeed, when it comes to this sort of topic, we probably need to question whether an infobox is aporopriate at all. Is an infobox an appropriate method for conveying information in an article about a mass killing? Blueboar (talk) 13:55, 22 March 2019 (UTC)[reply]
      • Arguably yes, it just shouldn't be filled in until after conviction. (Contrast that to a religon= field in the BLP infobox ) Its that well-intentioned editors unaware of why the field is blank will think to fix it blindly. --Masem (t) 14:09, 22 March 2019 (UTC)[reply]
        • Deprecate |perpetrator= and add |convicted_perpetrator=. --Izno (talk) 14:15, 22 March 2019 (UTC)[reply]
          • That would of course mean that when the perpetrator dies and there is no trial, there is nowhere to add them. Which is not necessarily a bad thing. TompaDompa (talk) 17:28, 22 March 2019 (UTC)[reply]
            • I think we should find a way to identify the perpetrator in some such cases, for example if there is a mass shooting that ends with the perpetrator killing himself (it's nearly always a "him"). The best way to deal with this whole issue would be for Wikipedia to stop trying to be a news service and only to have articles about events when good secondary sources (which breaking news reports are not) exist, but people putting forward that point of view always seem to get shouted down by people saying, "of course it's notable, it's front-page headlines in all the newspapers." Phil Bridger (talk) 17:50, 22 March 2019 (UTC)[reply]
            • And in cases where the perpetrator dies and there is no trial I believe that there's a difference between jurisdictions. In some places an inquest into the death of a victim will name in its verdict the person who caused the death, and in others it will not. Phil Bridger (talk) 17:54, 22 March 2019 (UTC)[reply]

I support changing "perpetrator" to "convicted" - feels more appropriate for factual record rather than mere description of an event, and hypothetically if there was an appeal in process or new doubts over a historical case it wouldn't invite any unnecessary infobox changes. U-Mos (talk) 06:23, 23 March 2019 (UTC)[reply]

Changing Wikipedia's infoboxes because some politicians want to play damnatio memoriae is not a good idea. Offering a choice of a "convicted" field per User:U-Mos is reasonable, but a plain "perpetrator" field should remain as an option even so. Because sometimes, for example, a widely known perpetrator might flee to ISIS territory or the next equivalent and not be prosecutable. Suspected perpetrators also should be described when sources widely describe the accusation. (WP:WELLKNOWN) Wnt (talk) 07:42, 23 March 2019 (UTC)[reply]

I don't see how describing suspected perpetrators in the infobox, where the room for nuance is scant to none, would be helpful. In prose is a different matter. TompaDompa (talk) 10:34, 23 March 2019 (UTC)[reply]
Why not? There are a lot of cases where the perpetrator is known beyond reasonable doubt but will never be convicted. Judicial sentences are not the only reliable source of information. On contrary there are cases where the person convicted is known not to be the perpetrator! Would not it be helpful to describe convicted but not guilty persons in the inforbox where the room for nuance is scant to none helpful? You seem to put to much trust in formal convictions. In addition, what is conviction? There is no clear definition of this term. Ruslik_Zero 08:45, 24 March 2019 (UTC)[reply]
That a convicted person may not be the perpetrator seems a very good reason for the change to me. Having the field as "convicted" removes any form of supposition, leaving any nuances or complications to the prose where they can be outlined in all necessary detail. U-Mos (talk) 08:53, 24 March 2019 (UTC)[reply]
This is incredibly poor reason. 90% people do not read beyond the infobox. Ruslik_Zero 13:47, 27 March 2019 (UTC)[reply]
  • Convicted is not quite the right answer. If the perp dies he is not convicted. If he confesses or brags/claims responsibility we can name without conviction. I'd venture that at least half the places this box would be used never see a conviction. Legacypac (talk) 09:28, 24 March 2019 (UTC)[reply]
  • Creating an additional template for suspects and one for perpetrators would remove all the confusion. ~^\\\.rTG'{~ 23:35, 25 March 2019 (UTC)[reply]
  • Oppose. In some cases it is appropriate for us to name the perpetrator prior to his conviction (e.g. when extremely widely reported in highly public events, or when the suspect evaded capture and trial (which in many places can't be done in absentia) - but it known with a high degree of certainty). In other cases - e.g. historic cases, events in warfare, etc - while we might not have a definite perpetrator it might still be appropriate to name in the infobox those covered extensively in RSes. Icewhiz (talk) 11:45, 2 April 2019 (UTC)[reply]
  • The template should first be merged into {{Infobox event}}; then the parameters should be rationalised. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:40, 2 April 2019 (UTC)[reply]

Note: This proposal was restored from the archive for the purpose of consensus being assessed and the discussion closed. TompaDompa (talk) 22:31, 18 May 2019 (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.


RfC: Add 'create an article' option in the interface

Should we add a "Create an article" button/link in the interface/sidebars? Headbomb {t · c · p · b} 02:04, 7 July 2019 (UTC)[reply]

The problem

One thing that always puzzled me is why we don't have a "create an article" button in the sidebars. Or similar. Imagine you want to get involved on Wikipedia, and you barely know a thing about it, but you want to create an article about say Hymenopterida, an insect superorder.

Tell me, how do you figure how to create that. There's nothing to guide you. If you search for 'create' in your interface, you have the option to create a book. There's nothing to create an article. There's no help link, no create button, no draft option, no tutorial, nothing. So, I propose we add a "Create an article" link/button to the interface, which would direct people to a landing page similar to

Welcome to Wikipedia, the encyclopedia anyone can edit! Because you do not have an account, you cannot yet create articles directly in the encyclopedia. You must first register an account and gain experience as a Wikipedia editor.

Once you have a registered an account, the following pages will help you gain this experience

  • Help:Getting started, which has several tutorials and primers about Wikipedia conventions and policies
  • Help:How to edit, which explains how exactly to edit the encyclopedia
  • Wikipedia:Sandbox, a page where you can freely experiment without having to worry about breaking anything

After you have created an account, you will be able to create an article through the Article wizard, which will guide you through the process, and explain basic concepts like notability, verifiability, and what reliable sources are. At the end of the process, your article will be created as a draft, and experienced editors will review it. Be aware that the reviewing process currently has a 2+ months backlog, with 1,257 pending submissions waiting for review.

which 'tab' you would land on would depend on your user access levels, and we could customize the advice/information to target the experience level of the person landing on that page. Headbomb {t · c · p · b} 19:10, 7 July 2019 (UTC)[reply]

!Vote (old proposal, withdrawn)

This discussion has been closed. Please do not modify it.
The following discussion has been closed. Please do not modify it.
  • Support as proposer. Headbomb {t · c · p · b} 02:04, 7 July 2019 (UTC)[reply]
  • Support. Sounds like a great idea that would help convert our readers into editors. The article wizard is an ideal place to direct new editors to, since it encourages them to use non-public-facing areas of Wikipedia (the sandbox, a user space sandbox, and the draft space) to create content. These areas are low-pressure "safe zones" where editors can get familiar with our editing tools (wikitext or the VisualEditor) without the pushback of being reverted after making a mistake. Hopefully, these zones help new editors learn the ropes and eventually become comfortable enough to participate in other areas of Wikipedia. — Newslinger talk 02:35, 7 July 2019 (UTC)[reply]
  • Oppose - Editors should not be creating articles before they know something how how to edit Wikipedia, what its aims and policies are, and how articles should be made. Adding a "create an article" link is only going to provoke a lot of badly written, poorly sourced, stub and sub-stub from people more interested in self-aggrandizement then in improving the encyclopedia. Let people spend some time here first during which they can learn the lay of the land and, in the course of it, learn how to create an article. Beyond My Ken (talk) 04:38, 7 July 2019 (UTC)[reply]
  • Oppose within the current framework. See my comment under discussion. Espresso Addict (talk) 05:12, 7 July 2019 (UTC)[reply]
  • Oppose At this age, Wikipedia should not be encouraging brand-new editors to create articles upfront; apart from the link being misleading because new editors and IPs cannot create articles technically. People should reasonably be conversant with wikitext and minor tasks until such time they intuitively find the way to create articles, that's the time they should do that. That process is an important learning curve and may takes days, week or months depending on the prior experience of the individual, but it does not matter. – Ammarpad (talk) 05:31, 7 July 2019 (UTC)[reply]
  • Oppose as premature. See my comment in the discussion section. Kudpung กุดผึ้ง (talk) 06:16, 7 July 2019 (UTC)[reply]
  • Oppose per above. We need to encourage the improvement of existing articles more than the creation of new crap ones. MER-C 11:07, 7 July 2019 (UTC)[reply]
  • Oppose per comments by Ammarpad above and Kudpung below. At the moment, the most direct way to create a new article comes either from first searching the wiki for existing references, or expanding upon a redlink, both good starting points for a new editor. MarginalCost (talk) 13:13, 7 July 2019 (UTC)[reply]
  • Oppose the existing procedure forces the person further along the learning curve before creating an article. Granted, possibly not far enough, but why make things worse?--Wehwalt (talk) 14:11, 7 July 2019 (UTC)[reply]
  • Oppose - AfC is drowning in unreviewed drafts. I don't believe NPP is much better off. Anyone who knows enough to be able to write a basic article, knows how to go about doing so (or ask how). Anyone who doesn't, shouldn't be having it made easier for them. Nosebagbear (talk) 15:28, 7 July 2019 (UTC)[reply]
  • Neutral - I support the sentiment/aim; there are probably people who could be great editors intimidated by the learning curve or where to look. But, and this might be because I've spent some time on Wikia lately (where there is a page in the interface for this), I fear this is likely to get people to start creating articles just because they can (i.e. not good ones) in a way that's likely to increase low-quality or speedy-able articles (and increase work for people involved in their maintenance) much more than it's likely to find good ones. - Purplewowies (talk) 16:33, 7 July 2019 (UTC)[reply]
  • Oppose – I agree with Ammarpad's and Nosebagbear's reasoning. Levivich 16:36, 7 July 2019 (UTC)[reply]

!Vote (new proposal)

  • Support as proposer. I agree directing people to AFC directly isn't ideal, so instead I propose we direct them to a landing page explaining how to get involved in Wikipedia. Headbomb {t · c · p · b} 19:20, 7 July 2019 (UTC)[reply]
  • Oppose Neutral If anything, we should be taking steps to make it harder for brand-new editors to create articles. I spend a fair amount of my reviewing copyright reports, and the number are by brand-new editors attempting to create a brand-new article, largely by copying and pasting some reliable (or not so reliable) source.--S Philbrick(Talk) 19:18, 7 July 2019 (UTC)[reply]
@Sphilbrick: I moved your !vote to the new section, since you made it after the revised proposal. However, time-wise it's pretty close to when things were reshuffled, so I'm pinging you to make sure your !vote reflects the current proposal and not the old one. Headbomb {t · c · p · b} 19:24, 7 July 2019 (UTC)[reply]
Headbomb, Thanks for the heads up. S Philbrick(Talk) 20:59, 7 July 2019 (UTC)[reply]
@Sphilbrick: Wikipedia:Article_wizard/Referencing also now warns against copy-pasting from sources, for what it's worth. I hope this brings you in the support category. Headbomb {t · c · p · b} 21:05, 7 July 2019 (UTC)[reply]
  • Support new proposal – I think it will help those who want to create new articles more easily learn how to do it and how to do it the right way. That, in turn, would make things better at AfC and NPP. I particularly like that it can specifically cater to editors based on their experience level. Levivich 19:45, 7 July 2019 (UTC)[reply]
  • Support. My rationale for the previous proposal also applies here, with modifications. This sounds like a great idea that would help convert our readers into editors. Headbomb's tutorial is an ideal place to send new editors to, since it directs them to essential reading that helps them understand Wikipedia's conventions and expectations. Then, it encourages them to create drafts in non-public-facing areas of Wikipedia (their user space sandbox and the draft space). These areas are low-pressure "safe zones" where new editors can get familiar with our editing tools (wikitext or the VisualEditor). Since they're drafts, and not live articles, patrollers won't revert the new editors immediately after they make a mistake, which can be burdensome for patrollers and discouraging for new editors. Any outstanding issues get addressed when the editors ask for help, or are ready to submit the drafts for review. Hopefully, these zones help new editors learn the ropes at their own pace, and eventually become comfortable enough to participate in other areas of Wikipedia (including draft reviewing and new page patrolling). — Newslinger talk 20:43, 7 July 2019 (UTC)[reply]
  • Support I think this is an excellent proposal. Giving new people proper direction on how to get started is a good thing. CThomas3 (talk) 21:40, 7 July 2019 (UTC)[reply]
  • Support new proposal. The landing page is a good idea. Also, this process seems to be a good way to get new productive editors involved in Wikipedia. If new editors can create acceptable articles then they might have a stake in participating here. This may encourage them to participate in other areas that need editors. Also, learning how to create acceptable articles is a great way to begin learning how editing works on Wikipedia. ---Steve Quinn (talk) 06:35, 8 July 2019 (UTC)[reply]
  • Support It's bizarre that the sidebar has comparatively obscure options like Create a book but doesn't have the fundamental option of creating a new article or page. I regularly create articles and do so by generating a red link and then clicking through on that – a process that is not intuitive and which would be hard to explain to a new editor. Andrew D. (talk) 08:48, 8 July 2019 (UTC)[reply]
  • Support with reservations. I like the general approach but before bringing the whole thing into general use, I think it needs to be carefully tested, perhaps in conjunction with specific virtual editathons. Reactions from new users and their reviewers should be taken into account.--Ipigott (talk) 12:43, 8 July 2019 (UTC)[reply]
  • Support new proposal. It will help new users to create drafts first, instead of live articles. I also like the customized landing depending on editor status. Megalibrarygirl (talk) 15:01, 8 July 2019 (UTC)[reply]
  • Support Trial - like the idea and even the execution is snazzily slick. I do however think Ipigott has something on it being trialled. I'm not sure if limiting it to a virtual editathon is the only way to go, but an 8 week trial would be good - see whether hits on those pages, and page/draft creation, vary significantly. Nosebagbear (talk) 17:54, 8 July 2019 (UTC)[reply]
  • Support a trial - provided some dedicated attempt is made beforehand to figure out whether WMF has something similar in the works already (as noted below). Not much point in working at cross purposes! Otherwise, this strikes me as a well-executed improvement. Some more work on the exact content will be necessary. E.g., auto-confirmed users may be more "experienced" then fresh IPs, but they still should be strongly steered towards AfC and cautioned against direct mainspace creation. Also, pointers to the Adventure sounds like a good idea. --Elmidae (talk · contribs) 19:15, 8 July 2019 (UTC)[reply]
  • Support a trial - This is a much better approach. Obviously, the various texts can probably be tweaked a little, but the concept is certainly worth a try. Beyond My Ken (talk) 01:09, 9 July 2019 (UTC)[reply]
  • Support for trial only. I don't think we can really know whether this will lead to an increase in articles we would want to keep, or if it will lead to an increase in junk and disappointed contributors. There's only one way to find out. But there would have to be a thorough review by the community after the trial, before anything should be implemented permanently. --Tryptofish (talk) 18:35, 9 July 2019 (UTC)[reply]
  • Oppose We already have too many articles, already. Fully a third of all articles ought to be deleted. I wouldn't support anything that encourages the hoi polloi to create articles. Chris Troutman (talk) 23:28, 9 July 2019 (UTC)[reply]
  • That makes sense. After all, it's not like we invite everyone to edit Wikipedia, or anything like that. As has been said numerous times in the past, everything has already been discovered anyway. Beyond My Ken (talk) 04:04, 11 July 2019 (UTC)[reply]
  • Support trial only: While my general sentiment is aligned with that of Mr. Troutman (namely, we have too many articles), I can't see the harm in running a trial of this. Any further attempts to expand such a trial to the entirety of Wikipedia would depend on the data received, community sentiment and discussion, etc., etc. Javert2113 (Siarad.|¤) 00:03, 10 July 2019 (UTC)[reply]
  • Support a trial for the many good reasons articulated above (and below) by Elmidae, Tryptofish, Kudpung, and others. Happy days, LindsayHello 06:15, 12 July 2019 (UTC)[reply]
  • Support giving it a try at the very least. XOR'easter (talk) 17:26, 12 July 2019 (UTC)[reply]
  • Oppose I don't think that directing people to create new articles as a form of editor recruitment is a good idea. Most articles written by new editors are deleted pretty quickly as unsuitable. Sending them through AfC is better but will still result in the submission being declined, possibly repeatedly. At this point the new editor is unlikely to continue. As Wikipedia has matured its standards for articles have increased and the number of suitable topics which don't have articles has shrunk, meaning that articles from new editors are much less likely to be useful. I suspect that the main effect of this will be to push up the AfC and/or NPP backlogs rather than to recruit more editors. We would be better off directing them to improve existing articles instead. Hut 8.5 13:08, 13 July 2019 (UTC)[reply]
  • Oppose as this will result in more junk to delete and therefore an increase in admin/reviewer workload (a department which is already badly understaffed). Agreed that improvements should be made to help newbies get involved, but this is not it. -FASTILY 22:40, 14 July 2019 (UTC)[reply]
  • Support as trial per Newslinger. Directs users to the correct places and tutorials, before they make bad articles that get deleted. ~~ OxonAlex - talk 09:30, 16 July 2019 (UTC)[reply]
  • Weak oppose WP:CIR applies across everything we do here, so you should at least know some of the basics before being given a button to create anything. But maybe a trial would be useful instead. Lugnuts Fire Walk with Me 15:09, 16 July 2019 (UTC)[reply]
  • Oppose per the reason I gave in opposing the original proposal now hatted. I still believe this would end up doing more harm than good; for instance by driving off more users (whose crap in mainspace would summarily have to be deleted). If we "must" add any link to the sidebar, it should be a link to some tutorial about fixing typos or the like. – Ammarpad (talk) 00:05, 17 July 2019 (UTC)[reply]
  • Oppose the reason it's so difficult to figure out how to create an article is because its so difficult to create an article that won't be deleted. * Pppery * it has begun... 01:30, 17 July 2019 (UTC)[reply]
  • Tentative support of a trial. I like making it easier to actually make an article, but am wary if it makes more junk as such. Only one way to find out....Cas Liber (talk · contribs) 03:57, 17 July 2019 (UTC)[reply]
  • Support. Great idea, worth a try and solves a common problem with some helpful links. I like the customised landing pages. --Tom (LT) (talk) 08:34, 17 July 2019 (UTC)[reply]
  • Still oppose, per Hut 8.5. New users should not even be encouraged to create drafts, judging by the amount of rubbish that gets submitted to AFC or deleted as G11/U5. MER-C 09:04, 17 July 2019 (UTC)[reply]
  • Support a time-limited trial to allow us to evaluate whether this would create more signal or more noise. Sandstein 10:54, 17 July 2019 (UTC)[reply]
  • Oppose NPP and AFC are already overloaded and backlogged and this will just heap more cargo on a struggling ship imv Atlantic306 (talk) 22:52, 17 July 2019 (UTC)[reply]
  • Oppose. Aside from the arguments above, we already have data from Commons indicating that unregistered users were uploading way too much junk to make this a worthwhile enterprise. Our current "new article" systems are already overloaded, and this is just far too tempting to trolls to use in creating articles that are deeply, deeply problematic. I suggest that the hypothetical difficulty in creating a new article (which doesn't really exist, since any registered account can do so) is in the quality aspects, not the mechanical ones; and the few unregistered users who have the ability to create a new article that will survive already have AfC. Risker (talk) 01:58, 18 July 2019 (UTC)[reply]
  • Still oppose, As I said above, as every AfC and New Page reviewer knows - and they are the only people who have an overview of what gets created nowadays - the last thing we want to be doing is making it too easy to create more junk. There is no disputing the fact that the encyclopedia has matured since its creation. The vast majority of new articles nowadays are obscure BLP from South Asia, Bollywood, Phillipino Beauty Pageants, reality shows, one-line stubs about soccer players, newly named asteroids, nn US political candidates, and blatant corporate spam. One of the reasons why there is so little interest in doing NPP is because there is nothing interesting to see nowadays - it's all just grunt work. Kudpung กุดผึ้ง (talk) 04:23, 18 July 2019 (UTC)[reply]
  • Oppose per all of the above. All this would do would be create more work for AfC reviewers, NPPers, and CSD admins. TonyBallioni (talk) 17:45, 18 July 2019 (UTC)[reply]
  • Oppose as per everyone above - This will simply mean more crap gets created and then more crap gets deleted, AFC & NPP reviewers have enough to do let alone this, On paper it sounds great but in reality not so much. –Davey2010Talk 13:26, 19 July 2019 (UTC)[reply]
  • Oppose A better link to place would be to the 20,000 already established articles needing cleanup. Learning how to clean an article is an extension to creating one, and just as valuable.  Spintendo  04:21, 21 July 2019 (UTC)[reply]
  • Support a general 'Become an editor...' or similar link. The real problem as per Headbomb is that there is no "Become an editor..." or "Become involved..." link - I would strongly support such an inclusion. All I can see now is the obliquely titled 'Community' on the sidebar. I don't support a "Create an article" link though. A number of editors above make convincing arguments as to why this should be a general link rather than a "Create an article" link. --Tom (LT) (talk) 22:27, 22 July 2019 (UTC)[reply]
    Yeah that would work too. Headbomb {t · c · p · b} 04:05, 23 July 2019 (UTC)[reply]
    Then that problem can be easily solved without even the need for an RfC. Just rename "Community portal" to "Get involved...," "Become an editor..." or whatever. The link basically already has this information though in an inconspicuous location: the tooltip of the link says "About the project, what you can do and where to find things." Needless to repeat, the portal has ideal links for new editors. – Ammarpad (talk) 20:01, 24 July 2019 (UTC)[reply]
    @Ammarpad: wrong section? Because I don't know what "Community portal" is. It's certainly not anywhere in the interface. Headbomb {t · c · p · b} 20:13, 24 July 2019 (UTC)[reply]
    It is the third item under the "Interaction" section in the sidebar. Unless you're using something that hides it, I am not sure how you're not seeing it. Here is the source text for the sidebar: MediaWiki:Sidebar, and the source text "Community portal". – Ammarpad (talk) 20:27, 24 July 2019 (UTC)[reply]
    Also a really good idea. If we end up linking to the community portal, we should probably give it a bit of a redesign to reduce information density first. Enterprisey (talk!) 10:17, 8 August 2019 (UTC)[reply]
  • Oppose for reasons I expressed in re the original proposal. At the moment, the most direct way to create a new article comes either from first searching the wiki for existing references, or expanding upon a redlink, both good starting points for a new editor. While the new language is nice, many articles are clearly created by those who haven't read the existing edit notice at the top of the page itself when you create a new article. As others have stated, at this point in the wiki's development, there is less need to encourage the creation of new articles, and more need to encourage the development of existing pages. MarginalCost (talk) 15:14, 25 July 2019 (UTC)[reply]
  • Support a trial. The growth and survival of WP depends upon the continual recruitment of new editors, and most new editors are likely to come because they have articles they want to write. However, for at least the last 12 years, at least half the submitted articles have been unsatisfactory. We have succeeded in moving most of the potentially problematic new articles--those by new editors--to Draft space, and it is therefore just as expected that most of them will not be acceptable, at least initially. It is therefore all the more essential that we provide prospective new-article writers with a clear route to make articles. The current method, of looking for an article and not finding it as the basic route to make an article is incredibly obscure, and what nobody coming here could expect. We need a clearly indicated route from the beginning, in a reasonably prominent way. The Article Wizard is a over-elaborate over-prescriptive way, but it works, and following it will not lead people astray. We need to find a way of making it much more prominent. Those who have worked on the general problem of creating and screening articles should reconsider opposition to this: it's in the spirit of WP to try new ideas. DGG ( talk ) 23:23, 26 July 2019 (UTC)[reply]
  • I'm a solid oppose here per the conclusions of the NPP/AFC crowd. --Izno (talk) 23:00, 27 July 2019 (UTC)[reply]
  • Support I know that when I created my first article, it certainly took me a while to figure out how, and I already had 200+ edits at the time. Let's do it. WizardKing 01:23, 30 July 2019 (UTC)[reply]
  • Support at least for a trial. This is a known deficiency in the interface. I'm a bit concerned with sending people to the AFC process, which we know is ineffective. If it can't support the influx of contributions after a week or two, the trial should be switched to posting directly to main namespace, which tends to be more efficient. Nemo 06:44, 31 July 2019 (UTC)[reply]
  • What Tom said. Yes to whatever makes the learning curve here less steep, but not by encouraging them to create articles (or drafts or anything standalone). Can we have a project page that allows new users to get feedback on whether potential new articles are likely to survive? For example, we can allow them to link to several sources for editors to evaluate potential WP:N compliance before the article is written. feminist (talk) 16:20, 1 August 2019 (UTC)[reply]
  • Oppose in this form. I like the thought here but there's already a 'Help' link under Interaction that prominently includes guidance on how to create an article. If that's proving hard for new editors to find (understandable - it's pretty vague), it might be best to add a second link immediately below called "Help build Wikipedia" or similar, pointed at Wikipedia:Contributing to Wikipedia or possibly Help:Getting started, rather than making another help page that would need to be maintained separately. For the reasons others have given, we probably want to encourage newbies to contribute by editing before they start creating and I think this way would achieve that better. › Mortee talk 22:02, 1 August 2019 (UTC)[reply]
  • Oppose. New users should not be invited to start new pages. Instead, they should be invited to improve existing content. Creating new pages is the hardest, and doing it through AfC segregates the newcomers from mainspace editing other users. Newcomers competent to start a new page will discover how to soon enough, incompetent newcomers being led down the glossy AfC path to rude mistreatment is not good for anyone. --SmokeyJoe (talk) 03:13, 5 August 2019 (UTC)[reply]
  • Oppose. New users should not be jumping in and creating new pages; all that will lead to is more nn-bios and one-liners to clean up. I appreciate there are hurdles in the way of creating new articles, but they are there for good reason. Better that they improve the articles we already have. Stifle (talk) 09:54, 8 August 2019 (UTC)[reply]
  • Support per DGG. Enterprisey (talk!) 10:15, 8 August 2019 (UTC)[reply]
  • Support per DGG. Creating a new page is one the main attractions for new volunteers, and telling them "we don't want you to do that, volunteer elsewhere" is unlikely to make them continue volunteering. —Kusma (t·c) 10:22, 8 August 2019 (UTC)[reply]
  • comment (mostly oppose, but also some support...). Oppose asking for "create an article", as probably that should not be the very first thing of a new editor (hmmm... it might have been mine... :-) but it was over a decade ago in a quite different wikipedia). Note that we do not lack articles although we do not have such a link for... almost 20 years or so? So maybe it is not exactly greatly needed. If implemented it should be a trial, i.e. with a time set and should only become permanent after a new RfC. Support, if this is reworded as a call for help, i.e., how to improve current content. - Nabla (talk) 00:49, 10 August 2019 (UTC)[reply]
  • Oppose per Ammarpad, Hut 8.5 , MER-C, Risker and Kudpung, and due to my past work in clearing out the speedy deletion and expired prod backlogs. My experience in this area echoes theirs. Adding Smokey Joe's reasoning. I've not yet formulated a clear, concise way to explain it to them without putting them off, but I agree that new editors need to learn their way around the 'pedia as regular editors before diving into article creation. It's both better for them psychologically, and better for the 'pedia. - CorbieV 21:05, 12 August 2019 (UTC)[reply]
  • Oppose per CorbieVreccan.--Vulphere 15:56, 13 August 2019 (UTC)[reply]

Discussion (Create an article)

I just clicked through Wikipedia:Article wizard and did not see anything about notability (well, there is "For further information, please visit our guide on notability" but someone wanting to write about their garage band is not going to see that). A "create article" link is setting new editors up to fail or at least to be frustrated by waiting for the overloaded draft review. The article wizard would first need toughening up. It needs a section on notability and a section with links on asking questions. Johnuniq (talk) 04:00, 7 July 2019 (UTC)[reply]

  • Please let's not channel more good-faith newbies into Articles for Creation, which is where the wizard sends people. It was never designed as a nurturing place for good-faith newbies to make their first edits. Espresso Addict (talk) 05:10, 7 July 2019 (UTC)[reply]
    AfC is a much better and user-friendly route than normal new page patrolling, as someone who patrols pages occassionally, rest assured, most of them are not treated as nice, with a "this is wrong", "this needs to be fixed", but more of a "your article is wrong in this way, and will be deleted, get it?" --qedk (tc) 05:58, 7 July 2019 (UTC)[reply]
I disagree. Sitting waiting for perhaps months until someone gives you a capsule review that takes a degree in wikispeak to unwrap, and then just says "no" in acronym speak, appears to me even worse than a swift speedy. At least the speedy route is quick, contains appeal instructions, and might just throw you in the way of a friendly admin. Espresso Addict (talk) 06:06, 7 July 2019 (UTC)[reply]
I seem to recall a long discussion involving I believe Kudpung on where to send genuine newbies in the context of mainspace creation being permanently turned off for non-autoconfirmed editors, but I don't think there is a suitable venue at present. I'd certainly support creating one but I doubt it's as easy as it sounds. Espresso Addict (talk) 05:58, 7 July 2019 (UTC)[reply]
Well, whatever is at the end of that link (WP:Create an article/WP:Article wizard/WP:Your first article/WP:Whatever we decide) could be a general landing page, with a short explanation that to create articles in the mainspace, you need to have some Wikipedia experience, or you go through the article wizard and upload them as Drafts so others can review them. Headbomb {t · c · p · b} 06:09, 7 July 2019 (UTC)[reply]
In my experience, this [1] is the kind of article that newbies submit on species (let alone the much more complex taxonomic entities), and that was far from the editor's first edits, and positively stellar compared with the worst I've tripped over. And with species, there's none of the problem with notability that plagues say (auto)biographies. Espresso Addict (talk) 06:22, 7 July 2019 (UTC)[reply]
  • As every AfC and New Page reviewer knows - and they are the only people who have an overview of what gets created nowadays - the last thing we want to be doing is making it too easy to create more junk. There is no disputing the fact that the encyclopedia has matured since its creation. The vast majority of new articles nowadays are obscure BLP from South Asia, Bollywood, Phillipino Beauty Pageants, reality shows, one-line stubs about soccer players, newly named asteroids, and blatant corporate spam. Help should be offered immediately at the registration interface, and as far as I know, the WMF is working on a new landing page right now - a long awaited project since they originally started and disbanded it under various pretexts in 2012. Let's give it time to develop, and let's not lose the breathing space we gained with the introduction of ACPERM which we fought 7 long years for. Kudpung กุดผึ้ง (talk) 06:18, 7 July 2019 (UTC)[reply]
    • Couldn't agree more. I urge anyone about to caste a !vote here to go have a good look at the new page queue before they say anything. Article creation should be one of the last tasks new editors are guided towards, not the first. Triptothecottage (talk) 13:04, 7 July 2019 (UTC)[reply]
  • Updated with just 273‎ bytes to address concerns raised in this section....Wikipedia:Article_wizard/Referencing.--Moxy 🍁 06:45, 7 July 2019 (UTC)[reply]
  • The problem is that the slogan 'the encyclopedia anyone can edit' has been allowed to be interpreted too loosely. Anyone can also ride a bike or drive a car, or sail a 470, or fly a Cessna 152, it's easy enough, but there is a learning curve (that's why kids bicycles have training wheels), and the rules of the road, the sea, and the air have to be learned. A good Article Wizard can do much to help, but the whittled-down-to-nothing thing that's replaced what we had used before ACPERM was rolled out is all but useless, and that's why AfC is so backlogged. The Article Wizard should be the training wheels.Kudpung กุดผึ้ง (talk) 07:47, 7 July 2019 (UTC)[reply]
  • Wikipedia Tutorial Button? - all the answers above are bang on. But how about instead of just avoiding making our job (AfC/NPP) harder, we push some more people towards a tutorial, whether WikiAdventure or otherwise? Nosebagbear (talk) 15:30, 7 July 2019 (UTC)[reply]

@Espresso Addict, Kudpung, Nosebagbear, Beyond My Ken, MarginalCost, MER-C, Wehwalt, Purplewowies, and Levivich: How about a landing page that looks something like User:Headbomb/Create an article? I've also added the mockup to the above so you could see what it would look like. Which 'tab' you would land on would depend on what useraccess level you have, so this could be tailored to the experience level of each person landing there. Headbomb {t · c · p · b} 19:07, 7 July 2019 (UTC)[reply]

Headbomb, that I like and support... funneling the editor through the right process depending on their experience level. Nice work! (And thanks for the ping.) Levivich 19:27, 7 July 2019 (UTC)[reply]
@Levivich: well, the new !vote section is up. Headbomb {t · c · p · b} 19:30, 7 July 2019 (UTC)[reply]
Exactly something like that is what the WMF is currently working on. But we all know what goes on at Phab. Perhaps Insertcleverphrasehere, the defacto coord of NPR knows, or Primefac, the de facto coord of AfC. Kudpung กุดผึ้ง (talk) 00:17, 8 July 2019 (UTC)[reply]
Other than the WP:AFCIMPROVE discussion from May 2018, I have not heard anything about changing or updating any part of the AFC process. Primefac (talk) 01:08, 8 July 2019 (UTC)[reply]
Kudpung, I'm also not aware of an active project on this, though I am currently only following the stuff on Phab that is directly related to the NPP wishlist items. — Insertcleverphrasehere (or here)(click me!) 05:12, 8 July 2019 (UTC)[reply]
@Headbomb: - I'd suggest adding the Adventure for the latter 3 (I realise that like WP:CENT, it becomes less valuable the more you have). Regardless of that, looks nice (I also had no idea that you could set viewing by permission level, but obviously that makes sense because the same occurs when you hit an editing lock) Nosebagbear (talk) 11:33, 8 July 2019 (UTC)[reply]

Pinging those who opposed based on some variant of 'there's too much shit at AFC/users need more experience' so far (@Chris troutman, Hut 8.5, Fastily, Lugnuts, Ammarpad, Pppery, MER-C, Atlantic306, and Risker:)

Well, a few things:

  • The AFC instructions have (since the start of this RFC) been tweaked to put the big don'ts front and center. For example, Wikipedia:Article wizard/Referencing now much more strongly hammers the three main points: Copyright, Notability, and what is and isn't proper referencing. Compare with the old version.
  • Likewise, once at AFC, {{AFC submission/draft}} now warns against copyright violations, writing with a NPOV, and hammering that it's a bad idea to write about yourself or your business (COI stuff is the majority of the crap at AFC). Compare with the old version which only told people where to go for help.
  • {{AFC submission/helptools}} is now also much more helpful at directing people towards resources (compare with old version) leveraging the power of WikiProjects to get feedback and suggesting to look at good/featured articles to have models of quality writting.
  • Wikipedia:Article_wizard/CreateDraft now gives an estimated timeline, so people are aware of roughly longs things will take.

This is at least worth trialing, I feel.

Concerning the 'lack of experience', well, these landing pages is a way to direct these people how how to get that experience. It's telling them "Yes, you can create pages, but it's a bit daunting to do that right of the bat, so instead consider doing these things instead, for example try doing [examples of easy tasks]." We have to have a way of recruiting the curious. Yes there will be shit submitted with general incompetence. But we too were shit/generally incompetent once. We're the encyclopedia anyone can edit. We made the internet not suck. And we need to remember that we too were once eager to join. We could create articles right off the bat. We submitted shit. We sucked. But we learned. So we need to have something for those that are eager to learn how to join us. Newbies deserve to have a link for them in the interface somewhere, and it's not by being a bunch of "disgruntled elitists that we're going to grow the movement. If you don't support a 'create article', we at least need a "Start editing / Get involved" sort of landing page. Headbomb {t · c · p · b} 02:47, 18 July 2019 (UTC)[reply]

Headbomb, I hear where you're coming from. But even though I may have been a not-good editor once, it was harder then to create an article than it is today by a long shot (we had no AFC, and almost no help pages), and I'm glad it was because my first article would no doubt have been (appropriately) deleted even back in those much more liberal days. However, we've automated so many of the "entry level" roles such as fixing typos and minor copy editing and reverting vandals that it is much more difficult to start off easy than it was pre-2010 or so. I still do not think that it's a good idea to stick a "create an article" button anywhere obvious, although I'd be okay with an automated message on the talk page of a newly registered account. (It would also be an interesting thought experiment to come up with tasks suitable for newbies that don't involve article creation, and including them in the automated message.) We're actually one of the few projects that *don't* post an automated welcome/informational message to new users. The message will likely remain on their talk page through unconfirmed and autoconfirmed periods at least, so they won't be losing the links. I fully expect anyone who reaches "extended confirmed" level to be capable of figuring out themselves how to create a new article. Risker (talk) 03:09, 18 July 2019 (UTC)[reply]
@Risker: Well, that's what the tabs can be used for! If you're a complete newbie, we can tell you where to go to learn. If you're autoconfirmed, you know a bit more, so we can tell you something a bit more relevant to you!
Put yourself in the shoes of a good faith and completely new editor, you don't know anything about Wikipedia works, except you want to get involved because it sounds fun, and you know something we don't have information on. You don't even have an account. How do you get involved? You see the "edit button" at the top of a window, so you guess you'll click that because you hear people can edit it and want to see for yourself. And then you're presented with a bunch of legalese and warnings. Or you land on a semi-protected page, and you don't even have an "edit button" anywhere.
What's better? That experience? Or, seeing a "Get started" link in the sidebar, so you click that, figuring if you want to get started, that's probably the place where you'll learn the how of Wikipedia. With such a link, we can give you advice of on you can contribute, where to go to get help, and what not to do, without you being on the ass end of {{uw-nor3}} after your first edit because you didn't know how to add references properly. Headbomb {t · c · p · b} 03:29, 18 July 2019 (UTC)[reply]
I could live with the two words "Get started" or "Things you can do" or something like thatin the Interaction box on the sidebar, linking to an appropriate page. Not "Create an article", which is just asking for trouble we don't need and are already having a hard time managing. It could probably be a rename of the Community Portal and its link, since there are a lot of "getting started" ideas there already; simply add a section on "create an article" there. Just keep in mind, what we're talking about here isn't what's in the current proposal. Risker (talk) 03:42, 18 July 2019 (UTC)[reply]
  • The article creation process would scare away too many newbies too early. I'd support adding a link to something like Help:Getting started in the sidebar. --Yair rand (talk) 05:25, 18 July 2019 (UTC)[reply]
  • I agree with the general sentiment that something should be done to encourage new editors to find stuff to do, but I also agree that this explicitly needs to exclude article and draft creation. Encouraging article creation leaves us with a bunch of drive-by editors creating articles or drafts with the usual COI, spam and notability problems. There are plenty of other things to do - expand stubs, categorize articles, and so forth - and it should be easy to find those tasks in a particular topic area a new editor is interested in. Building an encyclopedia requires substantial effort and is not suitable for everyone. MER-C 10:39, 18 July 2019 (UTC)[reply]
  • "We have to have a way of recruiting the curious" No, we don't. We have new editors join everyday that figure it out. Wikipedia attracts a special sort of self-selector that gets it. Efforts like these attempt to bring on the strap-hangers that will never make significant contributions. My first Wikipedia article was Dragon Seed (novel). That same day I also created The Raising of Lazarus (Rembrandt). Neither are very pretty or developed but I didn't need help or AfC. Why would anyone else? Chris Troutman (talk) 13:17, 18 July 2019 (UTC)[reply]
  • I agree with the idea of having something in the sidebar to encourage readers to become editors, I just don't think article creation is what it should point to. If people click on that button and actually write something then the vast majority of the time they will have a very bad experience when the article gets summarily deleted/rejected, so it won't be very good at attracting new editors. It also isn't free as it takes scarce editor time to deal with these creations/submissions. Putting up warnings or instructions won't necessarily help that much. If you try to create an article now you see a message saying you should cite references to reliable published sources, not violate copyright and other good stuff, and it strongly recommends you read a long page which gives you a good overview of what we want. None of this stops people writing rubbish articles. They either don't read it or falsely don't think it applies to their article. Hut 8.5 17:52, 18 July 2019 (UTC)[reply]

Proposal to add suicidal disclaimer at Suicide

This has been rejected before but I would like to raise this point again. Viewers of Wikipedia who are suicidal are more likely to search the Suicide Article than any other articles and as they read more info on suicide they may look at methods to commit suicide that are on the article and may actually replicate it.

I’ve seen many disclaimer that were added on top of the suicide article then they were deleted as there was a page on Wikipedia that tells Wikipedians how they respond to suicide threats from wikipedians. However most of the suicidal viewers are probably not wikipedians, they’re just random visitors of Wikipedia who just went to the suicide article to find out methods to attempt suicide.

Just by adding a disclaimer and redirecting them to the suicide crisis line on the top may just help them get out of that thought of committing suicide. So I’m proposing that we should add that disclaimer on the Suicide Wikipedia article just so we can prevent people committing suicide as a result of viewing that page. I also propose to add the same disclaimer on the Suicide Methods so they don’t replicate any sort of suicide attempts. — Preceding unsigned comment added by OfficialNeon (talkcontribs) 23:42, 19 July 2019 (UTC)[reply]

I'm broadly in favor of adding the top most visible and respectable national or international suicide prevention resources to the external links section. I proposed something similar years ago for the article for Rape and it was fairly broadly opposed. So I don't expect it will get consensus, but I'm still in favor of it. We're only one of the most popular websites in the world and all. GMGtalk 00:05, 20 July 2019 (UTC)[reply]
  • Support: I don't see anything wrong with adding such a disclaimer if you ask me. We're here to present facts, not encourage or condone any method of self-harm as what the suicide methods article may seem to imply, even if our job here is not to provide advice for things. Second, there's a similar disclaimer on articles like WikiLeaks telling people that Wikimedia has no affiliation with the site despite the name. TV Tropes, while more informal and less factually reliable, does take suicide seriously, and would go to lengths to advise suicidal individuals to seek help. Not that we'd add suicide counseling advice on each and every article though, but a general piece of advice to dissuade and comfort those who are depressed shouldn't hurt. As mentioned in the talk page, "the importance of harm reduction outweighs the importance of policies like WP:NPOV that might guide us under normal circumstances to leave out such a hat note." Blake Gripling (talk) 03:01, 20 July 2019 (UTC)[reply]
Can we do a hatnote that is geographically targeted by IP address? If so that would seem sensible and responsible to me. ϢereSpielChequers 09:08, 20 July 2019 (UTC)[reply]
@WereSpielChequers: that's not very feasible; if we did want to put something on these pages, perhaps a hatnote linking to Crisis hotlines. — xaosflux Talk 14:38, 20 July 2019 (UTC)[reply]
As mentioned in previous discussions on this topic, what would be preferred is instead a wikilink to List of suicide crisis lines. MPS1992 (talk) 15:28, 20 July 2019 (UTC)[reply]
If we can do geo targeted watchlist notices we can certainly do this, maybe with a little programming. The vast majority of IP addresses can be linked to a country, so those countries where we do have a crisis line we could put a hatnote. ϢereSpielChequers 21:18, 20 July 2019 (UTC)[reply]
I would suggest that whatever is selected look as neutral and as part of the encyclopedia as possible. Flashing lights and "NO, DON'T DO IT" would frighten the reader away. A hatnote, whether geographically targeted or no, puts the opportunity before the reader.--Wehwalt (talk) 22:46, 20 July 2019 (UTC)[reply]
+1.
I'd support something along these lines, which guides an interested reader who inadvertently arrives at Suicide while searching for help on the subject, while not being flashy or condescending towards the general reader. Abecedare (talk) 23:12, 20 July 2019 (UTC)[reply]
That example strikes me as appropriate and fitting with the style of Wikipedia. Particularly if the assertion that people looking for such information reach the general article is true; I have no evidence either way on that point, and benefit of the doubt here seems reasonable. Anomie 00:19, 21 July 2019 (UTC)[reply]
Well, when I search "how to commit suicide" the third result is Suicide methods. GMGtalk 01:05, 21 July 2019 (UTC)[reply]
We don't do disclaimers in articles and we also don't disguise them as bad hatnotes. – Finnusertop (talkcontribs) 13:42, 21 July 2019 (UTC)[reply]
Templates such as 'unsourced' may have been intended as editorial calls to action, but they also caution readers to take the contents of a page with a pinch of salt. Wikipedia does disclaimers, it just doesn't usually call them that. Richard Nevell (talk) 14:14, 21 July 2019 (UTC)[reply]
@Richard Nevell: WP:NODISCLAIMERS, which I linked to, explains why cleanup templates are one of very few exceptions to this rule. – Finnusertop (talkcontribs) 19:03, 21 July 2019 (UTC)[reply]
Indeed, which should be a sign that asserting "We don't do disclaimers in articles" might oversimplify things when some nuance is in order. Richard Nevell (talk) 19:50, 21 July 2019 (UTC)[reply]
afaIk, this would be better done with an extension, a script instead of a template. viztor 02:58, 21 July 2019 (UTC)[reply]
"Dynamic" content in articles break caching, indexing, and possibly other services that rely on us. Keeping in mind the "readers first" line of thinking, lets not break things with any sort of assumption about "where you are" when displaying article content. Anomie's example of leading readers of the encyclopedia to an article about support is pretty good and doesn't try to guess which thing you should see. — xaosflux Talk 04:48, 21 July 2019 (UTC)[reply]
Credit where it's due: The idea was Abecedare's, I just liked it. Anomie 11:22, 21 July 2019 (UTC)[reply]
  • Support - Certainly I see nothing wrong with something along these lines. While a geo-specified method would be nice, I'm concerned that cases where it was inaccurate would make it less helpful than a generic answer and link Nosebagbear (talk) 12:58, 21 July 2019 (UTC)[reply]
  • Thinking about this more, I don't really like putting a non-content banner of some sort on this page - the crisis lines are already linked at the bottom of the page. I suppose possibly a hatnote to the actual article on Suicide crisis might be editorially acceptable - as readers may actually be looking for that subject. — xaosflux Talk 14:37, 21 July 2019 (UTC)[reply]
  • I'm against this idea although the sentiment behind the proposal is a good one. Two reasons: 1. People find this article through Google, Google already includes crisis information and local hotlines. 2. There's not really any good evidence that suggests crisis hotlines are actually helpful at preventing or limiting self harm.[2] --188.250.220.217 (talk) 21:22, 21 July 2019 (UTC)[reply]
Opposed "Don't do heroin" or "If raped call" is simply not our purpose....that said external links to help groups would be OK in my view.--Moxy 🍁 01:47, 22 July 2019 (UTC)[reply]
Comment - And yet we have this policy page. Some things need not be didactic imho, but I guess it's all up to consensus. What I believe in is that we shouldn't just let suicidal people come in to the pages in question and carry out some form of self-harm as described there. Blake Gripling (talk) 02:04, 22 July 2019 (UTC)[reply]
WP:SUICIDE is unrelated to this proposal, and is certainly not an endorsement of this proposal. Banana Republic (talk) 02:13, 22 July 2019 (UTC)[reply]
  • Oppose. No disclaimers on articles. --Yair rand (talk) 04:21, 22 July 2019 (UTC)[reply]
  • Oppose. See guideline Wikipedia:NODISCLAIMERS. While I think this is a serious issue and I have sympathy with the intentions behind it, I do not think it is the job of the Wikipedia to give advice or tell people what to do or think. --Hecato (talk) 07:42, 22 July 2019 (UTC)[reply]
  • Support. There's nothing wrong with a quick note on the page. As others have noted, we have disclaimers on some pages. They're usually in the form of a short hatnote. A quick one-line hatnote, along the lines of "If you're considering suicide, please visit List of suicide crisis lines" should be enough to help people that may be considering suicide, and not significantly detract from the purpose of Wikipedia. I believe that Wikipedia's goal is to help as many people as possible learn as much as they can, and to encourage people to help others. I'd be willing to bet that there have been at least one person that has committed suicide and has read the Suicide article beforehand, and could have been helped with just a little compassion and just a single line that tells them that there is someone out there that cares. If we can save just one life, the policies don't matter. Just my 2 cents. andritolion (talk) 07:55, 22 July 2019 (UTC)[reply]
  • Oppose I would question the effectiveness of such disclaimers. The Hellenic Army has in recent years created its own suicide line, trying to reduce its chronic issues with drafted soldiers committing suicide. It has not done much to reduce the reasons for suicide, such as the poverty of the soldiers (the monthly payment for a Greek soldier in 2019 is 8.70 euros, equivalent to 9.76 American dollars), the isolation of soldiers from their families and friends, or the lack of treatment for their health problems The suicide rate in Greece (526 suicides per average year) has increased in recent years, despite the availability of suicide lines. Dimadick (talk) 10:04, 22 July 2019 (UTC)[reply]
    @Dimadick: I'm not an expert on the subject so wouldn't wish to comment on the efficacy of disclaimers. Perhaps it would be worth asking an organisation such as the Samaritans who would know more about this sort of thing for their views? Richard Nevell (talk) 18:28, 22 July 2019 (UTC)[reply]
    I don't think that asking an organisation such as the Samaritans would be helpful. I have no doubt that their volunteers have the best interests of suicidal people at their hearts, but they are not the best people to judge their own effectiveness. It is best for us to follow robust independent academic research. I haven't looked into such research, so it may or may not conclude that suicide helplines are effective, but any decision should be based on such research rather than on anecdotal evidence or intuition, which seems to be all that has been offered in this discussion. Phil Bridger (talk) 18:42, 22 July 2019 (UTC)[reply]
  • Support a hat note link to List of Suicide crisis lines. Wikipedia exists in the real world and a meta study of suicide prevention suggested that we don't know if these lines are effective or not. But it also appears its not harmful. And the inclusion of a single hatnote is not harmful to Wikipedia. So this low cost way is not harmful and might beneficial to our readers. Further, suicide ideation is inherently different from drug addiction and so those analogies just don't hold water for me. Best, Barkeep49 (talk) 14:13, 22 July 2019 (UTC)[reply]
  • We should not simply reject this on the basis of WP:NODISCLAIMERS. That is a guideline that was created by Wikipedia editors, and we can choose as Wikipedia editors to make an exception in this case. There is no ancient wisdom that was possessed by those who wrote the guideline but not by us. I do, however, have strong doubts as to whether it will actually achieve anything. As well as the issue of whether crisis lines actually prevent suicide, there is also the issue of whether telling someone about such lines actually leads to people using them when they wouldn't otherwise have done so. It is just possible that such directions could cause active harm. Any decision about this should ideally be based on robust academic research, rather than the gut feeling that we should do something. When it comes to human psychology intuition is often wrong. Phil Bridger (talk) 15:11, 22 July 2019 (UTC)[reply]
  • Comment I am meh with regards to a note of the form For agencies offering couselling about the subject see..., which is (or, at least disguised as) a navigational aid. But I'm strongly opposed to any hatnote of the form If you’re thinking about suicide, it’s important to know that you’re not alone. See... that directly addresses the reader and offers them life-advice; that goes against WP:ENC (fwiw, see also EB's article on suicide).
More broadly, my main two concerns regarding adding any hatnote are (1) the slippery-slope argument that Moxy has alluded to (where do we stop offering links to "helpful" resources: mental traumas, mental disorders, physical diseases, natural disasters, general trigger warnings ...?) and (2) the ineffectiveness argument mentioned by Dimadick (would the hatnote do anything except make us feel good about ourselves for doing something?). I'd like to see some thought-out arguments against those objections before I can support making an exception to WP:NODISCLAIMERS. Abecedare (talk) 16:20, 22 July 2019 (UTC)[reply]
  • Comment I would support Abecedare's example text here [3], since that is a genuine navigational aid to something related that people could be looking for. But anything more aggressive than that shouldn't be added to the article without some evidence that it might actually help. Red Rock Canyon (talk) 21:43, 22 July 2019 (UTC)[reply]
  • Oppose First of all the best avaliable evidence does not show a benefit in decreasing the risk of suicide. Here we have a 2016 review article in Lancet Psychiatry that says hotlines are of unclear benefit.[4] There are things we know that do work such as removing guns and other easily methods of suicide from the home. So if we are going to put a hatnote on the page it should contain advice that is better supported. Second why was this raised here on July 19th without notifying the talk page of suicide? This discussion has occurred lots of times there. For those who support this what is the evidence of benefit? Doc James (talk · contribs · email) 02:44, 23 July 2019 (UTC)[reply]
    Here is the full reference Zalsman, G; Hawton, K; Wasserman, D; van Heeringen, K; Arensman, E; Sarchiapone, M; Carli, V; Höschl, C; Barzilay, R; Balazs, J; Purebl, G; Kahn, JP; Sáiz, PA; Lipsicas, CB; Bobes, J; Cozman, D; Hegerl, U; Zohar, J (July 2016). "Suicide prevention strategies revisited: 10-year systematic review". The Lancet. Psychiatry. 3 (7): 646–59. doi:10.1016/S2215-0366(16)30030-X. PMID 27289303.
    I would support linking to helplines and ignoring all rules if there was evidence that such help lines work. Doc James (talk · contribs · email) 18:56, 23 July 2019 (UTC)[reply]
    Should we have a hatnote which recommends that people remove potential methods of suicide from the environment of those who are suicidal? At least that is known to be effective. Doc James (talk · contribs · email) 08:57, 29 July 2019 (UTC)[reply]
  • Support Hi all. I’m one of the lawyers at the Wikimedia Foundation, and I work in particular on issues related to threats of harm and similar risks. We’ve had a number of cases where people working on Wikipedia have contacted us because of threats of suicide to provide help for them, and one of my colleagues flagged this discussion to me. I think this is an important issue and I hope I can be helpful by sharing some sources that we’ve looked at and offering my thoughts on the matter based on what I’ve seen in dealing with suicide-related topics on Wikipedia.
I support a community addition of a message at the top that lets people reading the article know about resources that might be available to them if they’re considering suicide. It’s likely that a significant share of the population that looks into topics like suicide and suicide methods are doing so because they are considering suicide. I and a number of my colleagues believe that links to resources for seeking help do lead to saving lives, and a couple of the sources cited below provide some information on how these sorts of resource links have worked.
I would also note that as a matter of best practices, other online platforms that host user contributions, as well as a number of organizations that work to prevent suicide, recommend banners or similar notices to assist people. While Wikipedia is not quite like any other website, I think the way that people use it to search for information about difficult topics means that can be helpful to apply these best practices for suicide-related topics.
Wikipedia articles also appear prominently in search results related to suicide. I’ve linked a couple examples below: about 5,000 thousand people a day view the Wikipedia article on suicide, and 9,000 a day view the suicide methods article. So, changes that might have a small statistical effect can have a significant impact in practice.
Studies
Pageviews:
Industry and help group recommendation pages
-Jrogers (WMF) (talk) 06:58, 23 July 2019 (UTC)[reply]
Would this put the WMF in a position where they may be liable for directing thousands of people to a third party for advice? Any liability issues per Section 230 of the Communications Decency Act? We currently say Wikipedia:Medical disclaimer " Nothing on Wikipedia.org or included as part of any project of Wikimedia Foundation, Inc., should be construed as an attempt to offer or render a medical opinion or otherwise engage in the practice of medicine." Wikipedia:General disclaimer "If you need specific advice (for example, medical, legal, financial or risk management), please seek a professional who is licensed or knowledgeable in that area."--Moxy 🍁 07:14, 23 July 2019 (UTC)[reply]
I wouldn't see a link to helpful resources as a source of liability for the WMF, even if we were seen as the publisher (which we probably would not be if the community put up a banner). It's an attempt to be helpful to people, in line with the way many websites show information about the topic of suicide, and recommended by specialists who work on the issue. Imo, it's a positive thing if Wikipedia takes into account situations where certain information can harm some readers and offers other information that can help mitigate that harm. And I think suicide is a sensitive and unique enough topic that it would be a good place for a special exception to the general rules discouraging banners. -Jrogers (WMF) (talk) 07:44, 23 July 2019 (UTC)[reply]
  • Opppose Seriously, how many times have we gone over that we haveno disclaimers in articles? I understand that it may help people, but that's not what Wikipedia is designed to do. -- Rockstonetalk to me! 07:29, 23 July 2019 (UTC) Everyone here has convinced me.... I weakly Support a proposal like the one described in the section below referring to suicide prevention. It retains NPOV while still giving users access to resources which may help them. It also is possible that someone who typed in "suicide" is looking for "suicide prevention", so I think it's okay. -- Rockstonetalk to me! 01:20, 31 July 2019 (UTC)[reply]
    NODISCLAIMERS is a guideline rather than a policy, which means we can use our discretion. If it may help people, perhaps we should do it? Richard Nevell (talk) 07:39, 23 July 2019 (UTC)[reply]
    I mean, there are plenty of things which could help people that we don't do. Trigger warnings in articles involving traumatic things could help people, but we don't do that. What about a rape crisis hatnote for the article on rape? Or a hatnote for the article on homicide telling people not to do it? Censoring images could help people too, after all, an image of suicide could cause people to become more suicidal, and a disturbing image could haunt someone for a lifetime. Where does it end? Rockstonetalk to me! 07:55, 23 July 2019 (UTC)[reply]
    Comment If we DID have some type of disclaimer, I'd be OK with it being something like:
But that's about the extent that I think it should go. -- Rockstonetalk to me! 17:48, 23 July 2019 (UTC)[reply]
I'm not concerned by slipper slope arguments, and rarely am, for the reasons at slippery slope. Notably, this quote from an intro logic text book: The strength of the argument depends on two factors. The first is the strength of each link in the causal chain; the argument cannot be stronger than its weakest link. The second is the number of links; the more links there are, the more likely it is that other factors could alter the consequences. It's not particularly clear that if we add a hatnote we will be required or even strongly compelled to add similar notes to similar articles; there's not a strong link between each event in the slippery slope. The number of decisions required to reach the bottom of our slope is conceptually very large, we won't devolve into hatnoting The Sorrows of Young Werther with links to mental health resources in one or two steps, and likely never will, because we have WP:COMMONSENSE that people in crisis are most likely going to read suicide and suicide methods not some random other page. Such hatnotes are unlikely to be useful on other topics like mental illness in general or even rape because while similarly weighty, they are not nearly as time sensitive nor do we have particularly well developed encyclopedic content to which we can redirect a reader (we don't have a List of doctors in your area and services for survivors of sexual assault are incredibly variable between jurisdictions). Wug·a·po·des21:05, 23 July 2019 (UTC)[reply]
You say that none of the five standard disclaimers cover the disclaimer being proposed here, that's not true. It literally says in the risk disclaimer that Many articles contain frank discussion of controversial topics of which suicide is a controversial topic and falls under that category. Wikipedia is not meant to help people, Wikipedia is meant to be an encyclopedia. Whether or not that encyclopedia helps people is completely irrelevant. It is a collection of encyclopedic content, while this proposed hatnote is not encyclopedic at all. You will not see other encyclopedias linking to such resources or providing a disclaimer. I strongly oppose adding a disclaimer to the topic of this article, especially as a hatnote. In all honesty, if we have to add any type of disclaimer, it would be better as a banner which does not impede the encyclopedic content of the page, and one which could be minimized.
The slippery slope argument is not a fallacy, because it is not a stretch to imagine that other controversial topics may require such a hatnote. For example, the article on mass shootings is one such article that I almost certainly forsee having a hatnote if this proposal comes to pass, because this too is a form of suicide. -- Rockstonetalk to me! 21:35, 23 July 2019 (UTC)[reply]
I sincerely doubt that suicide was meant to fall under "frank discussions of controversial topics" because if asked to name 10 "controversial topics", few, if anyone, would have suicide on that list. We've had more controversy over infobox colors. Further, the hatnote isn't warning people about content, it's directing them to other pages they may in fact be looking for. Wikipedia is not meant to help people, Wikipedia is meant to be an encyclopedia this is what I mean by absurd; what do you think is the purpose of an encyclopedia? If a reader comes here looking for information and they don't find it, is that a success to you because we didn't help them find the information they were looking for? We consider what is helpful for readers constantly because that's how any good publication makes editorial decisions. We care about helping our readers find information, so linking them to encyclopedic articles we already have is not some wildly unencyclopedic thing to do.
the article on mass shootings is one such article that I almost certainly forsee having a hatnote if this proposal comes to pass This is also absurd. "Because it is a form of suicide" is not a sufficiently strong link for the reasons I gave above. Lots of things are forms of suicide; fire is a form of suicide but I doubt we'll put a warning there because there is no sensible reason why someone looking for List of suicide crisis lines would wind up at fire (or mass shootings), but there is a completely obvious reason why someone looking for that article would wind up at suicide or suicide methods. If you legitimately think the next logical step is putting hatnotes on things simply because [it] too is a form of suicide, then I really can't help you because that sounds patently absurd. Wug·a·po·des22:34, 23 July 2019 (UTC)[reply]
It is in fact true that our common goal is building an encyclopedia, not helping people. If someone thinks building a free comprehensive neutral encyclopedia would help people, and they like helping people and therefore want to participate, they're welcome here. If someone thinks that improving such an encyclopedia will harm people, and wants to harm people and so wants to participate in a helpful manner, they're welcome too. If someone wants to help people and thinks helping people will be accomplished by wrecking the encyclopedia, they're not welcome to do that. And of course, some people are just here to have fun, or improve the world (according to their worldview), or think of information or freedom as an end-goal, and they're also welcome to helpfully contribute. I realize this isn't super motivational to those of us who are here to help people, but what can you do... --Yair rand (talk) 22:57, 23 July 2019 (UTC)[reply]
There is a substantial difference between what my purpose as an editor is (building an encyclopedia) and what the purpose of an encyclopedia is (providing readers with information). Compare the difference between WP:HERE and WP:PURPOSE, the latter of which explicitly says Wikipedia's purpose is to benefit readers. Wug·a·po·des23:16, 23 July 2019 (UTC)[reply]
  • If a reader comes here looking for information and they don't find it, is that a success to you because we didn't help them find the information they were looking for?: It entirely depends on what information the reader is looking to find, for example if a reader is looking for information on how to do something, then they should not expect to find it here, similarly if a reader is looking for advice, then they're in the wrong place. In both cases, failure to find this information is a success to me, because advice and how to guides are both not the purpose of this project. Wikipedia is not a collection of information, even if cited, it is only a collection of information which is of an encyclopedic nature. Finding any particular set of information is not the purpose of Wikipedia. So no, not all information that a reader might be seeking should be found here and in many cases failure to find it is a success. To the extent that we do care about helping our readers find information, we use the "see also" section of articles. I would not be opposed (in fact, I'd strongly support) references to suicide hotlines and resources in the "see also" section of the page (which we don't have right now). -- Rockstonetalk to me! 23:25, 23 July 2019 (UTC)[reply]
I am glad that you seem to be entertaining the idea that the purpose of an encyclopedia is to benefit readers. You're right that the purpose of an encyclopedia is not to contain everything, but we do help find them find encyclopedic information (because we are an encyclopedia after all). Moving on, we in fact, do have encyclopedic coverage of these topics, like List of suicide crisis lines which I have linked above many times, and we do place navigational aids, called WP:HATNOTES, at the top of pages: Hatnotes are short notes placed at the very top of an article or a section, like a hat is placed on the very top of a head....Their purpose is to help readers locate a different article if the one they are at is not the one they're looking for. Wug·a·po·des23:41, 23 July 2019 (UTC)[reply]
I am aware of the purpose of hatnotes, however they are for things which reasonably could require disambiguation. Very few people looking for list of suicide crisis lines will end up in suicide instead, and very few people looking for suicide will not see a disclaimer before getting there. All the major search engines provide one. Someone who types suicide into Wikipedia is wanting an article on suicide, not information about crisis hotlines. It's not helpful. -- Rockstonetalk to me! 01:54, 24 July 2019 (UTC)[reply]
There are plenty of links from the suicide article to suicide crisis lines article. A hatnote is undue weight for something that is of unclear benefit. I could support an "ignore all rules" if there was evidence of benefit. Doc James (talk · contribs · email) 08:57, 29 July 2019 (UTC)[reply]
The World Health Organization guidance for media professionals reporting on suicide recommends that information regarding crisis lines be included in media reports. While I appreciate you're much more able to evaluate primary sources than I am, the best evidence I have is that the professionals who compiled the World Health Organization's guidance believe it is helpful enough to recommend that journalists always include them in reports. As for whether it is undue or an unlikely alternative target, I weight the costs and benefits differently. Wug·a·po·des07:40, 30 July 2019 (UTC)[reply]
Was not a primary source I was quoting but a review of the topic in question published by the Lancet. Doc James (talk · contribs · email) 21:17, 30 July 2019 (UTC)[reply]

The WHO document says "Information about support resources should be provided at the end of all stories about suicide. The specific resources should include suicide prevention centres, crisis helplines, other health and welfare professionals..."

A few things, our article on suicide is not a "story" about an individual who committed suicide. We do already link to Crisis hotlines 4 times in that article which provides a list of numbers. [User:Wugapodes]] was that the passage you were referring too? Doc James (talk · contribs · email) 21:23, 30 July 2019 (UTC)[reply]

  • Oppose per Doc James. Flyer22 Reborn (talk) 15:58, 24 July 2019 (UTC)[reply]
  • Oppose per Doc J. --Izno (talk) 23:03, 27 July 2019 (UTC)[reply]
  • Support I support but I also have some requests. We in the Wikimedia community have values and rules. We do not make exceptions lightly. We do have a process for exceptions, and it typically involves making a case and sorting some documentation. This issue of a suicide notice is not just an English Wikipedia issue, but an issue for all languages of Wikipedias and for our platform as a model for behavior in online spaces in general. This proposal is fairly disorganized to this point. Considering the seriousness of the issue and that putting a notice on a page is an exceptional and unusual thing to do which will have major and unpredictable consequences, I advocate to raise this issue from a casual discussion to a moderately organized discussion. I do not think this is so contentious that we need to invest the resources to make the best case and documentation that we can, but I do think that the issue merits some moderate amount of documentation. To implement this with the documentation we have now seems likely to cause various problems and we should mitigate that with some advance planning in the Wikimedia community. Blue Rasberry (talk) 14:35, 29 July 2019 (UTC)[reply]
    The English Wikipedia does not make decisions for other Wikipedias, and the different projects don't make content decisions like this collectively. --Yair rand (talk) 19:00, 29 July 2019 (UTC)[reply]
    @Bluerasberry: this is primarily an editorial decision, so each project will have their own discretion on this, it would take an office action if they wanted to force disclaimers or other banners on articles based on their content - something I'd expect large projects (like here) to have major resistance too. — xaosflux Talk 22:17, 29 July 2019 (UTC)[reply]
    English Wikipedia makes decisions with authority over government process about what information citizens can and cannot access. I know we have been doing this for about 20 years but our having this media influence is still a new and unusual power to wield. With English Wikipedia outranking most governments it also has overbearing influence on what other language Wikipedias do, especially in matters of global citizenship like this one. I recognize the idealism of having a community run process for every language Wikipedia community, and I do respect any organized attempts by other languages and Wikimedia projects to assert their own rules. When communities do not organize then all kinds of global defaults come to them. For various reasons this discussion here and now seems unusual to me for being more likely than most other discussions here to be a pilot for global change in Wikimedia projects and to present to every other online platform. If the wiki community decides that notices like this are useful then we have respect and standing to tell everyone else in the world that this is the norm. I could be mistaken, and what I am describing may not be the stakes, but my intuition is that this is a situation where English Wikipedia has power to issue a global cultural mandate. Blue Rasberry (talk) 13:58, 30 July 2019 (UTC)[reply]
  • Support If we can save one life with a brief blurb at the top, it's worth it. I'm personally familiar with people who have used the hotlines, and they have been beneficial. Really don't understand the opposition here - if you're not suicidal, it doesn't impact you, and if you are, there's a chance it could help. SportingFlyer T·C 22:06, 29 July 2019 (UTC)[reply]
  • It does impact people who are not suicidal, as it suddenly makes Wikipedia appear no longer neutral. There are plenty of things that "could help" that we don't do. Like I said earlier, having a link to rape crisis hotlines on the rape article "could help" as well, but we don't do that. For what it is worth, I agree with User:Bluerasberry that we should attempt to get wider community input, particularly because adding such a disclaimer will be disruptive. -- Rockstonetalk to me! 21:04, 30 July 2019 (UTC)[reply]
My other arguments from the other RFC Whilst we're here to make an encyclopaedia, and the link to suicide crisis lines is arguably unencyclopedic from this article, this is definitely an ethically challenging area. I would strongly support for this article inclusion, especially as Wikipedia is not censored and the suicide methods article may have obvious unintended consequences. Also I note that WP:IAR is improving or maintaining Wikipedia with no mention of Wikipedia being an encyclopaedia. Inclusion clearly violates even WP:HERE and everything else, but in this page I think all are overridden. and also re: evidence I think its one of those areas of medicine that will never really have good evidence. If evidence is shown in one study, worldwide generalisability is poor. Theres little evidence in risk assessment for suicide as well. It is common practice to link to crisis lines, despite the lack of evidence, I think we should do the same. --[E.3][chat2][me]
  • Support per Jrogers. Jake Wartenberg (talk) 03:44, 11 August 2019 (UTC)[reply]
  • Oppose' this particular proposal. There is no point in linking to any particular site, especially one of doubtful efficacy. the argument "It is the only thing that can possibly work" is in defiance of WP:V. and WP:OR and WP:MEDRS. We shouldn't be sending people o places where here is no evidence of effectiveness. "This is a problem. Something must be done. This claims to be some thing. We must do it. The discussions at the other location, mentioned below, make much more sense. DGG ( talk ) 06:37, 11 August 2019 (UTC)[reply]
  • Support We use disclaimers on talk pages, what's the harm in including one right at the forefront of the main article? Especially when it isn't there to clutter but potentially could help someone. The C of E God Save the Queen! (talk) 15:02, 13 August 2019 (UTC)[reply]
  1. Support It's a sensible action and I think the case can be reasonably made that it 'makes the encyclopedia better'. Also support the more conservative compromise wording proposal below that is more within wikipedia norms. T.Shafee(Evo&Evo)talk 03:51, 16 August 2019 (UTC)[reply]

Alternative proposal

Link to the general topic of suicide prevention rather than one specifically and poorly supported measure. Something like

Doc James (talk · contribs · email) 21:02, 31 July 2019 (UTC)[reply]

Per User:Banana Republic I could support something along the lines of If you're considering suicide, please visit suicide prevention. This would prevent us from giving undue weight to crises hotlines when other methods have better support. That article will need improvement but happy to work on that. Doc James (talk · contribs · email) 21:35, 30 July 2019 (UTC)[reply]

I didn't suggest that. I quoted andritolion, who did suggest that. I suggested "For suicide prevention, see ...." whatever the appropriate article would be. I wanted to de-personalize the hatnote, to make it more neutral. In general, the word "you" should not appear in the article space. Banana Republic (talk) 21:51, 30 July 2019 (UTC)[reply]
How about something like:
?-- Rockstonetalk to me! 21:54, 30 July 2019 (UTC)[reply]
An even better idea than what I proposed. Banana Republic (talk) 22:35, 30 July 2019 (UTC)[reply]
Well, I would support something like that. This would retain NPOV while giving users who are suicidal the opportunity to read an article that may help them without being preachy or breaking encyclopedic standards. I've changed my Oppose to a weak Support above.-- Rockstonetalk to me! 01:23, 31 July 2019 (UTC)[reply]
Sure would support User:Rockstone35 proposal. Have adjusted mine to reflect it. Doc James (talk · contribs · email) 21:02, 31 July 2019 (UTC)[reply]

Several studies have documented specific caller benefits during and after crisis line contact. These include:

  1. Changes in the callers’ crisis state or suicidality during the call;
  2. Resourcing for improved crisis management such as the development of action
  3. plans and the provision of referrals and
  4. Flow-on benefits after the call, as assessed in caller follow-up.

Overall, these studies provide promising, if preliminary, evidence that the participating crisis lines did deliver outcomes consistent with their goals of providing crisis support and reducing immediate risk of suicide. They also demonstrate how research can identify areas that need addressing to increase helper competencies and enable service improvement.

Furthermore, if you extend the paucity of evidence argument I have not heard of any evidence to link a suicidal person to how society manages suicidal intervention and prevention (linking suicidal people to help appears to be to be the main thought behind the WP:IAR in this proposal). If that suicidal person doesn't have access to those preventative measures, such as being in a remote area or low income nation, it could in my limited opinion could also have unintended consequences as well and I would strongly suggest a suicidal prevention expert's input here. I certainly prefer weak evidence and expert opinion/common practice (ie. to crisis lines) to what might have no evidence. Also if this second hatnote has consensus suicide prevention and suicide intervention needs a far more global viewpoint / rewrite. --[E.3][chat2][me] 19:26, 12 August 2019 (UTC)[reply]

  1. Support as reasonable compromise within existing norms. T.Shafee(Evo&Evo)talk 03:42, 16 August 2019 (UTC)[reply]

I have started an RFC at: Talk:Suicide methods#RFC: Hatnote at top. I have not been following this one as much, but users here may be interested in it. –MJLTalk 19:00, 2 August 2019 (UTC)[reply]

Add a warning for broken/orphaned reference names before saving edit

I think there should be a warning at the top of a preview of an edit if there is a broken reference name. I have been spending a lot of time going through the huge backlog of pages with broken reference names, and have found that many of them occur when someone copy/pastes text from one article to another and forgets to grab the parent reference. Also, there are some cases where someone mistakenly puts the name of a book or publication in the <ref name> parameter. I think most people don't scroll down to the bottom of the page to double-check the reference section if they preview their edit, and this could solve the problem. It would only take another minute or two for the editor to find the parent reference in this case, whereas when someone else has to hunt down the reference a year later, it can take a long time. I wasn't sure if this was something I should post about here or on Phabricator, so let me know if there's a better way to proceed. Secundus Zephyrus (talk) 19:29, 24 July 2019 (UTC)[reply]

A warning would be a very good idea. This has been a problem for years and there has been some progress. AnomieBOT's OrphanReferenceFixer manages to fix many of these errors or we would be inundated. See the log here. For a while there was another bot, ReferenceBot, which would leave messages on editors' talk pages about errors AnomieBOT couldn't fix. However it has not been running since Feb 2017. StarryGrandma (talk) 04:15, 25 July 2019 (UTC)[reply]
+1 Headbomb {t · c · p · b} 04:32, 25 July 2019 (UTC)[reply]
This would be a great improvement. Auto-detection of failure to include the pesky "/" at the end of <ref name> where needed would also help. RobDuch (talk·contribs) 07:01, 25 July 2019 (UTC)[reply]
Agreed. This is especially important when editing a section (not the whole page where all refs are visible) and forgetting to check for other sections where refs may become orphaned. ComplexRational (talk) 19:42, 29 July 2019 (UTC)[reply]
ComplexRational, I hadn't even thought of that possibility, that's a great point. --Secundus Zephyrus (talk) 20:29, 29 July 2019 (UTC)[reply]
All great ideas above. Does someone with technical background know how these warnings above the preview window are generated in Lua? --Hecato (talk) 10:23, 25 July 2019 (UTC)[reply]
Nyttend, that's a good point. I wonder if it can be worded in a less-scary way that might strike a balance between the newbies and the experienced editors? The reason I ask is because I've come across pages with broken references going back years, and I think if an experienced editor got a notification of an old error, they might be more likely to try to fix it if they have the time. --Secundus Zephyrus (talk) 18:55, 11 August 2019 (UTC)[reply]

Disclose the editors who are enrolled over Wikipedia Library

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.


A few months back, I sought for a L'Harmattan article over en-wiki RX. Now, L'Harmattan is a TWL partner whose subscriptions gets processed from fr.wiki. I (till date) have not come across any need to access any of their resources and thus, did not intend to consume one account for accessing a single resource (it seemed unethical to me) and per a conversation with Nikkimaria, sought for folks over fr.wiki, who have access to it. But, I failed to reach a single user, who had a subscription to Harmattan. One had his user-box, despite expiration of the subscription whilst one did not choose to reply. Another, (who was pinged by the one with expired-access), did not choose to reply either. Per subscription-counts, it was clear that ample people had access to it, but I had no scope of knowing whom to contact other than those, who self-disclosed. RX did not help me either and at last, Sam asked me to proceed towards consuming one account for the sole purpose of accessing about two pages, which is a highly inefficient and non-optimal way of doing things.

I (thus) propose that there be

a public list of all editors who are granted access to any resource from TWL

so that they can help out fellow editors within rational limits. All applicants (including myself) are feeding on a scarce community-resource and I am unable to see any reasons for not being radically transparent, in this regard.

FWIW, I'm not seeking for any retroactive change which might infringe on already signed legal agreements and all that. I'm arguing for the implementation of this proposal for all new requests and renewals.

Thoughts and opinions on the proposal (esp. about reasons (if any) to maintain the current privacy) are welcome:-) WBGconverse 15:58, 31 July 2019 (UTC)[reply]

Transcluded to Wikipedia talk:The Wikipedia Library. * Pppery * it has begun... 16:13, 31 July 2019 (UTC)[reply]
  • I like this idea. I think it helps with the transparency of TWL and allows more member-to-member resource sharing that doesn't have to bottleneck through the very busy TWL folks. Jessamyn (talk) 16:37, 31 July 2019 (UTC)[reply]
    • I'm not 100% sure about this. Shouldn't it be an opt-in list like WP:RX? On the RX, me and others have listed what resources they have access to, whether or not affliated by the wikipedia library. The only reason why I'm hesitant because what if some editors do not want to be on this list? What if they prefer not to be bombarded with emails asking for help for a resource they have access to? If it's opt-in, sure. Then it'd be a list of who has access to what and who don't mind helping others out :) --MrLinkinPark333 (talk) 18:04, 31 July 2019 (UTC)[reply]
      When you are accessing a community-resource, you shall be prepared for receiving such requests of assistance. Whether to process them is obviously at your discretion but as far as I have seen, most of the people are nice and collaborative enough to help out others:-) I also disagree about your assessment of probable bombardment, in light of the volumes of request at RX (which I've been patrolling for long). WBGconverse 18:26, 31 July 2019 (UTC)[reply]
      Well, this is before this idea comes up. I'm just listing a possibility of what could happen. Whether it does or not, we'll see. --MrLinkinPark333 (talk) 19:14, 31 July 2019 (UTC)[reply]
  • Hmm, the issue with that is that it's a retroactive change in the written out expectations. So I'm happy to be on such a list (I hadn't realised there was also the shared resources list, so I've added myself there). Whether it's fair to require that for all, despite being community licenses...I'm not sure. I'd certainly be in favour for such for any future granted accesses. I have a 2nd concern - people are going to always go for those on the top or bottom of any such list, which means certain editors are going to face way more requests. Is there a way to randomly shuffle them around periodically? Nosebagbear (talk) 18:33, 31 July 2019 (UTC)[reply]
    Regarding Nosebagbear's second concern, randomizing the list might help; Mr. Stradivarius' Module:Random as employed on this page for example could be used for this. Jo-Jo Eumerus (talk, contributions) 18:44, 31 July 2019 (UTC)[reply]
    Nosebagbear, I'm not seeking a retroactive change. I'm arguing for the implementation of this for all new requests and renewals. Probably worth clarifying in the main post? WBGconverse 18:56, 31 July 2019 (UTC)[reply]
    @Winged Blades of Godric and Jo-Jo Eumerus: - ah, that looks fine then, and a great potential solution Jo-Jo. I'd certainly support such a change unless someone comes up with another major issue. Probably worth clarifying in the proposal, though i imagine most current holders would be happy enough to sign-up as well. Nosebagbear (talk) 19:07, 31 July 2019 (UTC)[reply]
    :-) Agree that current access-holders can jump onto the list per their individual discretion. WBGconverse 19:10, 31 July 2019 (UTC)[reply]
  • One additional question, perhaps it sounds a little silly: When one enrolls in TWL, is it OK under their contractual agreements to access sources on someone else's behalf? Jo-Jo Eumerus (talk, contributions) 18:38, 31 July 2019 (UTC)[reply]
    Jo-Jo Eumerus, the relevant portion of the ToS (of WMF-Library-platform) states:-

    Please note that in order to access an individual publisher’s resources, you agree to that publisher’s terms of use and privacy policy. Additionally, your access to publisher resources through the Wikipedia Library is accompanied by the following terms.

    Your access allows you to search, view, retrieve and display partner content (that is, content that requires an account to access) from publishers; to electronically save partner content; and to print out single copies of partner content.

    You must agree not to share your usernames and passwords for access to publisher resources with others.

    Your access to publisher resources does not allow you to mass scrape or mass download restricted content from publishers; to systematically make printed or electronic copies of multiple extracts of restricted content available for any purpose; to data mine metadata without permission, in order to use metadata for auto-created stub articles, for example; or to use the access you receive through the Wikipedia Library for profit by selling access to your account or resources to which you have through it.

    I have checked the ToU of ample publishers (who are in the platform) and none disallows accessing sources on someone's behalf. They mostly regurgitate the above stuff in slightly different forms. WBGconverse 19:01, 31 July 2019 (UTC)[reply]
  • Support. I actually never really looked into WP:TWL before WBG posted on my talk page to inquire about my thoughts. I just applied to get access to JSTORE now. This seems a bit different in nature than WP:RX because it's a paid service to Wikipedians. I don't think it's unreasonable to ask them to potentially share the economic benefits with users. If it is deemed neccesary, the list can be opt-in, but do remember that these individuals (like potentially me in the future) aren't paying for these benefits rather than the library is on their behalf to create a better encyclopedia. We're a collaborative project, and I think it all the better for TWL to simply reflect that in some way. –MJLTalk 20:43, 31 July 2019 (UTC)[reply]
  • I thought this was already publicly made known - https://wikipedialibrary.wmflabs.org/activity/ - the applicants and the successful ones appear to be marked on the TWL page - so it should only be a matter of putting that data together but keeping track of expiry and maintaining the list is probably not a fun job. Maybe a software feature request for the Library Card Platform website would work. Shyamal (talk) 07:21, 1 August 2019 (UTC)[reply]
    Shyamal, that is an opt-in list and only tracks the last 50 events over the platform, pending which they are (probably) removed.
    Account coordinators regularly email the users whose accounts are nearing expiry to inquire about whether they still need the resource, in which case they are renewed or else, the account locked and allotted to someone else. So, they are already tracking expiry and relevant stuff. WBGconverse 07:30, 1 August 2019 (UTC)[reply]
  • The plans for a Wikipedia_Library_Bundle would seem to address the inefficiency of consuming an account for a brief specific need, though I don't know which or how many providers are ready to sign up for that? AllyD (talk) 08:34, 1 August 2019 (UTC)[reply]
    AllyD, those are plans (that have been already in the pipeline for over 2 years) and per safe estimates, will take another few years to be implemented. Whilst that would eventually address some of the root problems, do you have any objection to the current proposal? WBGconverse 09:03, 1 August 2019 (UTC)[reply]
  • Something I saw earlier this week indicates to me that some degree of broad rather than user account-specific access rights may be introduced soon, but I know no more than that. To the extent that access remains account-specific, the pre-Library Platform request method did involve public on-wiki record (e.g. [5]]) which, though not capturing the final steps of publisher registration and activation, was implicitly available to help another user seeking someone who could obtain a particular resource. I wouldn't think it too onerous a build to extend the Library Platform with a query on publisher to select contact details of one random user (to spread the load); though, trends in privacy legislation may mean this would have to be opt-in, despite it being a community resource which previously had on-wiki request lists. AllyD (talk) 08:51, 2 August 2019 (UTC)[reply]
    AllyD, I saw the phab-ticket but given how TWL has technically matured over the years, am not optimistic at all. WBGconverse 16:01, 2 August 2019 (UTC)[reply]
  • Hi all, I work on The Wikipedia Library program at the WMF. I just wanted to clarify the situation from our end, explain why this isn’t a feature we implemented, and provide an update on our plans.
As a first point, displaying a list of users approved for access via the platform is technically feasible to implement on the Library Card platform, in any number of different ways: randomly ordered, opt-in, opt-out, you name it. There are a few reasons we haven’t shared such a list for each publisher in the past, however. The first is that for many publishers we simply don’t have an accurate list of users who actually have access - while we know who we’ve approved for access, account setup has historically been a multi-step process in which users might not finish setting up their accounts. We also haven’t been able to record a clear picture of how long any individual’s account lasts, some require renewing yearly, others are indefinite, others end on a set date, depending on the publisher - it’s not as straightforward as it might seem. This unclear picture of who has access meant that showing a list of users with access was difficult, so it wasn’t work we pursued.
We also prioritised privacy concerns on this tool, in the Terms of Use (approved by WMF Legal) and the NDAs signed by coordinators, and in allowing users to apply via email where necessary to preserve their privacy. Additionally, facilitating the sharing of individual resources is something I wouldn’t feel entirely comfortable with given how concerned many publishers are with sharing this access freely in the first place - importantly, we don't pay for publisher content, it's all provided by donation. The reason we have account caps for most publishers is that they’re understandably hesitant to give access to their resources out for free. Additionally, the specific terms of use for some publishers do place restrictions on sharing of content. Finally, due to their local context, some users may not be comfortable receiving requests for full-text content - see the final bullet under ‘Copyright tips’ at WP:RX.
I appreciate, though, that a limited number of accounts per-publisher introduces issues when we’ve either filled the list or you only want one or two resources. I’m happy to say that the more comprehensive solution to this problem (as alluded to above by WBG and AllyD) is finally right around the corner! While the development on authentication-based access and the Library Bundle was unfortunately delayed for quite some time due to legal discussions, we’re now moving ahead with technical implementation and are currently scheduled to be up and running before the end of the year. Under this system more than half of our content will be immediately accessible to everyone who meets TWL’s activity criteria (500 edits, 6+ months editing, 10+ edits in the past month) without manual approval or a fixed cap on the number of accounts. This, along with a more streamlined proxy-based process for many other publishers, should mean that access is more plentiful and you should rarely feel worried about only needing a small number of resources.
In the meantime, as Xaosflux points out above, we do have userboxes/categories for most publishers which users can place on their user page to add them to the relevant tracking category and opt into marking themselves as being available for queries. There’s also WP:RX if you’re requesting individual resources. I hope that helps, please feel free to ping me if you have any questions. Samwalton9 (WMF) (talk) 18:19, 2 August 2019 (UTC)[reply]
Samwalton9 (WMF),
The first issue of multi-layered-approval is problematic, indeed. May-be necessitate that once an editor gets his/her access, he/she needs to confirm that over through email? Unless he/she confirms, we send periodic (monthly/bimonthly?) reminders to the users? Obviously, an user can play around that because we have to take his/her words at face value but that would be peak-ABF-esque.
Now, an account lasts for a specific time, which's unique to a part. resource across all applicants. The coordinators often knows this span, too and send mails, a month or two before our access is to end, inquiring about whether we still need access or our account can be locked and re-allotted to someone else. Do you enter into agreements w/o specifying all these details? How does the process of enrolling a partner plays our internally?
Additionally, the specific terms of use for some publishers do place restrictions on sharing of content. - Evidence, please.
Some users may not be comfortable receiving requests for full-text content - see the final bullet under ‘Copyright tips’ at WP:RX - One can take himself out of the list and, as I said, nobody can compel anyone to provide resources.
We also prioritised privacy concerns is not a reasoning tool - I'm asking for the reasons behind the prioritization, over here. WBGconverse 19:37, 2 August 2019 (UTC)[reply]
  • Oppose The Wikipedia Library (TWL) doesn't know whether an editor has access to a resource through TWL. TWL knows when they offer an editor access, but, depending on the partner, may not know if the editor followed through and activated an account with the partner. TWL doesn't know if the editor has retained any special url required to access the partner, or remembers or can recover their password. TWL doesn't know if the access has been terminated. In several cases TWL has contacted me to advise me that my access will lapse if I don't respond, when in fact the partner expired my access years earlier.
TWL access is widely available for the asking. Most subscription expire after a year (Miramar after just a few days), after which I beleive the subcriptions return to the pool. The 15% or so of partners who are routinely waitlisted (AAAS, Cambridge, Science Direct, Sage, ...) are mostly readily available through reasearch university libraries, and thus through Resource Request (RX). If an editor is so public-spirited that they hesitate to consume a plentiful resource by signing up for a subscription, then they should sign up for the account anyway, self-disclose that they have it, and offer at RX to use it on behalf of anyone else who needs it, rather than imposing that condition on all subscribers. If it ain't broke, don't fix it.
I volunteer at RX, where I can choose what requests to read and respond to. I would not sign up for TWL resources if WP:CREEP caused TWL to place me on a public list of people to contact about that resource. I have no interest in searching databases for someone who doesn't qualify for access through TWL, or is too lazy to apply for access through TWL, or is on a fishing expedition for something that I don't believe would improve the encyclopedia. Using a community resource to improve Wikipedia should continue being sufficient reason to grant access to that resource, without the editor having to be on the receiving end of unwanted requests for help. Transparency should be balanced against an editor's right to privacy. --Worldbruce (talk) 19:06, 2 August 2019 (UTC)[reply]
  • Oppose - Basically Worldbruce and Samwalton9 have covered everything I would have said. There might be room to improve the layout (simplification, clarification, etc.) of the TWL application pages especially to increase crosslinks between WP:TWL and WP:RX to advertise WP:RX for those in a situation like Winged Blades of Godric (WBG) where research assistance is required but ethical concerns prevent the researcher from signing up with TWL, but in my experience the coordinators are very good at directing requests for scarce sources to RX where assistance is generally available. The privacy issues raised above are likely to be common with some library-oriented folks (e.g. at TWL) for historical reasons. -Thibbs (talk) 14:25, 3 August 2019 (UTC) (Disclosure: I am a former TWL coordinator. -Thibbs (talk) 14:25, 3 August 2019 (UTC))[reply]
    Thibbs, I fucking know where the RX is. Have provided ample content to users, from there and received some. In the described case, nobody at RX managed to access the resource. I contacted Nikkimaria (the coordinator for the resource) who merely pointed me to fr.wiki user-cat and said that she can't help more. Also, the linked case is too hyperbolic to be relevant. WBGconverse 16:46, 3 August 2019 (UTC)[reply]
    OK, calm down. I understood your proposal of a public list to be a general proposal intended to help all editors here at Wikipedia including those who don't know where RX is. I understand that you have specific needs for specific sources in the case you described, but as your proposal was phrased as a general request I didn't think you were asking specifically for yourself. In your specific case I would recommend the following: (1) sign up for an account despite the ethical concerns, (2) carry out whatever research you need, and then (3) restore the ethical neutral point by alerting the coordinator that you wish to relinquish control over your account. Is it inefficient, sub-optimal, and generally clunky? Sure. But at least it protects the privacy of the other users who might wish to avoid unpleasant demands from others. -Thibbs (talk) 17:34, 3 August 2019 (UTC)[reply]
    My core point is that if you are concerned over privacy to such an extent (the proposal allows for optional opt-outs but with a public entry), you have no business to claiming community resources.
    As far as I have seen, once people access RX, they know about TWL and vice-versa.
    I have since got that resource (via guest inst. access and using stuff, completely outside of wikimedia) but that's not much relevant and it intends to serve as an example case. WBGconverse 18:03, 3 August 2019 (UTC)[reply]
    Worst case scenario: the accounts expire within a certain time period and the account gets cycled back into the community. I understand your perspective, but I don't think it's accurate to characterize the resources as a non-community resource. -Thibbs (talk) 19:52, 3 August 2019 (UTC)[reply]
  • Oppose: I'm afraid I have to oppose this resolution. As someone who uses TWL as a resource, I'm not comfortable being put on a presumably-public list for dissemination, simply because I use TWL. Moreover, it's a rather simple process to apply; it just takes some patience for one's submission to be processed. Thibbs, Worldbruce, and Samwalton9 more or less encapsulate my other thoughts on this matter. Javert2113 (Siarad.|¤) 15:04, 3 August 2019 (UTC)[reply]
    Not much sure as to why you have the access, either. WBGconverse 16:46, 3 August 2019 (UTC)[reply]
  • Oppose - I don't think WBG's initial concern is unreasonable, but find the arguments by Samwalton, etc. persuasive. I also don't actually see that there's a problem that needs fixing at this point. There is no case here where someone wants access to something and can't have it. WBG can have access to the resource in question (at least as far as I understand), but would prefer not to take an account for such a limited purpose. I'd be more sympathetic if we had a situation where someone wanted access, all the accounts were taken, and the people who have opted into using the user category were unresponsive. Especially if someone is themselves active at RX, I see no problem with them requesting whatever accounts they want. I wouldn't be opposed to making the user category opt-out rather than opt-in, though, since I suspect the majority of people who have access wouldn't mind being listed. — Rhododendrites talk \\ 18:15, 3 August 2019 (UTC)[reply]
  • Oppose. Agreed that it doesn't make much sense to require you to consume an account only to access two pages, but unless TWL indicates having the bandwidth to implement the extra reporting steps, I view this as scope creep or, most charitably, a nice-to-have. Last I recall, TWL was in need of more volunteers, not more to put on their plates. Additionally, it's really exciting to hear about recent progress towards proxy-based access (haste the day!) which would obviate the need for manual transparency. If the dev time is zero sum, that definitely seems like the area with greatest impact. czar 19:16, 3 August 2019 (UTC)[reply]
  • I don't have an opinion either way: but if you are going to do this, just make sure you have an 'accurate' list of currently enrolled people, for example I no longer have any access from TWL provided resources. — regards, Revi 07:19, 4 August 2019 (UTC)[reply]
  • The TWL could theoretically grant shorter-term access like a month-long access if scarcity of the resource really became the problem. Most editors applied for the access because they want to write an article which may have relevant material in respective database/library, that does not mean they're suddenly ready to became a librarian. The proxy model used by most libraries could also work, just that I don't think the partners would agree to that. SFPL worked out a license model with NYTimes that grant three day access to their patrons and can reapply after, which could also be of reference to what TWL might work in the future. viz 01:55, 6 August 2019 (UTC)[reply]
  • As a WPL account coordinator, I've had two or three users apply for accounts but express discontent over having to release any of their personal details to WPL volunteers. While a list like this wouldn't necessarily expose such details, a list like this would likely discourage such users from signing up. This may or may not be a reason to oppose this proposal, but I wanted to add my evidence that privacy concerns are important to people with WPL access. I personally do not wish to make a !vote. Smmurphy(Talk) 14:10, 8 August 2019 (UTC)[reply]
  • I don't think anyone should be required to disclosed anything, but it would be good to have voluntary disclosure of those things. Headbomb {t · c · p · b} 14:16, 8 August 2019 (UTC)[reply]
  • Oppose - I agree with User:Headbomb and others above. Users with access should be encouraged to disclose, but it should not be enforced. --Hecato (talk) 14:45, 8 August 2019 (UTC)[reply]
  • I'd be opposed to requiring disclosure. For some users in repressive countries, strictly regulated social groups, etc, just accessing certain information sources may be illegal, dangerous, or embarrassing. On the other hand, providing an easy way for users to find people with access to these databases seems like a good thing and promotes the goals of wikipedia, so I'm all for it, on a voluntary basis. I'd even make it easy to opt-in, like a "please list me in the directory" checkbox when you sign up (but which defaults to not). I've got JSTOR, Newspapers.com, and Rock's Backpages access. The later, of course, being a highly subversive organization. -- RoySmith (talk) 14:47, 8 August 2019 (UTC)[reply]
  • Oppose per several of the previous oppose votes. While the TWL partner accounts are a community resource, my volunteer time is not: whether I choose to make myself available to handle such requests must be, like all other contributions on these projects, entirely up to me. And, frankly, the sheer entitled attitude exhibited in some previous posts make me question whether I would want to subject myself to that hassle.
    That being said, until the mentioned Library Card Platform changes address the root problem, I think we both could and should do much to encourage more editors to volunteer to make themselves available for such requests and to make it easier to contact them with a request. My gripe above aside, I have always been happy to help anyone who asks—using both the TWL partner services I have access to, my personal library, and any physical library or other resource I can access—but I haven't been conscientious about adding the relevant user boxes or watchlisting WP:RX.
    I think we should use either mass-message or targeted email based on TWL account info to send out instructions for and encouragement to add userboxes for all resources an editor can access. The idea mentioned above about using Module:Random and a template to easily get a list of, say, five random editors with access to a given resource willing to handle requests. Maybe we could even get a bot to maintain a frequently updated list of "currently active editors with access to resource X" (ping Xaosflux) so one wouldn't have to waste time placing requests with editors who aren't currently editing, or who are on Wikibreak but haven't removed the userboxes. The Library Card Platform user interface and coordinator acceptance emails could surface instructions for adding the relevant userboxes on acceptance to a given resource, and explain why it is important to do so (the nominator's quandry isn't unique, but it's not something most people will automatically think of unless prompted).
    I also think more explicit guidance on what are permissible uses of partner resources would make more people comfortable volunteering to handle such requests. On the one hand we could clear away the nonsensical concern that partners might be pissed if you access their service on someone else's behalf (they won't be, and wouldn't have a leg to stand on if they did: this is knowledge not anything copyrightable we're talking about). But on the flip side I imagine a lot of them (but not necessarily all!) would react badly if you send someone a PDF copy of an entire journal article (just because academics at a university do that all the time does not mean we can or should get away with it). And if you can't just send someone the whole article, that means most requests will be some level of research, which is complicated and time-consuming (relative to just grabbing a PDF) and may not be in a field or area that you are familiar with. Clear and explicit guidelines on this will help steer the expectations of both requester and those trying to help, and will make borderline requests less uncomfortable for those receiving them.
    And just to note… I've never had any problem getting help accessing a resource in a TWL partner service. In my experience almost all editors on the project are happy to help in any way they can, and will bend over backwards to do so if it all possible. And that includes outright "Can you research this for me?" type requests! Wikipedia editors on the whole are straight awsome people. --Xover (talk) 09:57, 9 August 2019 (UTC)[reply]
Yes; yes you are. ——SerialNumber54129 11:01, 9 August 2019 (UTC)[reply]
Now why would you bring sexual orientation into this? Gråbergs Gråa Sång (talk) 15:09, 9 August 2019 (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.

OpenStreetMap

Map
Interactive map showing border of Michigan permanent link to the version (click to zoom)

Should countries and other territorial articles (Example?) contain "road maps" with borders outline of the areas in question with links to the Crowd sourced OpenStreetMap (WP:UGC)? These maps seem [https://foundation.wikimedia.org/wiki/Maps_Terms_of_Use endorsed by the Wikimedia foundation - however are not editable by the Wikipedia community directly to correct errors and original research problems. Secondly should we lead our readers to an external website in the lead of territorial articles WP:ELNO? --Moxy 🍁 14:00, 4 August 2019 (UTC)[reply]

Discussion

Maps

Support removal The community cant edit these third party Wiki-style maps (WP:USERGENERATED) and in many cases this would be the 4th map added to the lead of articles that in many cases dont even mention roads in the articles. Personally I think they are simply not reliable enough for Wikipedia all over ....lets quote the warning the Wikimedia foundation has posted...."we cannot represent or guarantee the truthfulness, accuracy, or reliability of any of the information in maps"....but understand in road articles it could be ok to have.--Moxy 🍁 14:00, 4 August 2019 (UTC)[reply]
  • Support removal in general, both on the grounds Moxy gives above and also on the grounds that they generally look extremely amateurish and badly designed. I don't support a blanket ban on them as I can certainly imagine cases where there's a legitimate "better than nothing" use case, but the onus should be on anyone adding these to an article to justify why the inclusion of an OSM-based map is an improvement. ‑ Iridescent 14:16, 4 August 2019 (UTC)[reply]
  • Support removal. See West_Los_Angeles, which has a map that defies the gist of the article, which says that the borders of this community are not distinct. The dot which is inserted into the map gives the wrong story. I don't see how this map can be considered a "reliable source," considering that it is simply one map-maker's opinion. BeenAroundAWhile (talk) 14:24, 4 August 2019 (UTC)[reply]
  • Strong keep: I am not a mapmaker, and having tried, I can tell you that the technicalities of creating boundaries for the interactive maps are beyond the ability of most Wikipedia editors. Being able to rely on the nearly-always-reliable OSM is remarkably beneficial. If there are instances where OSM is inaccurate, why not work with them to fix the maps, or simply generate your own correct map for use in Wikimedia projects? Regardless, having the option of using OSM is an enormous benefit that we shouldn't throw away just over a few inaccuracies. ɱ (talk) 14:35, 4 August 2019 (UTC)[reply]
From my experience our editors do very well at making boundary maps as seen by 4 maps at London.--Moxy 🍁 15:52, 4 August 2019 (UTC)[reply]
Well I edit articles on places in New York, and I don't know a single editor there/in WikiNYC (the largest chapter in the US) who knows how to create KML maps. I've resorted to using OSM data or just not including interactive maps. ɱ (talk) 16:34, 4 August 2019 (UTC)[reply]
Moxy, it seems that BeenAroundAWhile above disagrees with you, he doesn't like how users make (static) locator maps and location maps either. Nemo 14:16, 5 August 2019 (UTC)[reply]
I would agree about locator maps...but this whole RfC is about "political boundaries" and adding road maps to articles that dont mention roads. What the editors here might find a good addition is what is seen at Wiki Travel. --Moxy 🍁 15:01, 5 August 2019 (UTC)[reply]
  • Strong keep. There is a lot relevant information to be found in the map besides the highlighted border (in this particular example). One can find positions of cities, towns etc. that a given article may mention. Therefore very relevant to use the map. It looks like few users here can not bear Wikipedia linking out to another friendly free content project (OSM) which serves us high-quality free maps. These users would probably much rather link to proprietary maps (like Google maps) which is absolutely unacceptable for myself. The global quality of OSM is even mostly much better than Google Maps (you can check yourself). OSM is also used by many commercial companies (see this, this or this list) over proprietary maps because of its quality at no cost. OSM are the best global freely licensed maps in the world (this is why WMF is hosting them) - you simply can not find a better source, and that is a fact. And yes, instead of complaining about the quality why not to fix the map yourself? It is as easy as registering at OSM and using their graphical editor to edit the map.--Kozuch (talk) 14:55, 4 August 2019 (UTC)[reply]
OK a few points to cover. As per WP:Lead things in the lead should be covered by the article it's self... many maps are being added to the leads of articles that don't mention roads. If the community sees a value in the maps on political territorial articles at the very least they should be in the section if there is one about roads. As for just register and fix the map that still means the community here still has no way of debating any problems related to WP:OR of a political boundary.--Moxy 🍁 15:52, 4 August 2019 (UTC)[reply]
Maps are essential to encyclopedias, they don't need to be explained out in the body. Never were on Wikipedia, and never will be. And, yes, editing OSM is actually pretty easy. We can debate the accuracy of OSM maps here on Wikipedia, and choose whether or not to use any particular OSM map based on OR, accuracy, etc. ɱ (talk) 16:34, 4 August 2019 (UTC)[reply]
That would be great but the problem is there being added on mass with no debate. Should require a talk before mass addition of anything.--Moxy 🍁 17:30, 4 August 2019 (UTC)[reply]
  • Weak Keep (Based on map shown) More useful than an image based map (per first 2 sentences of Moxy), and can easily be edited to fix mistakes - the community can edit these maps in the same way they can edit Commons. ~~ OxonAlex  - talk 16:01, 4 August 2019 (UTC) (clarified 16:02, 4 August 2019 (UTC))[reply]
  • Keep and expand usage of template:maplink: such maps are just a natural evolution of the location maps and locator maps which have been used for over a decade in PNG or SVG format, without the hassle (and danger) of maintaining hundreds of thousands of files. Nemo 16:24, 4 August 2019 (UTC)[reply]
  • Comment I just removed one from Slovenia article since there are too many maps on the top already. I see the usability but the current style with a thick red line looks just plainly ugly to me. If these maps are to be used, they need to be improved. --Tone 17:24, 4 August 2019 (UTC)[reply]
It's very easy to adjust the color and width of the line. See Template:Maplink. ɱ (talk) 18:05, 4 August 2019 (UTC)[reply]
Then let's first fix the maps to look nice and add them afterwards. Not the other way around ;) --Tone 20:52, 4 August 2019 (UTC)[reply]
That’s not how it works... ɱ (talk) 21:03, 4 August 2019 (UTC)[reply]
  • Comment. The red line borders are often (usually?) inaccurate when zooming in. In the Michigan map, this can be seen when zooming in on Detroit, Sault Ste. Marie, or Ironwood, for example, but I've noticed it on other maps too. Station1 (talk) 17:29, 4 August 2019 (UTC)[reply]
The shapes are being over-simplified - this is a known bug (see here) which hopefully will be solved soon.--Kozuch (talk) 17:43, 4 August 2019 (UTC)[reply]
  • Keep. The WP:ELNO argument is spurious. The endorsement argument is spurious (no article content is “endorsed”). OSM is editable; what does “directly” mean? What map is “directly” editable in Wikipedia? I don’t buy these elitist arguments about “amateurish” and so on. Dumping OSM in the absence of alternatives does not serve readers. Yes, use something better when available, but don’t get rid of what’s available. Strebe (talk) 17:53, 4 August 2019 (UTC)[reply]
  • Support removal - These are beyond hideous and should never have been approved here (example),
They're currently used on highway articles too however on these maps there are no road names or landmarks ... They're just squiggly lines on a nameless map .... Get rid. –Davey2010Talk 19:13, 4 August 2019 (UTC)[reply]
"beyond hideous" - you are amusing myself. I guess you did not use the link in the map caption pointing to maritime boundary - do you know country borders exist on sea, too? The map in Italy article showed maritime borders, you can consider these to be hideous or not, but the borders are just a fact. You can like the fact or not, but Wikipedia is here to present facts not to judge them. Period.--Kozuch (talk) 20:06, 4 August 2019 (UTC)[reply]
That's great, but the red borders on those maps do not reflect fact. For example lets look at that UK one linked above by Davey2010. The Northern Ireland/Ireland border is inaccurate enough to start a war over. The town of Belleek, for example, is 90% on the wrong side of the border. For something that is contentious, us putting a stamp to these border maps is really poor. Yes borders are real. Maritime borders are real. However these maps are putting up what is quite frankly made up borders on land, ignoring the maritime ones. Just zoom in and look at the red borders and see how they do not follow the real borders to any real degree of accuracy. That's the problem people are having with these maps, not the fact they're using the Open Street Map, but the super-imposed inaccurate borders that are clearly inaccurate as you can see the real border close by them. Canterbury Tail talk 21:47, 5 August 2019 (UTC)[reply]
The inaccuracy of the red line (it is over-simplified and does not follow the border especially in areas there the border has complicated shape) is a know bug of Wikimedia Maps - see here: https://phabricator.wikimedia.org/T155919 hopefully it will be fixed soon (even though over 2 years old) --Kozuch (talk) 17:51, 6 August 2019 (UTC)[reply]
I'm confused ? .... You seem to be suggesting I have a problem with Maritime boundarys which isn't the case here .... My issue is with the maps and more specifically the giant red borders - Also everyone knows the border for the UK and it doesn't need a big childlike drawing to show it. As for "amusing myself" ...... I'll leave that unanswered. –Davey2010Talk 21:56, 5 August 2019 (UTC)[reply]
I am not sure "everyone knows the border for the UK" - consider a kid just learning about UK or geography. There is a technical bug (https://phabricator.wikimedia.org/T155919) that over-simplifies the shapes which explains the inaccuracies in the shapes. I will try to help fix that bug.--Kozuch (talk) 17:51, 6 August 2019 (UTC)[reply]
In all fairness I don't know the age demographic of those who visit but I would assume they're 12+ ?, Ah okay, Maybe if the lines were less thicker and perhaps black that might change opinions ? ... dunno but imho they are hideous in their current form. –Davey2010Talk 18:05, 7 August 2019 (UTC)[reply]
  • Support removal, for country articles, at least for now. I don't object to the idea in principle, but one serious problem with the current implementation that struck me in the examples I've seen so far is that these maps attempt to show maritime borders in the same style as land borders, implying both that (a) these maritime borders are of the same significance as the land borders and (b) shown with the same degree of exactness. They are neither. There are good reasons why professional general-purpose maps out there virtually never attempt to do this. Maritime boundaries are notoriously difficult to define, very often contentious or objectively ill-defined, and the ones I've seen shown in several samples here are either – to the extent that they ostensibly look as if they were exactly drawn – very questionable WP:OR, or plain false, or in some cases taking sides in what are in fact internationally disputed situations. I'd reconsider if we could get a version of these maps that filters out maritime boundaries or shows them only approximately and in those places they really matter. Fut.Perf. 20:13, 4 August 2019 (UTC)[reply]
  • Support removal I've reverted the addition of at least 3 of these today. Why? Because the borders on the maps are quite frankly dreadful. The underlying maps themselves are fine, it's the red drawn on borders that are of worse than zero value. They're interactive so you can zoom in, at which point you see the country border clearly on the main map, but the red outline of the supposed border that is only accurate to 10s of miles. The ones I reverted had borders in other countries. The France one had the French border going through Jersey and it appeared to have annexed chunks of Belgium. The attention to detail of them is quite appalling, and there is no evidence to support what they are actually using for the maritime borders, which look quite wrong. So on the grounds that these add on borders are very obviously not accurate, they should be removed as it's quite against what we're trying to do here. Unless Geneva has been taken over by France without the news having noted it (just check the history on the France article). They're simply laughably wrong. Canterbury Tail talk 00:15, 5 August 2019 (UTC)[reply]
@Epicgenius: No it's not the thickness of the border I'm concerned about. It's the fact the red borders overlaid on top of the maps have zero resemblance to the actual borders due to their extremely low number of data points. Canterbury Tail talk 16:29, 5 August 2019 (UTC)[reply]
  • Support removal - Poor quality, outside of community control. Beyond My Ken (talk) 02:39, 5 August 2019 (UTC)[reply]
  • Comment This feature was enabled based on the discussion Pump Technical: Should we ask for mapframe to be turned on? At the time I had potential concerns about the feature, and I was particularly concerned that such a significant proposal was posted at Pump Technical rather than posted to Pump Proposals. It appears to have resulted in a rather distinct skew in participation. The discussion was buried under heavy Snow when I stumbled onto it, so it seemed futile to investigate my concerns about the feature. Ironically I discovered this new discussion had been posted to Pump Miscellaneous, so I moved it to Pump Proposals. I want to ensure that all Proposal-page-watchers would have a chance to review this significant development this time. I still haven't investigated this as carefully as I'd like. On one hand I can see how the maps could be useful, on the other hand I'm very concerned about how this imports external content. Alsee (talk) 10:59, 5 August 2019 (UTC)[reply]
  • Weak support removal for national and sub-national articles; oppose for smaller human settlements such as cities, towns, and counties. The OSM map for countries, and sub-national entities such as U.S. states, seems slightly unnecessary due to there being SVG maps of almost all of these, if not every. Besides, these are typically easily-recognizable entities that don't need an interactive map. There may be a value in showing maritime borders though, so I don't strongly support the removal of such maps, especially since the shape formatting could be easily changed from thick red lines with dark fill, to thin black lines with no fill.
    For smaller human settlements, though, I don't support their removal, or I do support keeping the maps that are already there. These are not easily recognizable shapes and not everyone will be able to locate these on a map. Even if there's SVG maps showing the locations of towns, cities, counties, etc., they can't be zoomed-in. For instance, the article on Los Angeles city may benefit from an OSM map of the borders, since the SVG map (File:LA County Incorporated Areas Los Angeles highlighted.svg) can't be zoomed-in to show the jagged borders of the city. epicgenius (talk) 12:02, 5 August 2019 (UTC)[reply]
  • Comment It isn't clear why some of the discussion refers to "road maps", because the maps added by {{maplink}} aren't necessarily road maps; see (for example) this edit to United Kingdom. David Biddulph (talk) 15:10, 5 August 2019 (UTC)[reply]
  • Comment - look everyone, Wikipedia sucks too. Outside a hodgepodge of science and Dungeons and Dragons articles, there's plenty that are atrocious. Basically every article in the food, wine, and beverage field is a collection of minor edits into something barely cohesive. We're getting too far ahead of ourselves by trying to ban a tool that has some flaws but yet some good uses, just like Wikipedia does. Google, Facebook, Apple, and others link to, call on, and utilize Wikipedia in their software, understanding its imperfections and supporting its improvement. Why can't we with OSM? Let's use it where it is accurate, and when it isn't, we won't; otherwise we can edit it pretty easily. ɱ (talk) 16:03, 5 August 2019 (UTC)[reply]
  • Comment—can someone please clarify terminology here? Is proposal related to all maps, or just "road maps"? In the latter case, many articles have used KMLs to draw the routes of subject roads on a map, and it's been trivial to convert these KMLs into GeoJSON data used to draw the route of a roadway on one of these interactive maps, allowing readers to zoom in and view the road in more detail without leaving the article. It is also quite easy to create and edit KML files (and their resulting GeoJSON) to create or update the road maps used in highway articles without resorting to dedicated GIS software with steep learning curves just to output an SVG that will need cleanup to be useful as a map in a highway article. If this proposal were to touch upon road and highway articles, then I disapprove of it in that context and support keeping the maps around. Imzadi 1979  17:03, 5 August 2019 (UTC)[reply]
    • @David Biddulph and Imzadi1979: I don't think this has anything to do with maps placed in road-related articles. Rather, it's the inclusion of OSM maps in articles about geopolitical entities. The reason why they are being referred to as "road maps", is because OSM contains roads as well, whereas regular SVG images don't. epicgenius (talk) 18:18, 5 August 2019 (UTC)[reply]
  • Continue using OpenStreetMap, and expand the use of this resource. Whether linking in the article or just using the coords template should be done on a case-by-case basis, but we should use interactive maps where we can, and OSM are the best available open content maps. —Kusma (t·c) 17:30, 5 August 2019 (UTC)[reply]
  • Keep but only for use in road articles. Maps of this kind should not be used in articles for countries or other political divisions because border accuracy is generally poor, apparently due to low resolution. See this edit to France, which was soon reverted due to significant inaccuracies. Highway 89 (talk) 19:49, 5 August 2019 (UTC)[reply]
    • Regarding the map you reference -- The fact that the line cuts through the very edge of Jersey...it didn't throw me. If the lines were curves and followed the contours of the borders and rivers....sure, then it would have bothered me. But the lines are drawn in polygon style. It is not perfect, but I see a high value in this kind of map when it accompanies an article and I can therefore forgive the crudeness of the shape of the line. Phatblackmama (talk) 21:25, 5 August 2019 (UTC)[reply]
  • Keep maps when they're wanted by the editors of that article. This should be a case-by-case, strictly individual decision. If a better one is available (however the editors at that particular article define "better"), then use the better one, but when the interactive map is the best one, then use the interactive map. OSM is a wiki like us, so if it's wrong (tolerably rare, I understand), then you could go there and fix it yourself, or even just leave them a nice note about the problem, the way so readers leave notes for us on the village pump pages. And if the main problem is that you don't know how to fix these maps yourself, then learn how to improve them! Adding points is not rocket science. voy:Wikivoyage:Dynamic maps Expedition has some decent tools, and possibly even better than the help pages that we have locally. WhatamIdoing (talk) 23:06, 5 August 2019 (UTC)[reply]
    • Well, in the case of the country boundaries, I wouldn't say the errors are "tolerably rare". They are ubiquitous. And in the case of the maritime boundaries, trying to include them is a fundamental conceptual mistake and leads to unavoidable errors and WP:OR throughout, and I at least have no idea what I'd have to do to remove them, even if I wanted to edit OSM. Fut.Perf. 07:23, 6 August 2019 (UTC)[reply]
  • Keep for roads as they (unlike "big" things like France) will require a level of volume and consistency not achievable with individual file uploads. You know, unless we program a sophisticated bot to generate SVG map files from (you guessed it) OpenStreetMap data. ―cobaltcigs 23:19, 5 August 2019 (UTC)[reply]
  • Remove. They may possible be useful for roads at a fairly low level. For land borders of countries they are mostly useless, and for maritime borders they are in some cases hugely misleading, not to say plain wrong. Another case of "automatic edits" going wrong. The real world is simply not clear-cut enough to use such "tools" in an encyclopedia. --T*U (talk) 08:00, 6 August 2019 (UTC)[reply]
  • Strong keep: The maps help the user when there's otherwise no map. ChristianKl09:55, 6 August 2019 (UTC)[reply]
The articles in question have multiple boundary maps...in many cases multiple in the lead. Are you referring to road maps?--Moxy 🍁 23:51, 6 August 2019 (UTC)[reply]
--Moxy 🍁 23:51, 6 August 2019 (UTC)[reply]
  • Strong keep: Maps are very helpful for providing spatial knowledge to our readers. If any map is incorrect, it could be discussed on talk page or commented till it is fixed.Arjunaraoc (talk) 07:26, 7 August 2019 (UTC)[reply]
  • Strong keep as per Kozuch and Arjunaraoc. This is a tool that his very useful in some instances. I think the thick red line by default is ugly but this can be changed. The UK maritime map looks much better with a thin blue line (the accuracy is another matter). If the OSM data is too low resolution for purpose on the page in question the map should not be used there. Higher resolution data can be added. Like nearly everything added to an article, the editors should evaluate whether it is a good addition that improves the page. The individual talk places are the place for discussion of such edits. Banning the tool because the output is not always suitable seems a draconian approach. My biggest problem with these maps is that any further development is on hold.   Jts1882 | talk  08:25, 7 August 2019 (UTC)[reply]
  • Mu. Let's first be sure we're on the same page as to what these maps are, how their rendering works, and which errors/features/oversimplifications are due to OSM coders, OSM mappers, and WP/WMF coders. DaßWölf 10:21, 7 August 2019 (UTC)[reply]
  • ’’’Support removal’’’ from non road articles. Border of the Balkans is completely misleading.--2605:8D80:563:95E2:C8DD:6BEB:74A6:8DF9 (talk) 15:04, 8 August 2019 (UTC)[reply]
  • Support removal per Iridescent, Canterbury Tail, and others. Not a positive addition to our articles. Happy days, LindsayHello 17:49, 8 August 2019 (UTC)[reply]
  • Use them when they improve the article, take them out when they are not useful No need for overlegislating this. · · · Peter Southwood (talk): 18:13, 8 August 2019 (UTC)[reply]
  • Strong keep with additional WP:TROUTing for the nominator and those supporting removal. This kind of RfC is why Wikipedia can't have nice things. If you want to improve the map, it's easy enough to contribute to OpenStreetMap. Wikipedia isn't the place to manage maps, and it shouldn't be - OSM does that well, and even static maps are on Wikimedia Commons. Mike Peel (talk) 19:51, 8 August 2019 (UTC)[reply]
  • Strongly support removal. Zoom in on the Michigan one at the top of the thread to see how inaccurate the border is. For example, it shows parts of Kingsford, Michigan as being in Aurora, Florence County, Wisconsin. Being crowdsourced on another website, the maps do not comply with WP:V and aren't subject to WP's editorial controls. The risk of putting out bad information is too large. An interactive map would be great, but not a crowdsourced one from another website. Levivich 21:39, 8 August 2019 (UTC)[reply]
  • Moot. The border issue is not an issue at all: the "inaccuracies" of land borders are there apparently because of a problem with our templates, which retain the same coarse polygon when you zoom in (compare the mapframe borders of France linked above [6] with the actual OSM entity [7]). And besides, why would we want to add OSM maps for country or state borders? We already have good image maps, and conveniently, they don't allow you to zoom in beyond their intended resolution. And if there are problems with marginal use cases (like borders or highways), then just don't use OSM maps in those marginal cases. For the much more numerous point-like features (like settlements), they're indispensible. And obviously, editors should'be be adding them en masse to articles unless there's been a discussion first. – Uanfala (talk) 13:39, 9 August 2019 (UTC)[reply]
  • Support removal. Based on the removal points above. The known 2-year-old bugs probably aren't going to be fixed soon. In the maps' current state, they are not as valuable as they should be and this sadly isn't going to change anytime soon. So, remove. LittleCuteSuit (talk) 20:14, 18 August 2019 (UTC)[reply]

External websites

When selecting the map it takes you to an external link of the map...is this a case of an exception of our guide that merits an external link in the lead as per WP:ELPOINTS? "With rare exceptions, external links should not be used in the body of an article.".--Moxy 🍁 15:32, 4 August 2019 (UTC)[reply]
The EL argument makes no sense. It was created so people don't write "The London Philharmonic Orchestra (LPO) is a British Orchestra"... Not so we don't attribute content used in the article, or can't use that content whatsoever. ɱ (talk) 15:45, 4 August 2019 (UTC)[reply]
Normally external links of any kind in the body of an article indicate to our readers that it's an external link like with {{External media}}... and normally only after thoughtful consideration especially when it's in the lead.--Moxy 🍁 16:04, 4 August 2019 (UTC)[reply]
Great but it's clear that maps that use external data need to attribute it. Do you have any other proposal for attributing the map data to OSM? Anyhow, it's not in the spirit of WP:ELPOINTS, written merely so people don't paste in spam/promotional ELs throughout an article, like in the example above. ɱ (talk) 16:37, 4 August 2019 (UTC)[reply]
Normally, external links in the body off an article aren't marked well, because they're leading to Wikisource or Wiktionary. We also see them for links to Bible verses, IETF RFCs, as non-ref-tag-using inline citations in some tables (especially in lists of websites), and in the {{coord}} template, among other things. "Not normally" means "rather more often than rarely, once you count all the exceptions up" in this instance. And I can't say that I share Moxy's believe that {{External media}} is deployed only after thoughtful consideration. But no, this is not a violation of anything in WP:EL. WhatamIdoing (talk) 23:11, 5 August 2019 (UTC)[reply]
No indication it's an external link to an OR map not editable by this community ....see Poland info box. --Moxy 🍁 17:40, 4 August 2019 (UTC)[reply]
Ehh, it just goes to an information page about their copyright. And basically all Wikipedia maps are OR, so... ɱ (talk) 18:04, 4 August 2019 (UTC)[reply]
Maps must be sourced just like any other content....even so called sourced maps that the community can edit are marked/tagged as being unfactual something. This cannot be done by this community at an external website. See File:NouvelleFrance-Vraie-Version.png for what is done so editors can see what's going on with disputed Maps. --Moxy 🍁 18:19, 4 August 2019 (UTC)[reply]
I get that with historical maps, but most infobox boundary maps, like Michigan's borders, are sky-blue cases that don't need RSs. The jpg/svg infobox maps typically don't. That's my point. ɱ (talk) 18:31, 4 August 2019 (UTC)[reply]
  • The map is not an external link. It's a Wikipedia/WMF-generated map using OSM data on the backend. Your browser doesn't contact OSM servers when it renders the map. OSM requires users of its data to draw their own maps anyway. Re: interactive maps, I'd go as far as to say that if we want to offer private internal interactive maps without cataloguing a database of roads, borders, rivers etc. ourselves (ie. duplicating what OSM editors have done), OSM is the only realistic choice.
That being said, the map does offer links to various commercial websites in a drop-down menu on the bottom right of the screen. Those indeed are external links that we probably don't really need but offer for convenience of users who don't care what an external link is. DaßWölf 10:15, 7 August 2019 (UTC)[reply]

Civil parish bot

I started a discussion at Wikipedia:Bot requests#Civil parish bot to have a bot create the missing civil parishes in England (about 700) but there were a few problems, namely that my instructions weren't clear enough, that it would be violating my creation restriction (not so) and that they might not be notable (not so, civil parishes as opposed to ecclesiastical parishes are legally recognized administrative division per WP:GEOLAND).

I have created User:Crouch, Swale/Bot tasks/Civil parishes (current)/Simple which is the current model, there is also User:Crouch, Swale/Bot tasks/Civil parishes (current)/Coded and User:Crouch, Swale/Bot tasks/Civil parishes (current) which provide more instructions and some arguments for an against for bot created articles at User:Crouch, Swale/Bot tasks/Civil parishes (current)#Process.

There are 2 questions here, who has the understanding to program such a bot and are there any other things that need to be improves/changed to ensure that this works correctly or to otherwise improve the articles.

It would be good if eventually we could do the same thing for places in other countries to but we'll start with England for now. Crouch, Swale (talk) 12:02, 5 August 2019 (UTC)[reply]

I call WP:OTHERPARENT on this: although Crouch, Swale has linked Wikipedia:Bot requests#Civil parish bot, they fail to link the other places where they've requested this, such as Wikipedia talk:WikiProject England/Archive 4#Bot created articles. --Redrose64 🌹 (talk) 20:53, 5 August 2019 (UTC)[reply]
Not quite WP:FORUMSHOPing more than "wants to do something, but doesn't know what to do, so trying everything and seeing if something sticks". Truth is, no one seems interested in this, especially because of the lack of a clear example, with clear bot logic. And until those are in, interest will remain low. Headbomb {t · c · p · b} 03:19, 6 August 2019 (UTC)[reply]
  • Comment I'm not sure that this is the most necessary bot in the world (I don't believe that the US counties were created by a bot, for example), but nor do I adamantly oppose it on principle if all of the kinks get worked out. – John M Wolfson (talkcontribs) 00:34, 7 August 2019 (UTC)[reply]
  • Weren't the US counties created in the same way as the settlements, it looks like Ram-Man didn't have a separate account for the bot until later [8][9]. Anyway indeed the bot shouldn't be approved until we're sure its OK. Crouch, Swale (talk) 17:15, 8 August 2019 (UTC)[reply]
  • Based on my instructions does anyone have the ability to construct a code for the bot? If that can be done then we'd be going in the right direction to see if there's consensus. Crouch, Swale (talk) 08:00, 10 August 2019 (UTC)[reply]
    I've notified BON. Crouch, Swale (talk) 11:07, 13 August 2019 (UTC)[reply]
    @Crouch, Swale: I might be able to code such a bot, but I need some more info. Your /simple, /coded, and (current) are confusing. Can you please create: 1 full fledged example article (what the bot should be able to produce) and 1 "shell" with the content that would be common to all of the articles? (Like every single one will have == References == and {{Reflist}} DannyS712 (talk) 11:13, 13 August 2019 (UTC)[reply]
    @DannyS712: I have created User:Crouch, Swale/CP example which is an example "full fledged article" (although the categories obviously wouldn't be disabled). In the User:Crouch, Swale/Bot tasks/Civil parishes (current)/Coded example the words that aren't in "" are the content that would be common to all articles. In other words all articles will have the text "The parish touches" but the names of the parishes will be variable. The example given (Rattlesden) is one that already exists but illustrates how it would be created if it didn't exist. Note that I have removed the notes from the coded one but they'll stil be useful to the bot operator. Crouch, Swale (talk) 11:35, 13 August 2019 (UTC)[reply]
    @Crouch, Swale: Okay. So I see it as a shell that needs the following parameters:
    1. Name (without disambiguation)
    2. Region
    3. Centre point from City Population
    4. District name
    5. County name
    6. Population
    7. Area
    8. District name (with disambiguation)
    9. Touching parishes
    10. Number of listed buildings
    and, for each article, the title at which it should be located. It seems fairly straightforward, as long as all of that information can be retrieved in a usable format. Do you have a good way to get that data? If so, I'd be willing to fulfill the bot request, provided that there is indeed consensus for it. DannyS712 (talk) 11:58, 13 August 2019 (UTC)[reply]
    @DannyS712: these are explained at User:Crouch, Swale/Bot tasks/Civil parishes (current)/Simple but I'll add a bit here.
  • Name (without disambiguation)
    If the title isn't disambiguated then this will be the same as the title (as with the Rattlesden example) if the title is disambiguated (such as Boxford, Suffolk) then that will need to be removed from the "official_name" "civil_parish" and the bold face at the beginning. In other words for the Boxford, Suffolk example all 3 would just be "Boxford" not "Boxford, Suffolk" that is to say the name used on City Population.
  • Region
    The name of the region given in City Population which is not linked in the infobox for example "East of England" or "North East".
  • Centre point from City Population
    This is the middle (centre) point of the area given for the parish at City Population, if its not possible for the bot to get that then the coordinates from the Ordnance Survey linked data can be used. This is also used to measure the distance from the county town.
  • District name
    The title of the district (which might be disambiguated) for example linked as Babergh (and Category:Babergh) if not disambiguated but Arun (and Category:Arun District) or Stafford (and Category:Borough of Stafford) if it is. Remembering also if its a unitary authority.
  • County name
    Ceremonial county thus for Olney its Buckinghamshire not Milton Keynes.
  • Population
    The 2011 figure given by City Population, which is omitted if City Population doesn't give any data (mainly for parishes of less than 100) also noting that the sentence "In 2011 the parish had a population of X" is removed.
  • Area
    When you click on an entry at City Population it gives the area (which is 13.2 for Rattlesden). This is only added to the infobox.
  • District name (with disambiguation)
    As with the district name above this means that the district article (and/or category) might be disambiguated as explained above, if the article is then it needs to be piped in text as explained.
  • Touching parishes
    The names of the other parishes the parish touches (which may be disambiguated) the bot works out the correct article by checking the coordinates of the target article or if it can't just linking to the unqualified name which I can fix.
  • Number of listed buildings
    From the listed buildings site (although the English Heritage site might be a better option but can be discussed later) namely by finding the parish from here by region then county/unitary authority then parish (and the coordinates for the buildings can be compared to those from the OS to ensure the correct parish has been found). Crouch, Swale (talk) 18:56, 13 August 2019 (UTC)[reply]
    @Crouch, Swale: I understand what they stand for. My question is if you have a spreadsheet or other place where all of the applicable data is. I'd prefer not to manually input the 2011 figures, etc. DannyS712 (talk) 03:14, 14 August 2019 (UTC)[reply]
    @DannyS712: all of the 2011 figures are at City Population by region, at South East, London, North West, East of England, West Midlands, South West, Yorkshire and the Humber, East Midlands and North East on the "Population Census 2011-03-27" row eg for Workington its 25,207. Those (such as Wythop) don't have population data but do still have the area (if you click on the area). Crouch, Swale (talk) 07:22, 14 August 2019 (UTC)[reply]
    @Crouch, Swale: for South East, I made User:DannyS712 test/parish.json, which has the data from the link you posted above. But, making that took a lot longer than I thought. If you want me to help with this, I need all of the data in one place (not population from one source, coordinates from another, etc) in a bot-readable format (ideally json). --DannyS712 (talk) 08:59, 14 August 2019 (UTC)[reply]

Combine discretionary sanctions notices

Some articles end up with multiple discretionary sanctions notices on their talk pages, when multiple reasons apply. Talk:2019 Dayton shooting is one example of the messy, confusing, and poorly readable outcome. I would suggest combining them. Like having a single template with one or more reasons plugging into it, the way Template:Multiple issues works. Sakkura (talk) 19:23, 10 August 2019 (UTC)[reply]

Some of them have specific sanctions, eg Template:ArbCom Arab-Israeli enforcement. I'm not sure what's confusing about having several on a page. --Doug Weller talk 18:10, 11 August 2019 (UTC) reping @Sakkura: --Doug Weller talk 18:12, 11 August 2019 (UTC)[reply]
A container box like we have when multiple wikiprojects would not be bad, it can lead off "This article is subject to multiple discretionary sanctions:" and include each notice. --Masem (t) 18:14, 11 August 2019 (UTC)[reply]
The DS talk page banners are technically useless anyway. Per WP:Discretionary_sanctions#Awareness_and_alerts, editors may only be sanctioned under DS if they are technically "aware" DS applies, and technical awareness is defined with various criteria. Working on an article that has a talk page DS template banner is not one of them. So in reality, these things are entirely FYI but for application of current DS procedure their very existence is a nonissue, and therefore so is there polish and form and content. All that said, support modification as follows. If the presence of the moot but FYI template text ever makes any difference to anyone, then that is the sort of person who is likely to click a link to see that text. So I think I agree, it would be nice to have a simple bannershell that lists the topics, with links to pop up the specifics for each. The reality, though, is few people will read them no matter what they say and the folks who take enough care to do so are unlikely to be source of the problems. So.... sure, clean 'em up. But it probably doesn't make a ton of difference either way and as a technical matter... they don't matter. NewsAndEventsGuy (talk) 18:17, 11 August 2019 (UTC)[reply]

Misspelled filename

It should be File:My blood is full of airplanes.jpg instead of File:My blood is full of aiplanes.jpg. Please move file to correct name with redirect and mark the redirect with {{R typo}}. — Preceding unsigned comment added by Monniasza (talkcontribs) 11:32, 11 August 2019 (UTC)[reply]

@Monniasza:  Done. Next time, please use {{rename media}} to request that a file be moved. --AntiCompositeNumber (talk) 11:40, 11 August 2019 (UTC)[reply]
My hovercraft is full of eels. --Redrose64 🌹 (talk) 16:42, 11 August 2019 (UTC)[reply]

Proposal to use a CentralNotice to publicize photo competition

There's an open proposal on Meta to run a CentralNotice banner on Wikipedia and certain other Wikimedia projects from September 1 to September 30 in order to publicize the Wiki Loves Monuments photo contest, as has been done in previous years. Please comment on the proposal at m:CentralNotice/Request/Wiki Loves Monuments 2019. --Yair rand (talk) 06:10, 14 August 2019 (UTC)[reply]

Make Compulsive masturbation into article stub

Compulsive masturbation has diagnosis criteria, so it is encyclopedic. Please make article about compulsive masturbation which will replace redirect. — Preceding unsigned comment added by Monniasza (talkcontribs) 17:28, 14 August 2019 (UTC)[reply]

You can do it yourself! See Help:Your first article for advice and details. Anomie 11:14, 15 August 2019 (UTC)[reply]

Debates regarding ongoing issues

Hi everyone, I just wanted to propose for a debate section in the talk pages of ongoing issues like the Hong Kong crisis article. This would enhance views from different people across the world and this would encourage boldness from people who previously feared editing hence bringing the vision of Wikipedia's 'Be bold'policy to a realization. Thank you -RazorTheDJ (talk) 19:45, 14 August 2019 (UTC)[reply]

Wikipedia is not a forum. I would think a debate section would be near the literal definition of a forum. --Izno (talk) 03:16, 15 August 2019 (UTC)[reply]
Yes, a talk page is not the space for a debate or any general discussion of the article's subject. However, if such a section is devoted to analyzing the viewpoints of sources with different biases and their worthiness of inclusion in articles, it may be a good idea (as long as it does not stray to personal opinions, in accordance with talk page guidelines). Those types of discussions are in the nature of a talk page. ComplexRational (talk) 09:24, 15 August 2019 (UTC)[reply]

Watchlist-message on a sister project proposal

Initial note at MediaWiki_talk:Watchlist-messages#Sister_project_proposal

I don't know what the protocol or precedent is for whether sister project proposals should be listed in the MediaWiki:Watchlist-messages. Most sister project proposals have not gained much traction and are not especially Wikipedia-relevant. However, meta:WikiJournal has had >100 comments so far and I think is fairly relevant to Wikipedia. I think getting broad feedback is valuable so it might be worth a notice briefly. Previous locations of notifications listed at this link.

Questions:

  1. Should this sister project proposal be listed in the messages
  2. If so, is the wording appropriate?
  3. If so, what is the preferred time length?

Any opinions or ideas appreciated. T.Shafee(Evo&Evo)talk 03:34, 16 August 2019 (UTC)[reply]

@Evolution and evolvability: thanks for posting this here. Perhaps a little bit more in the message hook (what is the sister project going to do - and how is is relevant to the English Wikipedia?). Just FYI, on these if noone objects at all in about a week it will usually get posted. — xaosflux Talk 14:25, 16 August 2019 (UTC)[reply]
@Xaosflux: Thanks. a few possible alternative texts below aiming to keep to typical character lengths seen in past messages (longest recent notice):
  • Initial proposed text: "A proposal for a new Sister Project is open for discussion"
  • Alt proposed text1: "A proposal for a new Sister Project to coordinate external peer review of content is open for discussion"
  • Alt proposed text2: "A proposal for a new Wikimedia Sister Project to coordinate external peer review of content via hosting open access academic journals is open for discussion" Comment/support/oppose!
  • Alt proposed text3: "A proposal for a new Wikimedia Sister Project to coordinate external peer review of content is open for discussion". This would help facilitate expert feedback for existing Wikipedia articles, provide a route for new wikipedia articles, and publish open access research articles.
Alt 3 is probably too long, but I included in case the wikipedia interaction info is useful. I'm happy for others to choose between which they think would be best (or combine/write and alternative). T.Shafee(Evo&Evo)talk 01:09, 17 August 2019 (UTC)[reply]

Update default preferences for new users

I help train new users at editathons. The Preferences defaults are not ideal for new users. At editathons we often take a special couple of minutes to advise people to change them. So I would like to change them for everyone, which will save time for lots of people. I can make this request for a "configuration change" to English Wikipedia at Phabricator but must show that there is a consensus on the proposed changes. I ask for your feedback here on two proposed changes, which I have wanted for several years:

  • Under Editing, Editing mode: should default to "Show me both editor tabs" so the new user can quickly get to the Visual Editor. We generally advise new users to use the Visual Editor immediately. They are not likely to be programmer types nowadays.
  • Under Watchlist, these four toggles below should be turned on immediately by default, otherwise the Watchlist is not useful for finding updates to their own past work. I don't know why, but for new users they are not all on by default.
    • Add pages and files I edit to my watchlist
    • Add pages and files I move to my watchlist
    • Add pages I create and files I upload to my watchlist
    • Add new files I upload to my watchlist

What do you think? -- econterms (talk) 14:13, 16 August 2019 (UTC)[reply]

@Whatamidoing (WMF): I think you might have some previous research/discussion handy for this one. --Izno (talk) 14:27, 16 August 2019 (UTC)[reply]
@Econterms: I'm not following your request very well, I just created a brand new test account to see the options:
  1. On first edit I already got the giant pop-up asking if I wanted the Visual Editor, if selected it became my default
  2. "Add pages I create and files I upload to my watchlist" is already on by default
  3. "Add pages and files I move to my watchlist" isn't in the watchlist section of preferences
  4. "Add new files I upload to my watchlist" isn't in the watchlist section of preferences
  5. "Add pages and files I edit to my watchlist" is off by default.
    For this one, I think it should be - it discourages "ownership" and also prevents watchlists from becoming horribly large over time. — xaosflux Talk 14:33, 16 August 2019 (UTC)[reply]
    OK, a little more on this. Once a user becomes confirmed/autoconfirmed then they gain access to: "Add new files I upload to my watchlist" (which is on by default) and "Add pages and files I move to my watchlist" (which is off by default). — xaosflux Talk 14:54, 16 August 2019 (UTC)[reply]
  • Thank you, xaosflux. I just checked too and I stand corrected; as you say only two of those prefs appear and the new user can indeed get to the visual editor, but they have to get something right immediately to have both editors visible. I prefer that both editor tabs be visible to anyone by default, although I understand a user can get to the Visual Editor and have it stick as you say. So I still want to make that request. And all those things should be on the watchlist asap, I think. Only experienced users have the problem of a large watchlist, and they have enough info to fix the problem. Relatively new users get something out of the watchlist system only if their very first edits show up, and often they don't. It's morale-reducing to get involved in setting technical preferences immediately when we want the new user to get the uplifting feeling of having made a fix and having the system work right. So I still want these defaults adjusted as I mentioned. Thanks for researching it. -- econterms (talk) 15:18, 16 August 2019 (UTC)[reply]
    Adding the tab buttons is "easy" and is done at other projects, for example: w:es:Special:Random. That would just require some consensus here. — xaosflux Talk 15:34, 16 August 2019 (UTC)[reply]
I agree that both edit tabs should be open immediately ( which one I tell people to start with depends on their previous computer background). Since we usually tell people to start off by editing some existing article, the default for watchlistist pages edited should be on. For most participants, their watchlist is unfortunately never going to get large enough to be confusing. DGG ( talk ) 17:53, 16 August 2019 (UTC)[reply]
I certainly agree that "Add pages and files I edit to my watchlist" should be on by default - for most of us this is most of what the watchlist is there for, & without it it isn't much use. Unfortunately most new editors don't stick around long enough to get a "horribly large" watchlist (ok, like mine is), so I'm not impressed by that concern, still less by "it discourages "ownership"". Johnbod (talk) 02:29, 17 August 2019 (UTC)[reply]
Hello, econterms,
The English Wikipedia (and maybe about a hundred other wikis?) has the mw:VisualEditor/Single edit tab configuration style. However, unlike the others, the first option here is the 2010 wikitext editor. There are advantages and disadvantages to having one vs two edit tabs. Generally speaking, with inexperienced editors and random-person user testing, one tab that starts in the visual mode is what people seem to want. But it's not an overwhelming majorty thing, because if you've edited for years and years as an IP, and now you've decided to create an account, you don't really want to see something different from what you're used to.
Among long-time experienced editors, we got used to having two tabs back in 2013, and while it took us a week or two to stop clicking on the 'wrong' one, we're over it, and most of us easily switch back and forth. Formatting disaster? Give me the wikitext. Need to insert a column in a table? Visual mode, every time. But a new editor isn't going to know the relative strengths and weaknesses of each approach, so the advantages to them are quite small. The documented disadvantages are rather significant. Offering two similar buttons creates a lot of confusion.
I don't think that the Editing team has any plans to work on this question this year, but if people want to switch the button to start with the visual mode, then I could ask the team about it. Whatamidoing (WMF) (talk) 03:15, 17 August 2019 (UTC)[reply]
Whatamidoing (WMF): I find it less confusing to offer both tabs than to have partial disclosure of the functionality. We explain why the tabs are necessary, and show that they look different visually, and move on. It is direct and clear. Both functionalities are important. It is I think more distracting for someone to need one and not see it when their mind is on a substantive problem to be addressed. It sounds like you have expert knowledge showing something different? -- econterms (talk) 08:20, 17 August 2019 (UTC)[reply]
econterms, have you tried showing them how to switch between the two modes (from inside the editor)? Whatamidoing (WMF) (talk) 03:03, 18 August 2019 (UTC)[reply]
As someone who does edit training, please make the default "both editor tabs". And is there any good reason why IPs should't be given two tabs too? Many good faith IP newbies break syntax using the source editor, but it is far more difficult to break syntax in the Visual Editor (ok, not 100% guaranteed, but very unlikely). 05:37, 17 August 2019 (UTC) — Preceding unsigned comment added by Kerry Raymond (talkcontribs)
Kerry, if IPs disproportionately screw up wikitext, then that sounds like an argument for giving them one button, which leads to the visual editor. Whatamidoing (WMF) (talk) 03:05, 18 August 2019 (UTC)[reply]
I'd be fine with that too for IPs. A lot less cleaning up of broken syntax to do and by making it more obvious/easy how to cite, the use of citations might improve. If a newbie tries to add a citation, it is typically a naked URL so using "Cite > Automatic" in Visual Editor would be a vast improvement over the things they manage to do with the URL in source editor. Kerry (talk) 03:25, 18 August 2019 (UTC)[reply]
I don't know about broken syntax (I think I generate a fair amount myself), but most unintentional WP:EGG-like links are created using the Visual Editor. I'm not sure there's less cleanup required of inexperienced VE editors or inexperienced Wikitext editors. Surveys need to be done. — Arthur Rubin (talk) 10:43, 18 August 2019 (UTC)[reply]
  • I agree that simplifying setup for new users is important. Every minor bit of configuration you need to do before you can start doing something useful is 1) An opportunity to get things set up wrong, and 2) A turnoff to new users. Maybe as a workaround, there could be some piece of javascript which sets everything up properly for a new user, and a big friendly button on the editathon home page that says, "Click me first!". Even cooler, I could imagine a system which clones an account. So, the editathon organizer could create a new account as a template and configure it in whatever way they feel works best for their teaching style/environment. Then, they could freeze that configuration, and have the "Click me first!" button use that to configure a new account the same way. — Preceding unsigned comment added by RoySmith (talkcontribs) 16:02, 17 August 2019 (UTC)[reply]