Jump to content

Wikipedia:Village pump (policy): Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
m →Notifications: fix sig
Line 1,045: Line 1,045:
===Notifications===
===Notifications===
Previous RFCs on this topic has been impacted by [[WP:CANVASSING|canvassing]]. For transparency, please only leave neutrally worded notifications and list them in this section.
Previous RFCs on this topic has been impacted by [[WP:CANVASSING|canvassing]]. For transparency, please only leave neutrally worded notifications and list them in this section.
* [[User talk:Spartaz]] notified by 23:56, 9 February 2018 (UTC)
* [[User talk:Spartaz]] notified by <b>[[User:Billhpike|BillHPike]]</b> <small>([[User talk:Billhpike|talk]], [[Special:contribs/Billhpike|contribs]])</small> 23:57, 9 February 2018 (UTC)


===Comments===
===Comments===

Revision as of 23:57, 9 February 2018

"WP:VPP" redirects here. For proposals, see Wikipedia:Village pump (proposals).
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The policy section of the village pump is used to discuss proposed policies and guidelines and changes to existing policies and guidelines.
If you want to propose something new that is not a policy or guideline, use Village pump (proposals).
If you have a question about how to apply an existing policy or guideline, try one of the many Wikipedia:Noticeboards.
This is not the place to resolve disputes over how a policy should be implemented. Please see Wikipedia:Dispute resolution for how to proceed in such cases.

Please see this FAQ page for a list of frequently rejected or ignored proposals.


Should Wikipedia have and maintain complete lists of airline destinations?

Closing this section and the Aftermath section below (incase editors use OneClickArchive). –Davey2010Talk 00:02, 29 January 2018 (UTC)[reply]

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

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
The result of this discussion was that there appears to be consensus Wikipedia should not have these lists, due to the excessive detail and maintenance required for keeping a local version up to date of data which is available directly from airline websites anyway. Basically, the arguments in Wikipedia is not a directory. fish&karate 11:47, 23 January 2018 (UTC)[reply]

See Category:Lists of airline destinations. These 444 pages are lists of every single city each of these airlines fly to. Should Wikipedia be hosting this content or is it a case of Wikipedia is not a directory? 22:28, 1 January 2018 (UTC)

  • It is my belief that these were created in good faith by somewhat over-eager fans of aviation. These lists provide far more information than is needed for a general-knowledge encyclopedia and to my mind amount to free advertising for the airlines, although I'd again like to stress that I do not believe that was the intent behind them.
An explanation in the main article on an airline of what region an airline operates in and what cities are its hubs is more than enough explanation, if readers desire further information they can follow the links to the airlines own website, which is far more likely to be accurate and up-to-date anyway. There is an important distinction between information and knowledge. Wikipedia strives to provide knowledge, and is explicitly not a directory or catalog, which is just information. I therefore believe a community discussion of whether we should retain this content is in order. Beeblebrox (talk) 22:28, 1 January 2018 (UTC)[reply]
  • Well, I just looked at one - the um, list was started 14 years ago! and it was pretty up-to-date - what are you going to do with them? Alanscottwalker (talk) 23:25, 1 January 2018 (UTC)[reply]
  • wow. I'd no idea we had that. I just looked at a few (per Alanscottwalker) and they look to be in good shape. Some in really good shape. So I have no problem with us keeping these as long as they can be kept up. So yes I suppose. Hobit (talk) 00:01, 2 January 2018 (UTC)[reply]
  • Can we somehow port these over to Wikivoyage? bd2412 T 00:12, 2 January 2018 (UTC)[reply]
  • Question: How is this any different from all our super-detailed info about railway, bus, streetcar, subway, and other transit destinations? The only obvious differences are the mode of transport and distance covered (sometimes – but there are very short flights and very long railway lines). A less obvious distinction is that it's easier to change flight patterns and routes of service, so they will change more often, so these lists will need more maintenance. We have lots of lists that need regular maintenance, so again: how it this case different? All that said and asked, I have no particular objection to the idea of moving the info to WikiVoyage, if that site is still really alive. Just makes me wonder what else should move there if we go that route [pun intended].  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  01:53, 2 January 2018 (UTC)[reply]
  • Obviously not. This is what NOTDIR is for. Regardless of how "current" these lists are, they do not belong here. If another site or project wants them, they can have them; we are CC-licensed, after all. James (talk/contribs) 14:38, 2 January 2018 (UTC)[reply]
  • Comment – See previous (10+ year old) deletion discussions here and here. –Deacon Vorbis (carbon • videos) 15:13, 2 January 2018 (UTC)[reply]
  • Comment Is this any different from the "airlines and destinations" section present in almost every article about a commercial airport? As much as I like the sections because they give one an idea of the "reach" of an airport, I can't come up with a policy-based argument for keeping one but not the other. – Train2104 (t • c) 16:41, 2 January 2018 (UTC)[reply]
  • No - As BD2412 suggested above, the information should somehow be copied over to Wikivoyage. - Knowledgekid87 (talk) 16:44, 2 January 2018 (UTC)[reply]
  • Perhaps re-run the old deletion noms? See what happens? -- Alanscottwalker (talk) 16:50, 2 January 2018 (UTC)[reply]
  • I don't have a problem at all with the well-maintained ones, and have often used the destinations lists in airport articles. Just like most other transportation related articles, they are typically up to date, well maintained and useful. Wikipedia is not only a "general purpose encyclopaedia", but in addition contains vast amounts of specialised knowledge. I can't see a huge difference between lists of this type and many of our sports statistics pages -- both are specialised and require frequent updating. There may be interesting content to add to many of the lists (reasons for opening and closing of certain routes, or which routes were bought when some other operator collapsed). The historical destination lists seem to me to be a possibly quite valuable resource. Removing all those pages will throw out a lot of encyclopaedic material; not worth it just because some of them feel like they might not belong. —Kusma (t·c) 17:10, 2 January 2018 (UTC)[reply]
  • Is there a way to separate the historical ones then or include the information via prose in other articles? If I were looking for what plane took me where I would inquire a travel agent, not Wikipedia. - Knowledgekid87 (talk) 17:13, 2 January 2018 (UTC)[reply]
I do think that since changes in destinations do receive coverage it kinda makes sense to have it. Galobtter (pingó mió) 17:14, 2 January 2018 (UTC)[reply]
  • Yes It seems likely that these lists have been spun off from the airline articles as they have grown and developed. If there is scope for improvement in the way we do this, this this should happen in an organic way, rather than being disrupted by some crass deletionism, which has already been tried and failed. WikiVoyage would be hopeless as a substitute. It doesn't have pages for individual airlines and so does not appear when you search for such information, where our pages do. Wikidata might be better as a repository because their data is more comprehensive and better structured as a database. Exploring this possibility should be done in a constructive rather than destructive way per our editing policy. Andrew D. (talk) 17:28, 2 January 2018 (UTC)[reply]
  • Yes, despite wanting to say no, because Wikivoyage ought to be the more natural place for this sort of thing. Problem is, the editors at Wikivoyage disagree with this assessment! In early 2017 a decision was made to not host information about airlines or destinations due to concerns about how much there would be to maintain, and because they aren't attempting to maintain similar sorts of information about bus or train lines. There are other reasons, too. See wikivoyage:Talk:Airlines for more of that conversation.
But therein lies the reason why this information is probably okay to stay on Wikipedia -- we do maintain extremely comprehensive information about destinations served by train and bus lines all over the world. Random example: List of Toronto Transit Commission bus routes The long-standing existence of lists of routes suggests to me that Wikipedia has long accepted consensus around the idea of providing information about destinations. I guess I just don't why rail & bus would be fine, but airline would not -- servicing destinations is the intrinsic purpose of these businesses, right? A transit company/agency that didn't serve destinations wouldn't even be notable, right? Warren -talk- 03:06, 3 January 2018 (UTC)[reply]
  • If Wikivoyage decided some time ago not to host these, perhaps we can ask them to reconsider. Obviously there is a community of interest willing to maintain them. Maybe those editors would be willing to maintain them on a sister project. bd2412 T 04:41, 3 January 2018 (UTC)[reply]
Agree that the next step is for this to go to s “formal” AFD... if only to ensure wider consensus and notification. Blueboar (talk) 16:22, 10 January 2018 (UTC)[reply]
That should go too. Its not remotely as notable as London Buses route 161. Only in death does duty end (talk) 17:02, 10 January 2018 (UTC)[reply]
Why would it do that? In this case, we are not a dumping ground for travel destinations. - Knowledgekid87 (talk) 17:05, 10 January 2018 (UTC)[reply]
There is nothing wrong with article London Buses route 159. Staszek Lem (talk) 18:41, 10 January 2018 (UTC)[reply]
Exactly. Indicating what region they operate in, which cities are hubs, and providing a link to their website gives the reader all the information they could possibly want. No one could actully plan a trip based on these lists, they are just long lists of information, without any knowledge behind them. They provide no benefit to the reader that they couldn’t get (in much more detail like routes and times) by just clicking the link and going to the airline’s own website, which the airline would be paying someone to maintain and keep up to date in real time as changes occur. Beeblebrox (talk) 22:34, 22 January 2018 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Aftermath

This is currently at both WP:AN and WP:ANI, comment there rather than here. power~enwiki (π, ν) 22:55, 28 January 2018 (UTC)[reply]

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

I've seen a bunch of deletions of these pages by Beeblebrox today (e.g. American Airlines destinations). There are also a bunch of links to those pages that need to be removed, and some airline pages (Ansett Australia) have sections with full lists of destinations removed as well. power~enwiki (π, ν) 22:06, 28 January 2018 (UTC)[reply]

Based on discussion at User_talk:Beeblebrox#Air_New_Zealand_Destinations these speedy-deletions may be getting reverted. power~enwiki (π, ν) 22:17, 28 January 2018 (UTC)[reply]

Yeah, we apparently need to have another discussion about whether consensus counts for anything in this case. Beeblebrox (talk) 22:30, 28 January 2018 (UTC)[reply]

I think it's more about who was informed about such a discussion. I may be wrong, of course, but I'm never wrong, so I guess that's the case. The Rambling Man (talk) 22:32, 28 January 2018 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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: Is "telenovela" a suitable disambiguator?

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Television shows are to be disambiguated with (TV series) and not using the genre or format of the show. If this does not resolve the ambiguity, a consensus of editors on the article's talk page should determine what additional disambiguation qualifier is appropriate, on a per-article basis.
With respect to AussieLegend, it does seem as though this discussion had run its course when it was first closed. Ivanvector (Talk/Edits) 18:42, 30 January 2018 (UTC)[reply]

Should we allow "telenovela" to be used as a disambiguator? There was recently a discussion at Wikipedia talk:Naming conventions (television)#RfC: Telenovela disambiguation which, despite being fairly thoroughly discussed among a number of topically interested editors, failed to come to consensus, and the closer specifically directed that a broader discussion would be needed to resolve the matter. --woodensuperman 09:15, 9 January 2018 (UTC)[reply]

  • Oppose. "TV series" is sufficient. A telenovela is still a TV series. We do not allow other genres of TV series to be disambiguated in this way (sitcom, soap opera, etc, etc), so WP:CONSISTENCY is an issue. This is not sanctioned at WP:NCTV, and despite the recent RfC which resulted in no consensus to add this as a disambiguator, the poorly worded close means that despite there being no consensus to allow this, articles can remain at a title which goes against our naming convention guideline. --woodensuperman 09:15, 9 January 2018 (UTC)[reply]
  • Oppose per WP:USEENGLISH and WP:OVERDAB. Woodensuperman is exactly right; this would open the door to "Foo Bar (soap opera)", etc., and even to use of non-English labels for these things.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  09:26, 9 January 2018 (UTC)[reply]
  • Comment Just to point out that most telenovela have been disambiguated as such for quite awhile. The main argument being that telenovela is a format rather than a genre - the genre being soap opera. We don't disambiguate by genre but we do by format (sometimes). A no-consensus result means that there would be no consensus to change these from the status quo (already disambiguated as telenovela). Only in death does duty end (talk) 09:30, 9 January 2018 (UTC)[reply]
I disagree. A "no consensus" close means there is no consensus to change the guideline, and article titles which go against the guideline should be moved in line with it. There has never been consensus to allow "telenovela". --woodensuperman 09:37, 9 January 2018 (UTC)[reply]
Guidelines are not binding policy and can (and are) ignored regularly. You would need actual consensus to mass-rename a bunch of articles beyond 'this guideline says so' when they have been stable for a significant period of time. (FWIW I actually think they should be disambiguated as TV series, as the technical differences between tv-series, soap operas, telenovela's are a matter for categorization, not disambiguation) Only in death does duty end (talk) 09:40, 9 January 2018 (UTC)[reply]
What Woodensuperman said is absolutely what it means. It is not possible under WP:CONLEVEL policy for the failure of a minor discussion on a backwater page to even come to a consensus, to magically transform into the overturning of an actual site-wide guideline. That's ass-backwards. RM discussions and RfCs about moving articles are the consensus discussions to move the articles, so what you're saying must happen is happening. I.e., you're making a point that isn't a point. Finally, there is no principle that a mistake that has languished for a long time cannot be corrected. We regularly – like every single day – move badly named articles to comply with WP:AT policy, the WP:MOS guidelines, the WP:DAB guideline, and/or the naming conventions guidelines, more often than not via the WP:RM/TR speedy process. PS: Since you actually say you agree with the proposed change, please do not post devil's-advocate stuff like this. It's a waste of other editors' time.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  09:49, 9 January 2018 (UTC)[reply]
While I generally agree with you, the main problem is there are already exceptions in the relevant guideline which indicates it is not a hard and fast 'generally accepted' for everything. Just most things. More than a few of the policies and guidelines which include exceptions state that others not listed may exist, because nothing is entirely documented to that level of detail. If the relevant guideline were so hard and fast, a bulk-rename request should have sailed through. That no one attempted it suggests less than absolute confidence. Only in death does duty end (talk) 14:41, 9 January 2018 (UTC)[reply]
As I mention above, perhaps now is the time to get rid of the exception for "miniseries" too. "TV series" can work equally well for these, and usage of "miniseries" is not universal, and could be controversial, especially when it is used for non-US shows. --woodensuperman 14:47, 9 January 2018 (UTC)[reply]
I would also agree that's probably a good idea. Telenovelas have more in common with miniseries in structure (apart from the obvious one - length) than standard TV-series. And a guideline that doesn't include exceptions is less difficult to wriggle around. Only in death does duty end (talk) 14:51, 9 January 2018 (UTC)[reply]
  • Oppose - there is no call for one particular genre to be an exception to a WP:NCTV guideline. The same problem exists for articles named with (anime). Why are these exceptions just because they originate in non-English countries/languages? The argument that this is a "format" vs a genre is flawed as no one can define this "format" in a way that doesn't also fit other (TV series) unless you bring up language, storyline types, or run length - all of which could apply to any other TV series. None of these is sufficient. -- Netoholic @ 10:02, 9 January 2018 (UTC)[reply]
  • Oppose per SMcCandlish and Netoholic. Would lead to endless special pleading and wheel warring. James (talk/contribs) 13:47, 9 January 2018 (UTC)[reply]
  • No. (This is phrased as a yes/no question, people, not as a proposal to support or oppose). Per our article, similarly formatted shows are called different things in different places around the world. Taking this to the extreme would produce a whole host of different disambiguators for each one, which is silly compared to using what they're all common examples of. –Deacon Vorbis (carbon • videos) 14:02, 9 January 2018 (UTC)[reply]
  • Oppose "TV series" is fine, we shouldn't use the show's genre unless all other options are taken (eg two shows, from the same country, from the same year, with the same name, then we'd have to distinguish by their style). --Masem (t) 14:49, 9 January 2018 (UTC)[reply]
  • No per others. Same for miniseries, (anime) in MOS:ANIME etc. Genre is vague and creates complexity- having it all as TV series is simple and consistent. Galobtter (pingó mió) 07:30, 11 January 2018 (UTC)[reply]
  • No, per discussion above. Although I've been neutral on this, and can see an important cultural component in various usages of the terms, consistency does favor labeling Wikipedia articles on fictional television series with the same descriptor. Article text itself should still allow use of the term, and hopefully no objection to in-text usage will arise based on this RfC. Randy Kryn (talk) 13:08, 11 January 2018 (UTC)[reply]
I don't think anyone is suggesting that we stop using it in article text, or indeed as a category name - we happily use "sitcom" or "soap opera" in this way. --woodensuperman 13:55, 11 January 2018 (UTC)[reply]
Extended content
Although it's been discussed in this RfC, I don't think the use of the term "miniseries" is being decided here. That seems like another discussion, as miniseries has a meaning in English related-but-separate-from "TV series". Randy Kryn (talk) 14:06, 11 January 2018 (UTC)[reply]
Agree, let's keep on topic. -- Netoholic @ 04:59, 12 January 2018 (UTC)[reply]
  • Proposal to amend WP:NCTV. As we seem to have clear consensus, I would propose adding the following (or similar) to the guideline:
"Do not disambiguate by genre or format, i.e. "sitcom", "telenovela", "soap opera", etc., unless multiple articles for TV series from the same year, region 
and network exist and further disambiguation is required."
Would appreciate any comments or improvements. --woodensuperman 09:25, 19 January 2018 (UTC)[reply]
  • My suggested version would be "If the year, country, or a combination of both is still insufficient to disambiguate the topic, only then should the use of an appropriate genre or format word ("sitcom", "telenovela", etc.) be considered via a page move request - announced to WT:NCTV, WT:WikiProject Television, and any other relevant discussion pages.". This line could also replace the (animated) option, since that is a similar odd situation, and rarely used correctly anyway. -- Netoholic @ 09:48, 19 January 2018 (UTC)[reply]
  • Either of those seem fine to me; the wording of the second is a bit clearer (e.g. what would "exist" really mean in the first?).  — SMcCandlish ☏ ¢ 😼  00:05, 20 January 2018 (UTC)[reply]

 Done. I've added both sets of wording suggested above, mine (amended) in the normal disambiguation instructions, and User:Netoholic's in the additional disambiguation instructions. It seems to make sense this way, but it may still need a tweak. --woodensuperman 10:22, 30 January 2018 (UTC)[reply]

  • Comment - I have reopened this RfC. It was started by Woodensuperman who also voted in it. It's highly inappropriate for him to close the RfC early. Closing should be done by somebody who was not involved in the discussion unless all participants agree to close it early. --AussieLegend (✉) 18:33, 30 January 2018 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.

Pruning/blanking abandoned very bad articles

As the encyclopedia grows, we have increasingly many articles started but abandoned in essentially useless state (unstructured, no context, hopelessly bad writing, no sources, etc). Some remain that way for years - someone tags them for cleanup, but no-one is interested enough to make a go of it, or doesn't know where to start. We have 9000+ articles in Category:Cleanup_tagged_articles_without_a_reason_field (3000+ tagged for at least 8 years) and 4000+ in Category:Wikipedia_articles_needing_rewrite. There's currently a WP:ANI discussion about one user who's been trying to delete such articles, leading to acrimony since others note the article topics meet the notability bar, that sources are available, but no-one adds the sources or fixes the actual article.

I'd like to get away from the user-conduct-focused discussion/arguing at ANI and see if we can find a better solution to the underlying policy issue, which several others there seem to think is indeed a problem. Testing the waters here if people would be supportive of one of the following, or an improvement thereon. If the discussion goes somewhere, can take to {{rfc|policy}} after sorting out the details.

  1. Speedy-delete. Create a CSD to allow speedy-deleting such articles, under some sort of stringent conditions, e.g. tagged for ["major"?] cleanup and no substantive edits for [3+?] years, no or woefully inadequate sources provided.
  2. Discuss-delete. Don't allow CSD, but change deletion policy to explicitly allow deleting such articles, with reasonably stringent guidelines as above to prevent abuse or false urgency/brinksmanship. Hope that at least some of the time, someone in the AFD discussion will instead jump in to improve the article.
  3. Blank. Don't delete such articles, but replace them with a template like "A Wikipedia article with this title was started, but was abandoned before a usable article was developed. If you feel this topic is notable, we encourage you to create an article using reliable sources. Previous partial content is available in this page's history if useful." Remove from generic cleanup categories. This blanking action could either be allowed as a matter of editorial discretion (Editorial-Blank), again with some guidelines to avoid overuse, or only as a soft-delete outcome of an AFD discussion (AFD-Blank).
  4. Flag. As Blank, but keep the existing article content, just preface it with an editnotice, something like "This Wikipedia article has been abandoned in a state which may be of limited usefulness. Wikipedia is a collaborative encyclopedia; if this topic is of interest, we strongly encourage you to dive in and improve it, using reliable sources."
  5. And of course, Status quo. There's no problem, leave such articles as-is in the hope someone will improve them, and continue to Keep them if someone nominates them AFD, etc, provided the subject is notable and sources appear to exist, etc.

The Speedy-delete option would of course the swiftest at removing embarrassing, useless stuff, but essentially gives up on the tiny ray of hope someone will improve things. It would require the most stringent, bright-line conditions on where it could be applied to be developed. Discuss-delete would harness multiple pairs of eyes to verify, and perhaps productively force a discussion of "OK, are we going to fix this or not?". The remaining two options keep the so-called content available, caveat it for readers, yet encourage someone to sometime jump in, and reclassify the cleanup backlog to segregate out articles where realistically normal cleanup isn't going to be sufficient or even happen.

Thoughts? ​​​​​​​​​​​I will mention this at the ANI thread and am pinging ~10 top commenters there of this discussion (but let's keep user conduct out of it!). Martinp (talk) 16:55, 20 January 2018 (UTC)[reply]

  • I'm opposed to "blanking" a page as it will still be indexed, be a blue link, etc. What I don't see above would be something like "send it to Draft:" (which could be an AFD outcome anyway) that could be useful? — xaosflux Talk 17:02, 20 January 2018 (UTC)[reply]
  • I think the status quo is probably the right play. Even really crappy articles sometimes have something of merit, or they point to the need for an improved article on the topic. Those that don't meet notability criteria are subject to deletion already; no great need for a CSD criteria, which would be potentially controversial as as enabler of ultra-deletionism by a handful of rogue administrators — just tote them to PROD or AfD as appropriate. The cure appears worse than the illness, from where I'm sitting... Carrite (talk) 17:06, 20 January 2018 (UTC)[reply]
  • Number 5 (status quo) as first and only choice. Anything that allows any driveby editor to unilaterally declare something as "very bad" will just mean a re-run of the current problem in an ever more virulent form since what you consider "very bad" isn't necessarily what I consider "very bad", and the existing of maintenance tags isn't necessarily actually indicative of a serious problem with the article. Anything that requires a consensus before something is flagged as "very bad" would just create an additional layer of bureaucracy replicating AfD. Despite the people who claim otherwise, "this article is terrible and will never be improved" is regularly accepted as a deletion rationale; the current issue is regarding an editor who's been tagging legitimate articles and lying about the non-existence of sources, not with the WP:TNT approach per se. ‑ Iridescent 17:06, 20 January 2018 (UTC)[reply]
  • Status quo--The project has no deadline.As simple as that.By the way, I will concur with Iridescent that TNT is quite used as a successful deletion rationale but the case at ANI differs by a mile.Winged BladesGodric 17:12, 20 January 2018 (UTC)[reply]
  • As has been shown in recent AfDs, many of these articles are about notable topics, are easily fixed with a little effort, and many could not be described as 'essentially useless'. The best approach in these cases is to encourage good editors to attempt to improve them, and nominate them for deletion only if the articles are genuinely unsalvagable. So basically the status quo, but with greater efforts to get them fixed. --Michig (talk) 17:13, 20 January 2018 (UTC)[reply]
  • Oppose It is explicit policy that "Perfection is not required: Wikipedia is a work in progress. Collaborative editing means that incomplete or poorly written first drafts can evolve over time into excellent articles. Even poor articles, if they can be improved, are welcome. ..." Nupedia had the different idea of only publishing polished and reviewed work but that was not successful and so was abandoned. Wikipedia works and so its successful methods should be left alone. Andrew D. (talk) 17:14, 20 January 2018 (UTC)[reply]
  • Any such change to the status quo is incompatible with the very foundation Wikipedia is built on and cannot work. Wikipedia is a constant work in progress, with no article ever being perfect and that's what makes the project great. It's also, as 2Q points out, the main reason people actually start to get involved: They come here, see that something does not exist or lacks information and they add something. We can't force anyone to actually work on those articles the OP mentions but every single one of them might a) be useful to someone already and b) might get someone to fix it. I understand that there are a few editors who believe Wikipedia should work radically different but that would probably also be its demise (it#s basically what Citezendium tried and we do have an article about how they failed miserably). Regards SoWhy 17:38, 20 January 2018 (UTC)[reply]
  • There is one (and as I see it ONLY one) advantage to outright deletion ... any existing links to the article will become redlinks. Redlinking will highlight the need for someone to start over and create a new (better) version. Blueboar (talk) 18:03, 20 January 2018 (UTC)[reply]
    ...until the next well-meaning editor comes along and starts removing the red links... Regards SoWhy 20:28, 20 January 2018 (UTC)[reply]
    Removing red-links can be done in two ways: (1) removing the wiki-code to leave the potential article topic unlinked; (2) creating a small stub that doesn't get expanded (i.e. turning the red-link blue). I have never quite worked out which is worse, but there is definitely an effect where people rise to the challenge of a red-link and create good articles from scratch. For some reason, the motivation seems to diminish when expanding a stub (well, for some people, some are just as happy expanding a stub as they are creating a new article). Maybe find a way to motivate people to work on permastubs? I am sure there have been editing drives along those lines. Iridescent is right to keep making the sewage analogy, but is there any way to work out whether Wikpiedia (or rather, the small part of it any one person sees at any one time) is a delicately fertilised field with blooms springing up here and there, or a fetid, steaming mess with some diamonds gleaming in the murk? Carcharoth (talk) 23:02, 21 January 2018 (UTC)[reply]
  • Comment- recently I have been cleaning up and categorising articles about tiny villages in India, which is indisputably some of Wikipedia's worst content. They've frequently got no sources at all and are riddled with such strained grammar and so many misspellings it can often be impossible to decipher what the sentence is trying to say. Many contain advertisements for local tourist attractions, travel blog entries, gushing hagiographies of non-notable local residents, and attempts by article editors to communicate with each other by asking each other questions in the article space. Often there's nothing to be done but aggressively prune them back such that all the content that's left is "Such-and-such is a village in Foobarbaz state, India". It's a lot of work. A lot of work. Yet none of them so far have had no salvageable content. So I'd say there's an option missing from your list, @Martinp: allowing editors very wide freedom to aggressively remove crappy content from articles. Reyk YO! 18:12, 20 January 2018 (UTC)[reply]
    • ​Even the worst of those "Boggley Wollah is a village in Foobar Province, men are brave and women are beautiful and virtuous, is 12 km from railway and have electric light" Indian village stubs still serves some useful purpose, since if nothing else they tell readers where the place is, and generally include at least some kind of external link to the local government website. It's actually vanishingly rare for a non-vandal Wikipedia article to be useless to the reader; where WP:TNT comes into play is when the answer to "would people Googling this topic genuinely be better served if this page didn't appear in the search results, and it is unfeasible for it to be improved to the point where that's no longer the case?" is unambiguously "yes". ‑ Iridescent 18:50, 20 January 2018 (UTC)[reply]
Stubifying is definitely an option - just replace the text with a source line (to say the census) that the village exists and has such an option. Galobtter (pingó mió) 18:55, 20 January 2018 (UTC)[reply]
WP:ATD already mentions reducing something to a stub as an alternative to deletion. Yet people mostly ignore it, just as many ignore ATD altogether. Regards SoWhy 20:26, 20 January 2018 (UTC)[reply]
I do what Reyk does. Sometimes I get kickback for it but I have a fairly thick skin. However, the Indian village articles (and indeed those across the subcontinent) specifically have some other issues, notably a lot lack coordinates and they have so many variant transliterated spellings that it is nigh-on impossible to locate them. That is when AfD should come in but, alas, the usual people will turn up with the usual argument, ie: place of habitation, therefore keep. - Sitush (talk) 19:33, 20 January 2018 (UTC)[reply]
I haven't had anyone scream at me for my extensive pruning yet. But I also know that if I take them to AfD (even the ones where I can't verify if they exist) it'll be "keepkeepkeep! habited place!" with possibly "block nominator for disruption" thrown in. But I can do something about the travel guides and silly comments about local inhabitants. Reyk YO! 19:58, 20 January 2018 (UTC)[reply]
A few years back when I was working on the inhabited places of Ethiopia, I sent a few to AfD & managed to get those articles removed. While it is difficult to prove a given village or hamlet in a country like Ethiopia or India does not exist -- & the problem with Ethiopia is multiplied due to bad maps & numerous variant spellings -- I was able to do it using some reliable sources. (Citing Google Maps as showing nothing there ought to be a clincher.) While I consider myself an inclusionist, & we should never lightly delete articles, IMHO when sufficient research has been spent on showing such a place does not exist, deletion really is the proper solution. -- llywrch (talk) 17:58, 22 January 2018 (UTC)[reply]
  • Oppose any changes along these lines. I totally get where User:Martinp is coming from on this, but articles that aren't in great shape are often a great source of new editors for Wikipedia. Many of our existing ,well-sourced, well-written articles can be very intimidating for a new editor to approach because of the use of complex templates, hundreds of sources, the application of a wide range of MOS guidelines, etc. etc.... three of the oldest articles that is tagged cleanup without a reason are List of Ranma ½ video games, Canadian Radio-Television Commission and Punk rock in Spain. I doubt any substantial support would be found for deleting these articles simply because they have a cleanup tag and need some work. Someday, someone will show up to do more work on these... might be this year, might be 2025. Who knows. What I do know is that our standard AFD process works fine for getting rid of unsalvagable articles. We don't need to employ speedy deletion for this sort of thing. In fact, doing so would be a violation of WP:CONS. — Warren. ‘ talk , 18:17, 20 January 2018 (UTC)[reply]
  • Comment The problem is real and many of these little village articles have BLP violations as well as the other problems discussed. But I think User:Galobtter's answer is best, stubify them or take them to AfD. Doug Weller talk 19:21, 20 January 2018 (UTC)[reply]
  • Oppose current policy allows for easy removal of unreferenced material and stubbing if necessary. Cas Liber (talk · contribs) 20:36, 20 January 2018 (UTC)[reply]
  • Flag might be a good idea and give new editors something to test their teeth on rather than have them create new non-notable trivia to prove themselves. Xxanthippe (talk) 21:31, 20 January 2018 (UTC).[reply]
  • Strongly support pruning, but ... I'm not sure people realize how bad some of our articles are and how many of them there are. It's very likely that we could use purely mechanical criteria to select the worst 5% of our articles and 99% of our readers and editors would say that these articles are useless to them. 5% of 5.5 million is over 275,000 articles, much too many to benefit from AfD or the other labor intensive methods discussed above. Just to give folks an idea of these types of articles, I I hit the "random article" button about 50-60 times and selected the following:
I intentionally did not include articles on officially recognized geographical places, species, and sports people, who likely have supporters of even the shortest articles in such a series. I think some of the included articles (e.g. the 1902 film) might be worth being in the encyclopedia, but I wouldn't want to take more than 10 minutes to review it. That would take 46,000 editor hours for the 275,000 articles.
So how to select the articles for review. The mechanical criteria could include articles than have *all* the following
  • article length (say less than 4 sentences or xx words)
  • page views (say less than 2 per day)
  • last substantial edit by a human (i.e. not a new category or spelling correction) older than, say, 2 years.
  • less than 2 inline refs
  • ORES score, say 90%+ prediction that the article is a stub (see https://ores.wikimedia.org/ui/ )
So get the bottom 1% of the articles. In many cases (50%?) it should be a speedy merge of perhaps 1 line, with a redirect, e.g. Bass sarrusophone into Sarrusophone. It would be nice to have a special Prod that couldn't be removed unless you actually improve the article. That might cover 30% of these articles. So maybe 20% would need special consideration that would actually take more than 10 minutes. Then move on to the next 1% if everybody is happy Smallbones(smalltalk) 22:35, 20 January 2018 (UTC)[reply]
  • This is not actually a bad idea in principle, except for one flaw: Then move on to the next 1% if everybody is happy. Has everybody ever been happy here? - Sitush (talk) 01:20, 21 January 2018 (UTC)[reply]
  • 1% is still 55,000 articles. If ten of us addressed 10 of these every day, it'd still take a year and a half. This isn't a process that can be truly automated, especially if you want to contemplate merging articles together. — Warren. ‘ talk , 01:28, 21 January 2018 (UTC)[reply]
My main point above is that we have to semi-automate it, or just leave all the garbage in. Humans are only needed to save the acceptable stuff - but having any discussion would just take too long on the very worst stuff. Merging Bass sarrusophone into Sarrusophone could be done in 10 minutes. Slapping a sticky prod onto Euskaltegi would only take a few minutes to find that there aren't any non-Wikipedia, non-commercial sites to reference. The lost 1902 film might be worth taking a bit more time to see if anything other than crowdsourced sites have anything about it - the crowdsourced sites don't. At some point, it's got to be do something with it (at least 10 minutes worth) or chuck it asap. The mechanical methods would give you the "at some point". Smallbones(smalltalk) 05:13, 21 January 2018 (UTC)[reply]
Re If ten of us addressed 10 of these every day, it'd still take a year and a half.

'If seven maids with seven mops
Swept it for half a year,
Do you suppose,' the Walrus said,
'That they could get it clear?'
'I doubt it,' said the Carpenter,
And shed a bitter tear.

– Lewis Carroll (1872), "The Walrus and the Carpenter", from Through the Looking-Glass, and What Alice Found There. See also Sisyphus. --Redrose64 🌹 (talk) 10:28, 21 January 2018 (UTC)[reply]
Can we have that as the Wikipedia disclaimer? :-) Carcharoth (talk) 23:04, 21 January 2018 (UTC)[reply]
  • Oppose I would probably just stubify - I think it's good to leave a stub for editors who like to develop stubs. Some of the articles above like Aliens are to Blame for Everything or Christodoulos Neophytou could probably be deleted through AfD, but it's a notability issue more than an article-quality issue. For poor quality articles that are notable I think it is preferable to have a stub instead of a redlink. SeraphWiki (talk) 02:08, 21 January 2018 (UTC)[reply]
    ...which is already policy and has been for for years now. Sometimes people are trying to re-invent the wheel instead of simply following policy. I dare say any messy article about a notable subject that people argue to WP:TNT, could be reduced to a stub instead; we just need people to do it. Regards SoWhy 15:43, 21 January 2018 (UTC)[reply]
  • Improve. Nobody's suggesting edit and improve incomplete articles about notable topics? For a start, we could apply the time used on this discussion, and time wasted on AfDs for notable and verifiable subjects just because Wikipedia:I just don't like it. Be Wikipedia:Here to build an encyclopedia, Wikipedia:Don't demolish the house while it's still being built. Jack N. Stock (talk) 05:57, 21 January 2018 (UTC)[reply]
  • Thanks for the feedback! To be honest, I'm a bit surprised so many people think there is no problem. We do have lots of basic stubs that are mildly helpful and someone will hopefully expand them, but we also have lots of abandoned stuff which is really not usable in its current state, and it's pretty clear essentially no one has the ability/interest to improve it and feels it is worth their while. It's nice to say "eventually someone might fix it" or "why don't *you* try fixing it rather than just destroying stuff", but we can't force people to volunteer to fix stuff they're just not interested in. However, it's pretty clear there's little support for any of the proposals I suggested. I do think the discussion about when to stubbify and WP:ATD is a useful one, and perhaps provides a good framework for some articles (and requires no change to policies). Anyway: leaving open for a while longer (not everyone is on WP every few hours!)... Martinp (talk) 12:06, 21 January 2018 (UTC)[reply]
    • ​Don't be too surprised. Remember that you're talking to an audience who by-and-large remember the competition between Wikipedia and Citizendium; we have empirical evidence when it comes to whether "the sewage fertilizes the flowers" or "weed out the dead wood" is a more productive approach over the long term both in terms of article production, and in terms of editor retention. Wikipedia's policies sometimes appear arbitrary, but—especially for something fundamental like deletion—they're generally the result of years of watching what works and what doesn't, so we're typically reluctant to change core policies unless there's an extremely good reason to do so. ‑ Iridescent 13:12, 21 January 2018 (UTC)[reply]
  • Improve. the community is trying to get away from giving deletion editors any tools.--Moxy (talk) 14:51, 21 January 2018 (UTC)[reply]
  • Oppose, the day we abandon constructive policies such as WP:PRESERVE or WP:ATD, or principles such as WP:DEADLINE, is the day I abandon Wikipedia. I'd say status quo, but at present we already have far more misuse of AFD than we should to stifle articles that can be fixed, or to address what are really editing problems, such as what to do with subpages of undeniably notable topics or articles that have been WP:SPLIT. postdlf (talk) 15:09, 21 January 2018 (UTC)[reply]
  • Pruning is good, but do it with care. See William Whitfield for an example (see article history and the talk page). The process of deletion and recreation does already happen, specifically for the case of articles that get prodded and when copyright violations are deleted. An example here is Patrick Forrest (see logs). This article was first created about someone else of the same name and deleted by the prod process in June 2006. An article on the surgeon was created in May 2017 and deleted due to the aftermath of a sockpuppetry case. The current article was created in June 2017. I suppose the question is whether the deletions made any difference to the ultimate outcome? It looks like it didn't. Carcharoth (talk) 23:16, 21 January 2018 (UTC)[reply]
  • Status quo plus per User:Postdlf. I am particularly alarmed by the comment by User:Smallbones because he seems to target stubs about "ethnic" things like a Serbian film or a Kazakh sports body, which are certainly notable. Providing readers with a basic link to those things is obviously useful, and if the articles don't do anything else, so what? If we had a better geographic representation they would not stay stubs for long. And we're not going to get that by arbitrarily deleting articles for being too short, knowing what bias that is enforcing! Wnt (talk) 02:11, 22 January 2018 (UTC)[reply]
  • Comment First, the number of articles the OP is concerned about amount to less than 0.1% of the total number of articles. In short, we're discussing what amounts to a rounding error, so in the larger picture we will always have a few thousand problematic articles like these; the "status quo" is a defensible option. On the other hand, something needs to be done about these articles; there are too many articles marked as stubs. (In my experience, as many as a quarter should be upgraded to "Start" or better.) If we had more active WikiProjects, we could simply leave the problem of abandoned very bad articles to those groups to either improve these articles or nominate them for deletion: those group would have the experts who could handle them quickly. Perhaps there should be a competition to encourage dealing with this backlog. (FWIW, currently I am reviewing a number of articles -- maybe as many as 100 -- that were created by a banned user that may be hoaxes. So I am working on this problem from my own direction.) -- llywrch (talk) 17:58, 22 January 2018 (UTC)[reply]
  • Status Quo (5) as first option. Flag (4) as second option; though an additional flag over all the crap we current tag such articles with is probably of marginal additional utility, so the more I think about it, the more 5 seems the best option. I am unconcerned with substandard articles, all of Wikipedia is substandard to some degree, and I don't see what we gain by deleting some number of articles below some arbitrary quality limit. --Jayron32 20:26, 22 January 2018 (UTC)[reply]
  • Flag. Cleanup tags get the reader's attention and help encourage involvement. KMF (talk) 01:42, 23 January 2018 (UTC)[reply]
  • Draftify. These articles are essentially drafts. Move them to draft space and if an editor wants to improve them, they can. If they are garbage, they can be deleted. Natureium (talk) 15:04, 23 January 2018 (UTC)[reply]
  • Comment I think that either drafting or flagging is a better idea. The problem with flagging is that it might be prone to drive-bys. Why do you think {{cleanup}} has a ten-year backlog? Because people just slap the tag on without explaining what needs cleaning up. Adding a "reason" field has done very little. Pruning and stubifying may help, but it may also leave the content vulnerable to unwarranted A7s. Ten Pound Hammer • (What did I screw up now?) 23:45, 23 January 2018 (UTC)[reply]
  • Flag (4) as first option and Status Quo (5) as second option. I concur with Xxanthippe on the testing ground idea; at least this would give incentives for new editors (especially those under mentorship programs like Wikipedia's "Adopt a User") to learn how to find sources and fix an article by being at the field. However the fact that Wikipedia has no dead lines should be stressed on the flag too as we don't want the pace to go unhealthily tight. But if that is unfeasible then I'll opt for the status quo although the large troves of particularly those poorly-written-but-okay articles can still serve as a ground for those newbies to test their hands on which would prove immensely useful for WP:SUP. Even more better when the students/newbies learn about finding reliable sources in the process of the crowdsourced fix-up that would help them to not fall for such "FAKE NEWS" things; as a matter of fact Wikimedia-Deutschland was spot-on in this.14.192.208.93 (talk) 08:41, 24 January 2018 (UTC)[reply]
  • For things that merit deletion we already have prod, AFD, db-hoax and so forth, but we need to remember that deletion is not cleanup, and by driving editors away deletionism probably does more harm than good. As for cleanup tags, yes there is a problem, but is it that some cleanup tags persist for a long time or that some people think their time is better spent adding cleanip tags rather than actually improving articles? I'm very much of the opinion that if we could steer a few hundred hours a year of the time that is spent template bombing articles into improving articles we wouldn't just be making Wikipedia a better quality encyclopaedia, we would be educating newbies by example instead of biting them and driving many away. Up until template bombing replaced the previous "SoFixIt" philosophy circa 2007 this site was steadily recruiting new active editors and the community was growing. Subsequent to that the community declined for several years before stabilising three years ago at around 5 million edits a month. If we want to speed up the rate at which articles like those improve I suggest we turn most of the maintenance templates into hidden categories and try to get back to the "soFixIt" culture of the years of our exponential growth in editors. ϢereSpielChequers 09:30, 24 January 2018 (UTC)[reply]
  • Status quo. Yeah, there's a lot of garbage out there. I admit that I PROD/AfD a solid 30% of articles that I come across when I dive into CAT:ORPHAN. But there's also a lot of really interesting stubs that turn out to be ripe for expansion! It would be a huge loss if we just tossed the baby out with the bathwater. ♠PMC♠ (talk) 23:59, 24 January 2018 (UTC)[reply]
  • Status Quo the suggested changes are too broad and would sacrifice potentially good articles, and automating deletions would be undesirable as human involvement is needed for careful assessment of the value or lack of value of articles Atlantic306 (talk) 13:36, 29 January 2018 (UTC)[reply]

Require all templates to have appropriate disambiguation parameters and documentation

Frequently, templates are built on the assumption that there all pages on a certain topic will conform to the same title scheme, with no ambiguities. However, reality is not that forgiving. Editors therefore come across numerous instances where a template has been constructed that automatically fills in fields by adding an incorrect expected value to article names. Sometimes these links are just wrong. Sometimes these are links to disambiguation pages. An example that I have recently come across is Template:International football competition statistics, which incorrectly assumes that every article on the men's national soccer team for a given country will be at "Foo national football team", despite both United States national football team and United States men's national football team being disambiguation pages, due to the prevalence of American football in the United States. A contrary example (where the disambiguation parameter is done right) is Template:Sortname, which has a clearly delineated "|dab=" parameter for introducing a disambiguating term.

Complicated templates can easily generate errors that are hard for even seasoned editors to find and fix. I therefore propose that every template that has a parameter that can potentially call an incorrect page should have

  1. either a clear disambiguation parameter such as "|dab=" or "|link=", or an "#IFEXIST" function that allows an editor to override the parameter by filling it in with a piped link (e.g. [[Correct link target|Desired display text]]
  2. a "Disambiguation" section in the template documentation page demonstrating how link fixes can be implemented.

I don't think that it is too much to ask that template editors employ existing common solutions to avoid pervasive errors. bd2412 T 22:50, 23 January 2018 (UTC)[reply]

At {{Stnlnk}}) I coded an "#IFEXIST" tree that goes through all the disambiguation forms for railway stations (from most- to least-common) to automatically find the correct page. This makes it completely transparent to the user, and after three months I have yet to hear any complaints. Useddenim (talk) 23:49, 23 January 2018 (UTC)[reply]
Oooookayyyyy then - see User talk:Jc86035#Disambiguating Broad Street and User talk:Certes#Disambiguating Coniston. Two users WP:SUBSTing {{stnlnk}} in order to dab the link. --Redrose64 🌹 (talk) 23:56, 23 January 2018 (UTC)[reply]
I am not calling out particular templates here. I cited Template:International football competition statistics solely as an example, but I am proposing that this should be a standard for ALL templates that can potentially call a wrong link due to natural inconsistencies in article titles. bd2412 T 23:59, 23 January 2018 (UTC)[reply]
  • Simple solution.... don’t use the template. Blueboar (talk) 11:44, 24 January 2018 (UTC)[reply]
    • Templates are useful shortcuts for a great deal of formatting, and I don't want do discourage their use for that purpose. I only want them to be made with reasonable editing solutions in mind. Also, "don't use the template" is not a solution for editors visiting a page where a complex template is already in use, and only needs a fix. bd2412 T 12:45, 24 January 2018 (UTC)[reply]
  • So, the more important question we ask is what do we do if they don't. Any proposal of this nature has to be enforceable, if it isn't, it might as well not exist. If the only answer to "what do we do if they don't?" is "we just fix it", then you can do that now. No one is stopping you from making the world better. And I don't really feel like blocking good-faith editors over a matter such as this! If we're not going to enforce this with consequences for not doing it, what's the point? WP:SOFIXIT exists for a reason, you know: being a volunteer organization, we can't make people do anything. All we can do is fix what we want to fix, we can't make anyone fix something they don't want to fix. --Jayron32 13:40, 24 January 2018 (UTC)[reply]
    • WP:SOFIXIT is of little use to the typical editor confronted with a complex template that generates errors. Is it preferable to perpetuate these errors? bd2412 T 14:24, 24 January 2018 (UTC)[reply]
      • You missed the point of my comment, so let me restate it again: What are you going to do to template editors that do not do this? Are you really going to ban them from Wikipedia? That seems ridiculous and draconian. If you don't have a consequence for violating a policy, then you don't have a policy. You have nothing. If you want to write some guidance in the form of "here's some good ideas when writing a new template", by all means, no one here will stop you, but do you honestly expect to create an enforceable policy that will have actual consequences for violations? --Jayron32 16:14, 24 January 2018 (UTC)[reply]
        • I have not proposed any consequence. However, I would like template editors to have these issues in mind when they begin to construct templates. I consider this comparable to an editor making articles without reliable sources. If someone starts doing that, we usually point out to them that there is a policy requiring sources, and ask them to edit their articles to fix the deficiency. It is very rare that an editor who has been informed of this requirement will continue to make unsourced articles, so we have to get through several of problems before we need to worry about addressing intransigent behavior. If an editor starts making templates written in such a way that they tend to introduce errors, I think the same course of action would apply. bd2412 T 17:19, 24 January 2018 (UTC)[reply]
  • Have you had any pushback attempting to add this parameter to a template? If so, can you given an example? Creating a guideline (there is snow chance this is going to make a policy) that templates "should" allow this syntax isn't going to make it happen - and we're not about to start deleting templates solely due to a lack of this switch. — xaosflux Talk 15:42, 24 January 2018 (UTC)[reply]
    • Rarely, but my concern is that we not get to the point of an editor making a help request at WikiProject Disambiguation saying that they have spent 20 minutes trying to figure out how to fix an error, and can't penetrate the template. Bear in mind that many of these templates are not merely a single template, but a string of templates or modules that call different subtemplates depending on how they are filled out. bd2412 T 17:22, 24 January 2018 (UTC)[reply]
  • It seems to me that the first step here is documentation -- first make a guide that explains how to do what you want correctly. Later on, if it needs to become a guideline, that can be discussed at this point. But the heavy lifting of documenting seems uncontroversial and does not require community consensus. CapitalSasha ~ talk 18:32, 24 January 2018 (UTC)[reply]
    • That would be a good start. I'm not sure if it is possible, but it would be nice to get a list of templates that generate links from plain text, and which do not have documentation explaining how to disambiguate or otherwise make a direct link to a different title. bd2412 T 19:25, 24 January 2018 (UTC)[reply]
I have spent a lot of time recently deciphering templates (and in some cases Lua) to deduce what inputs would cause those templates to produce the desired output. I know others such as Narky Blert have done so too. I would certainly welcome easily found parameters such as link=. I'm certainly happy to help with the implementation, so I hope any discussion of sanctions for not providing them is moot.
The times I've deliberately replaced a template call by a raw wikilink are in single figures. The example Redrose cites was based on my misunderstanding of a tool. I've searched for such accidental edits and found only about a dozen by myself and another dozen by other editors, which I've updated to use templates. Certes (talk) 01:43, 1 February 2018 (UTC)[reply]
  • Agree and then some. 'Nuff said.
User:Certes flatters me. I know nothing about templates – except for the dozen or so where I've managed to work out how to fix the links they create to DAB pages. Otherwise, all I do is try to kick up a stink when a template creates a bad link which I haven't the first idea how to fix. Bad coding, incomplete documentation, lack of dab fields, etc. = same result – useless links in Wiki which confuse readers, annoy WP:DPL members and waste their time, and (most importantly) are bad for the encyclopaedia. Smug answers from template "owners" spelling out the "obvious solution", or saying "don't break the template formatting by adding {{dn}}" are singularly annoying (I've had several of those). Narky Blert (talk) 02:18, 1 February 2018 (UTC)[reply]
My 4-step procedure:
(1) Try [[Precise target|ambiguous target]]
(2) Try Precise target{{!}}ambiguous target
(3) Read the documentation
(4) If the documentation is not immediately intelligible, {{dn}} flag the sucker. I have other things to do.
Narky Blert (talk) 02:36, 1 February 2018 (UTC)[reply]

Official facebook page

There seems to be a disagreement between LovelyLillith and me at Judith Newman. They removed a link to the FB page of the subject of the article and started edit-warring when I reverted, so that I had to go myself to the talk page. They seem to believe that WP:LINKSTOAVOID universally prohibits links to FB (citing #10 and #11). They do not seem to be succeptible to my arguments that the first line of this guideline excepts the links to official pages, and that a FB page controlled by the subject conforms with the definition of the official page at the same guideline. At this point we are deadlocked, and more opinions are welcome at Talk:Judith Newman#Facebook page reference. Thanks.--Ymblanter (talk) 08:33, 25 January 2018 (UTC)[reply]

This should be at WP:ELN. I see no useful information at the page. Johnuniq (talk) 08:40, 25 January 2018 (UTC)[reply]
I am afraid WP:ELN is dead. I tried to use it in the past, I never got any response.--Ymblanter (talk) 08:51, 25 January 2018 (UTC)[reply]
Not particularly dead. WP:ELNO does grant allowance for an official page per the bolded statement at the top of the section (subject to WP:ELNEVER). However, WP:ELOFFICIAL defines an official page; there are two items that the page must meet: 1) She, or someone of her obvious choosing, controls the page (she does); 2) "The linked content primarily covers the area for which the subject of the article is notable." It is this second criterion which I am doubtful of--the page appears to be her personal page, not one which is dedicated to her topic of notability, that is, her journalism. If there is a dispute here, I would resolve whether the second one meets the intent of ELOFFICIAL. --Izno (talk) 13:08, 25 January 2018 (UTC)[reply]
Yes, but my understanding is that journalists routinely use FB as public figures, and she is writing about everything. Anyway, it seems like there is a page which is kind of official, if there have been no protests I am going to add it tomorrow on the webpage. The question is more broad though, we have {{Facebook}} with plenty of transclusions. The argument of LovelyLillith, which I believe to be incorrect, means that all of these transclusions must be removed (and the template deleted).--Ymblanter (talk) 14:46, 25 January 2018 (UTC)[reply]
I would agree that the edit summaries are oddly terse if not decidedly incorrect. Perhaps Lillith can elaborate on the specific meaning of those summaries. --Izno (talk) 15:42, 25 January 2018 (UTC)[reply]
Based on what she wrote below it is probably not going to happen.--Ymblanter (talk) 06:44, 26 January 2018 (UTC)[reply]
Is this Wikipedia:External links/Noticeboard#Face Book what you meant by it being dead? Emir of Wikipedia (talk) 14:53, 25 January 2018 (UTC)[reply]
This one as well, yes.--Ymblanter (talk) 14:55, 25 January 2018 (UTC)[reply]
It looks like I have never posted there, and I must have confused it with WP:RSN. However, that one does not seem dead as well. Now I do not know anymore. I remember I had a bad experience with one of those.--Ymblanter (talk) 14:59, 25 January 2018 (UTC)[reply]
The matter seems to have been settled agreeably on the Talk page of the article in question, by the suggestion of using http://www.judithnewman.com as her "official website" instead of the FB page. Accusing me of edit warring to our peers instead of WP:AGF, particularly on such a minor point, can be construed as WP:OWNERSHIP, even if that is not the intention. LovelyLillith (talk) 23:48, 25 January 2018 (UTC)[reply]

RfC: All Wikipedia articles should have infoboxes (straw poll)

Withdrawn by initiator per the objections below. Just to note: the goal was in no way nefarious, simply an attempt to get a "sense of the community", but I accept that the community doesn't think the format is conductive to that. I leave it up to others to forumulate an RfC which will do that, if that goal seems worthwhile. Beyond My Ken (talk) 04:51, 28 January 2018 (UTC)[reply]

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

Should all Wikipedia articles have infoboxes? Beyond My Ken (talk) 00:42, 28 January 2018 (UTC)[reply]

All Wikipedia articles should ideally have infoboxes, with the exception of those so short (i.e. "sub-stubs") that the infobox would simply be repeating the entire content of the article.

  • Comment by initiator of RfC – The purpose of this RfC is to use a straight up-or-down vote to determine the sense of the Wikipedia editing community towards infoboxes. Please do not complicate it or muddy the waters by adding additional proposals to it. I have not provided a "Threaded discussion" section because discussing infobox philosophy is not the purpose of this RfC, which is deliberately a blunt instrument, a "straw poll" designed to return a general fact: whether the community numerically supports or opposes the ideal that all articles should have infoboxes. I ask you to please respect the purpose of the RfC. Beyond My Ken (talk) 00:42, 28 January 2018 (UTC)[reply]
    • Beyond My Ken, it sounds like you're hoping that people will reply with the item that most closely matches their personal view (which is fine), but how do you want people to respond if they want infoboxes on nearly all articles? If someone wants to see infoboxes on, say 95% or 99% or articles, do you expect them to "support: (almost) all" or as "oppose: definitely not all, because there should be a small number of exceptions"? WhatamIdoing (talk) 00:54, 28 January 2018 (UTC)[reply]

Support: I agree; ideally, all articles should have infoboxes

  1. Support Chris Troutman (talk) 01:06, 28 January 2018 (UTC)[reply]

Oppose: I disagree; I do not think that all articles should have infoboxes

  1. - Lourdes 00:56, 28 January 2018 (UTC)[reply]
  2. Oppose though I would support the proposal that all non-stub biographies should have infoboxes. There are too many exceptions for this rule to be feasible. Many pages on general concepts use navigation templates instead of infoboxes (e.g. History of India), abstract concepts (Mind) have no obvious content for an infobox, and lists almost never have infoboxes. power~enwiki (π, ν) 01:01, 28 January 2018 (UTC)[reply]
  3. (edit conflict) This is a false dichotomy if I've ever seen one but mkay. Do I think that "all" articles should have them? No. Do I think that there are a vast number of articles that would benefit from one? Sure. They are helpful for our readers to get a quick overview of the article they are reading. --Majora (talk) 01:03, 28 January 2018 (UTC)[reply]
  4. I think this is the wrong question. There are several topics that do not (ETA) need infoboxes at all (for example one of my own, Loot box, doesn't fall into any infobox usage). But taking the question of where there are commonly infoboxes like for biographies of people, I also don't think we can force this, and it would be bad for WP to force it, even though personally I would love to see a standardized approach here. --Masem (t) 01:45, 28 January 2018 (UTC)[reply]
  5. Strongly oppose I don't think there's any reason not to continue current practice, which is that the consensus of active editors on a page determines whether an article has an infobox (unless somebody solicits additional input through an RfC). What would be the rationale for bureaucratic micromanagement of requiring every article to have an infobox? — Malik Shabazz Talk/Stalk 01:51, 28 January 2018 (UTC)[reply]
  6. Oppose to all, support whenever applicable. Renata (talk) 01:56, 28 January 2018 (UTC)[reply]
  7. Oppose as above. Xxanthippe (talk) 01:59, 28 January 2018 (UTC).[reply]
  8. Oppose They are not a "one size fits all" item. For one thing there are numerous articles (especially stubs) that do not have enough info in them to merit an infobox. MarnetteD|Talk 02:00, 28 January 2018 (UTC)[reply]
  9. Oppose. Sometimes they're useful and sometimes they're not. The argument I often see in favour of infoboxes is they can emit metadata that can be used by third parties, but I don't buy that for a second. Eric Corbett 02:03, 28 January 2018 (UTC)[reply]
  10. Oppose--what Eric says and more. Drmies (talk) 02:04, 28 January 2018 (UTC)[reply]
  11. Oppose per Eric. I like them where they make sense but "one size fits all" isn't a good idea here. Dennis Brown - 2¢ 02:14, 28 January 2018 (UTC)[reply]
  12. Oppose this poorly formulated RfC per power~enwiki. We have a serious problem with fiercely determined advocates on both sides of this issue, but imposing infoboxes across the board is not the solution. Cullen328 Let's discuss it 02:23, 28 January 2018 (UTC)[reply]
  13. Oppose as simply impractical. Many, many articles would not be compatible with infoboxes. {{Infobox MMA move}} on 12-6 elbow? {{Infobox historical journey}} on Charles I's journey from Oxford to the Scottish army camp near Newark? {{Infobox list of books}} on List of dystopian literature? What would be in an infobox on a list article? – Jonesey95 (talk) 02:38, 28 January 2018 (UTC)[reply]
  14. Oppose and recommend snow closing this. While I like infoboxes and believe that articles should generally have them if they're of an appropriate length, making them mandatory reeks of instruction creep. Some articles are so short that infoboxes are unnecessary (like stubs). Narutolovehinata5 tccsdnew 03:08, 28 January 2018 (UTC)[reply]
  15. If this were Encyclopædia Britannica, it might be suitable for an editorial board to rule that certain styles will be strictly enforced. That is not suitable at Wikipedia where collaboration requires getting on with people even when they think strange things. Johnuniq (talk) 03:10, 28 January 2018 (UTC)[reply]

Discussion

  • I hate the way this question is formulated, because I think the result of this discussion is going to be used as a weapon by those who wish to remove infoboxes from articles where they already exist by claiming that the results of this discussion support them. I can't vote either way on this because it presents as a binary option an issue which is far too nuanced. I really don't like this whole direction.--Jayron32 02:48, 28 January 2018 (UTC)[reply]
I share your concern, Jayron32, and certainly hope that this RfC is never used in that fashion. Cullen328 Let's discuss it 03:00, 28 January 2018 (UTC)[reply]
Anyone that uses a clearly false dichotomy RfC to advocate for their particular decision is doomed to fail if it was ever brought to the attention of the wider community. Most editors aren't that stupid. --Majora (talk) 03:02, 28 January 2018 (UTC)[reply]
Perhaps the nominator could withdraw this RfC and begin/continue a discussion about what sorts of articles should usually have infoboxes. There may be some consensus on at least some minimal guidance. – Jonesey95 (talk) 03:25, 28 January 2018 (UTC)[reply]

@Rschen7754: I think the OP is trying to propose that all non-stub articles should have infoboxes. Narutolovehinata5 tccsdnew 03:56, 28 January 2018 (UTC)[reply]

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

Criteria for inclusion in Births and Deaths sections of Wikipedia date articles

Per previous discussions over at Wikipedia talk:Days of the year, it seems that there is some level of support for some kind of inclusion criteria for what articles to include on the Births and Deaths sections. There are some concerns that these sections are too-Western centric (i.e. people from North America or Europe are over-represented).

The question now is: should we have some kind of guideline for inclusion in Births and Dates articles? Or is the status-quo fine? In my case, my pet proposal is that a proposed inclusion criteria would be similar to what's currently done at WP:DYK, where no more than half of each set can be about US-related topics. Though of course, other editors are free to propose other proposals here. Narutolovehinata5 tccsdnew 03:16, 28 January 2018 (UTC)[reply]

I agree with KMF that this is trivia. There is no possible way to develop an objective criteria for inclusion, and any volunteer time wasted on this would be better spent actually improving the encyclopedia. Cullen328 Let's discuss it 05:10, 28 January 2018 (UTC)[reply]
If you're reading the Wikipedia article about a particular day of the year, I would surmise that probably you are very much in the market for useless trivia! CapitalSasha ~ talk 05:18, 28 January 2018 (UTC)[reply]
With the exception of a few incidents which are frequently referred to by their dates (e.g September 11 attacks), or dates which represent holidays on the Gregorian calendar (e.g Storming of the Bastille, which is the source of Bastille Day), all data on date pages are trivia. I see no reason why it's any less trivia that the Titanic sank on April 15 than that the actress Emma Watson was born on this date. עוד מישהו Od Mishehu 07:59, 28 January 2018 (UTC)[reply]
  • The best option in my opinion would be to branch out "Born on ..." and "Died on ..." into separate articles (many of these lists online, but lots of misinformation, and none that are verifiable), maintained by bots and linked to on the DoY pages. This would reduce editor time spent to practically zero, does away with arbitrary inclusion criteria, and makes sure the info is still there for people who want it. The only objection that I've come across is that this could be done by category instead, but this makes it a nightmare to sort by year, and prevents the brief summary of what the people were notable for. ‑‑YodinT 12:19, 28 January 2018 (UTC)[reply]
  • I think the inclusion could be based on quality of linked articles. For example, limit inclusion to articles that have 500 words of pure prose and have no major clean up tags. Renata (talk) 14:44, 28 January 2018 (UTC)[reply]
That makes sense for a internal stuff...but that's not exactly an encyclopaedic inclusion criteria? That's the same problem with Narutolovehinata5's proposal - "than half of each set can be about US-related topics." is fine for internal inclusion, but not for an objective encyclopaedia. Galobtter (pingó mió) 14:50, 28 January 2018 (UTC)[reply]
Well, Wikipedia is mature enough that truly notable people generally have bios that are pretty decent. Of course, there are all kinds of exceptions and anomalies. But I think it would be very useful to have some sort of arbitrary criteria based on article quality to avoid lengthy discussions on who is more notable. Renata (talk) 03:56, 29 January 2018 (UTC)[reply]
In my view a notability criterion would be relevant, but that may be different from an article quality criterion. Many highly important people from (e.g.) the 18th century have short, underdeveloped articles, while many largely irrelevant sports or music (mainly US and UK) people from today have lengthy well developed articles maintained by fans. So a quality criterion developed along lines of development of article, would not solve the problem raised at the start of this post and in fact may even worsen it. Splitting off list of births and deaths on this date as Yodin suggests would not be perfect, but would at least largely solve the problem. This not in the least because such lists would allow much more entries, without overwhelming the rest of the entries on the day article (thus taking the sting out of discussion there). Arnoutf (talk) 07:11, 29 January 2018 (UTC)[reply]
@The Rambling Man: Wouldn't such list articles (assuming the sections get split, as proposed above by some users) end up being very long and potentially falling afoul of WP:IINFO? Narutolovehinata5 tccsdnew 13:15, 29 January 2018 (UTC)[reply]
Policy has nothing to do with it. It's too unweildy. As a quick Fermi approximation, Wikipedia has 5.5 million articles. If 10% of those were about people (not an unreasonable guess) that'd be 550,000 biographies here at Wikipedia. We'd guess about 1/365 would have any random birth or death date. That's approximately 1500 people per day born, and 1500 people per day die (a bit less, since some of those people haven't died yet). Aproximately 3000 lines of text just to keep track of birthdates and deathdates is unreasonable. --Jayron32 16:11, 31 January 2018 (UTC)[reply]
  • I don’t know if this is possible tech-wise, but what would be helpful to the reader would be to group “on this day” entries into sub-lists... non-birthday events that occurred on the day go in one section... birthdays in another (I would even divide the birthday listings up into sub-sub-sections by profession groups: Performing arts, business, politics, etc). This would help readers USE the lists more efficiently... to more easily find the information they are looking for. Blueboar (talk) 11:35, 29 January 2018 (UTC)[reply]
  • Could this be better handled by categorifying the data? That way, the category "Born on XXXX" would automagically be populated. Surely there is some better semi-automated way to handle this better than relying on people randomly coming by to add a name to a page. --Jayron32 15:11, 29 January 2018 (UTC)[reply]
    • See above: Categories don't allow readers to see a brief summary of each person, or even display which year they were born. Also, if you wanted to try to sort these categories by year it would be problematic and very counterintuitive (even if you add leading zeroes to account for years < 1000), B.C. dates would still be sorted alphabetically (so 1 BC first, 300 BC last), followed by A.D. sorted alphabetically (1 AD first, 2017 last). If not, then you end up with just an unreadable list of names sorted alphabetically, something I doubt any of the readers (for example those mentioned above by CapitalSasha and Od Mishehu) would be interested in. With Wikidata, it should be straightforward to get a bot to maintain these lists as articles, rather than resorting to categories of use to neither man nor bot. What do you reckon? ‑‑YodinT 16:17, 29 January 2018 (UTC)[reply]
I'm against this, primary because I fear it would have potential to creep over to the "years" article, in which the inclusion of everyone that has a wikipage is very useful. I also glimpsed at two random dates in January and it did not seem that outrageous, when you consider the attempted scope of the article. (Granted this was on the desktop version) We could include tools to make it easier to navigate however on mobile,but I'm not in favor of limiting the amount of people that could be there. --Deathawk (talk) 22:37, 29 January 2018 (UTC)[reply]
I would say that, in line with some others here, we should get rid of these sections; they seem irrelevant to information about the date (so most people on the page for a given date probably won't care about this information) and it's inherently too hard to come up with an objective standard for who should and shouldn't be included. Perhaps a set of categories for people who were born or died on a given date would be an improvement (i.e. Category:People born on January 1, etc.) Every Morning (there's a halo...) 00:34, 30 January 2018 (UTC)[reply]
I think much of this debate comes from a fear that these pages will get too long too quickly and will become out of control. This, for the most part, is unfounded, as the pages are edited by humans and most people will not actually have time to edit these in such a way that it gets unmanageable. And if they do, we can split it off into a separate article. I agree with a sentiment explained already in this threat that the people who go into a date article probably are looking for a list of who was born and who died on that day. What I'm saying is, I don't think this is a feature that our readers are annoyed by, so much as editors are, and we should be in service to the reader. --Deathawk (talk) 02:07, 30 January 2018 (UTC)[reply]
I agree with Deathawk's position. It is trivia, but the reader looking up a date like January 30 probably is looking for this kind of trivia. Coming up with DYK-like restrictions for it seems to serve editors more than readers, IMHO. Double sharp (talk) 05:56, 30 January 2018 (UTC)[reply]
There has to be some way to manage these lists. Right now, Category:1980s births has approximately 15,000 people per year. Given that everyone born will die, and that Wikipedia continues to exist, that's roughly 1,000 new entries per date every ten years. That's untenable. The argument that this won't happen because people won't do it strikes me as flawed because that's not a guarantee that it won't happen, and it wouldn't be hard to write a bot to populate those lists or for one determined editor to do so. The fact that it hasn't happened yet is probably due more to the fact that these lists are currently curated, even though we don't have clear guidelines. Personally, I think it'd be best to create a new article People born on (x date) and leave a tiny subset of the most notable (determined perhaps by restricting it to a certain number per article or by set criteria) on the actual date article itself.
As to the other arguments, I agree that these lists are largely trivia, but that does seem to be the purpose of the DOY articles, and I’m okay with that. I don't think a category suffices because it doesn't include the brief descriptions and because categories are merely alphabetical and not chronological. -- irn (talk) 14:16, 3 February 2018 (UTC)[reply]
  • A summary of my opinion:
  1. These sections are of value and are the kind of thing people expect to see in an article about a given year or date.
  2. They should not be allowed to become too long. 100 names in each section should be the absolute limit.
  3. An effort should be made to ensure a spread of nationalities, occupations, and historical period.
There will be a lot of work needed to establish criteria but to me it seems essential that we make the effort. — Preceding unsigned comment added by Deb (talk • contribs)
  • If nothing is done we'll have to put up with seeing the Births and Deaths sections grow to enormous length – I recently saw someone going through methodically adding all the footballers from a particular country, and we have no rule against this. I've estimated potentially 3,000 names under Births for each day. Otherwise we need criteria for "super-notability" to go on these lists. Something on the lines of Deb's suggestion may work if we have subsections for each date with really tight and unarguable eligibility, such as "Monarchs, presidents and prime ministers born on this day", "Nobel prizewinners born on this day", "Olympic gold medallists born on this day" ... then "... died on this day", all chosen to ensure Deb's "spread of nationalities, occupations, and historical period": Noyster (talk), 17:19, 3 February 2018 (UTC)[reply]
I like that suggestion a lot. The unarguable eligibility for super-notable subsections seems a little difficult to me, though, when dealing with entertainers and sportspeople. (Michael Jackson and Pelé come immediately to mind as examples.) I think it should be doable, but we might need to elaborate the criteria elsewhere and just label the subsections "Entertainers" and "Athletes", for example. -- irn (talk) 17:42, 3 February 2018 (UTC)[reply]
  • Any notability criteria is likely to be subjective and devolve into protracted discussions over personal preference of notability, to the detriment of time spent actually improving the encyclopedia. I suggest adopting the type of standard used at "On this day - born/died" which is (I think) B-class articles or above. This would encourage editors to improve their favourite biographies to B-class to get them included on the day page, and would also be an objective standard. I have seen editors going through the day pages removing names which they personally consider non-notable and it's very subjective of course - "not her, she's a porn star and that's not on" etc etc. It should also be easy to get this automated if it's pulling on the pools of B, A, GA and FA articles only. MurielMary (talk) 09:39, 4 February 2018 (UTC)[reply]
B-class isn't exactly a objective criteria..anyone can change ratings.Galobtter (pingó mió) 09:44, 4 February 2018 (UTC)[reply]
  • I really like the incentive for editors to improve the articles. While it might not be a perfect solution, I think it would address the concerns of editors who work on DoY articles, in that the lists won't become unmanagable (for at least the next decade or so), and we shouldn't allow the potential fixing mentioned above to prevent a good idea from being implemented. It also seems to follow the pattern of WP:ITN, in that it's not just about "more or less notable", but quality of their coverage on Wikipedia. Would love to help with an improvement drive to address WP:BIAS on this. ‑‑YodinT 12:39, 4 February 2018 (UTC)[reply]
  • Just tossing out an idea here... If we really want to base inclusion on article quality, then perhaps the criteria should be “good article” status. “Good article” status is a more defined process which means the article has been reviewed and has achieved a substantive quality standard. The down side is that some notable subjects may not be listed (if the article about them is poorly written) ... the up side is that this would encourage editors to work on these articles, and bring them up to “good article” standards. Blueboar (talk) 13:37, 4 February 2018 (UTC)[reply]
I'm thinking limiting it to B articles might work quite well. Deb (talk) 11:44, 5 February 2018 (UTC)[reply]
The problem I see with limiting this to a certain class of article is that it's not exactly user friendly. I imagine that the majority of editors adding content to these pages are relatively inexperienced to Wikipedia, and would be unaware of what a "B class article" means. It would be devastating for them to come and have there edit reverted. I could imagine some editors who might prove useful to the project being turned away from it as a result. It's just too much CREEP. One thing that might work is instead language that encourages the inclusion of "high class" articles as opposed to underdeveloped ones. A good example is how Wikipedia: Unusual Articles, states that the articles should be of "decent quality" but does not further expand on what that means, as a result the editors somewhat police themselves. --Deathawk (talk) 03:41, 6 February 2018 (UTC)[reply]
"Decent quality" is rather subjective, and, if editors got together and put a definition on "decent quality" I suspect they would just be re-inventing the wheel - WP already has definitions of quality in the Stub/Start/C/B/A/GA etc scale. I think In The News has a definition of "decent quality" for inclusion in their corner of the main page which is something like "no orange tags, all statements cited, no copy vios of images" but this is a pretty low bar and I think using something this minimal wouldn't go far to reduce the quantity of articles on the day pages. What I've noticed at In The News is that someone nominates an article for inclusion, someone else tags it with an orange tag, then the nominator gets to work fixing up the article, the orange tag is removed and it gets published on the main page. Good for the encyclopedia to have all that effort going into improving articles. MurielMary (talk) 10:48, 6 February 2018 (UTC)[reply]

I still maintain that this is problem mostly imagined. Personally I find it a bit ridiculous to have a Wikipedia article for every day of the year, but I don't really see it as problematic and if people find it interesting I don't mind either way. Having said that if you include a list of every date and have a listing of birthdays and death dates for the page, then it stands to reason that you are going to get a lot of listings . However this is the purpose of the page and it is fulfilling that roll. To somehow modify that list, you are now making it actually less useful, and it's falling farther and farther from the purpose. --Deathawk (talk) 20:17, 6 February 2018 (UTC)[reply]

@Deathawk: There are over 1.5 million biography articles at the moment, that's more than 4,000 births for each day, plus deaths, with more being added all the time. If we don't attempt to curate them, they would quickly reach article size limits. I would personally agree that complete lists make sense, and aren't a problem, but they would have to be split from the main pages. But either way, we've got three options I suppose:
  1. No births & deaths on the DoY pages (and optionally splitting the lists into separate articles).
  2. Having a list without the names of people that very few readers would have interest in (e.g. a very obscure mid 20th century sportsman compared to, say, Alexander the Great) – again, this could be done in conjunction with separate lists, but doesn't have to be, as at present.
  3. Ignoring the DoY articles, allowing them to fill up, quickly becoming very slow, to the point of being unreadable on mobiles, and eventually reaching the absolute article limit, preventing editing, etc..
A fair number of editors are trying to prevent #3 from happening, but it's a complete pain without guidelines that would make the process easier (and hopefully automated, to free us up to do more positive editing!). I guess you're not actively trying to prevent this from happening, but opposing it on the grounds that it's imagined makes me think you don't do much editing on DoY pages? Either way, it seems that for the first time in a long while we're finally pretty close to reaching a consensus – would be great to reach the point where a clear guideline proposal could be made. ‑‑YodinT 21:53, 7 February 2018 (UTC)[reply]
A bit late to the discussion, but the original question was whether the pages were too America-centric. I've been attempting to correct this by deliberately adding people from around the world. A problem that comes up often is that many of these are stubs, or need content from another wiki. Add to that the new requirement that dates of birth and death need good Wikipedia references, and it's a lot more work to edit these pages with quality content.
For the record, I guess I'd go with option 2 above. There's a lot of interest in "born on this day" and "died on this day", so I think births and deaths are relevant. Natalie Bueno Vasquez (talk) 06:23, 8 February 2018 (UTC)[reply]

As for the proposals above which suggests that all articles that are mentioned in Births/Deaths sections need to be at least B-class, I'm not sure it would work in filtering out systemic bias; if anything, it could only help worsen it. Some articles on even the most well-known Western people are at C-class or lower, meaning that they'd have to be left out; on the other hand, from experience, articles on non-American or non-European topics tend to be of a lower quality as well, meaning that even very popular names wouldn't be mentioned. So while article quality could potentially work as a standard for inclusion, it also has its drawbacks and might not solve the problem at all. As for the suggestion of simply making separate list articles and listing all births/deaths there, that would be wildly impractical: such articles would be way too long. Narutolovehinata5 tccsdnew 07:37, 8 February 2018 (UTC)[reply]

Lists of births & deaths could easily be broken down (either by the people's roles as suggested by another editor above, or by century). ‑‑YodinT 09:58, 8 February 2018 (UTC)[reply]

Guidance on removing comments from closed discussions

Just a few minutes ago, I reverted a commented added to a closed discussion (the RfC above about airline destinations). My revert was then reverted by Mandruss, citing WP:TPO. The language on the RfC closing template seems to contradict WP:TPO. Can anyone help clarify what should be done here? Thanks. –Deacon Vorbis (carbon • videos) 14:12, 28 January 2018 (UTC)[reply]

Re: [2][3][4]
I'll ask again: What part of WP:TPO authorizes this removal? The fact that a comment violates a guideline (let alone a comment generated by a template, which was what was cited by Francis Schonken) does not authorize removal, or we would be allowed to remove vios of NOTFORUM etc. We are not (and, by the way, NOTFORUM is part of a policy). Removal is a serious action and it is reserved for the most egregious situations. Even if commenting in a closed discussion is considered disruptive, TPO bullet 3 states: "Posts that may be considered disruptive in various ways are another borderline case and are usually best left as-is or archived." It is not considered disruptive in my experience, and in fact I was roundly chastised once in my younger days for simply objecting to comments added after a close. A close is a suggestion, not the 11th commandment.
The rules must be applied evenly to all comments, including useless comments by new editors. To do otherwise is a very slippery slope. ―Mandruss ☎ 14:20, 28 January 2018 (UTC)[reply]
Rather than REMOVING a comment added to a closed discussion, I would suggest that the appropriate action would be to create a new sub-section (perhaps entitled “Comments made after closure”), and MOVE the added comment into that sub-section. This way others know the sequence of events. Blueboar (talk) 16:30, 28 January 2018 (UTC)[reply]
Right, it makes perfect sense that you wouldn't want it to look like the comment occurred before the close. It could be done as you say, or one could just move the comment below the {{closed rfc bottom}}, {{abot}}, etc. Either would be acceptable under the refactoring provision, as I see it. Removal is not refactoring any way you shake it. ―Mandruss ☎ 19:25, 28 January 2018 (UTC)[reply]
And it was my bad for not doing that instead of the plain revert. ―Mandruss ☎ 19:28, 28 January 2018 (UTC)[reply]
  • Support removal - The bottom of that closed discussion clearly states The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.
Admittingly after maybe an hour I've added a comment to a closed discussion as part of an update or to say thanks but other than that discussions shouldn't really be edited especially after 5 days of it being closed, Removal was fine. –Davey2010Talk 19:43, 28 January 2018 (UTC)[reply]
There is nothing in TPO about removal of comments that "shouldn't really be" posted. If you're invoking WP:IAR (aka WP:IJDLI), at least say so. Or, you could play the "Wikipedia does not have firm rules" card, or any of the various other trump cards that shut down policy/guideline arguments. ―Mandruss ☎ 19:50, 28 January 2018 (UTC)[reply]
Discussion
I never said there was - TPO IMHO is unrelated, I'm not invoking anything - Read the template which again I will quote for you! - The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion. - It clearly states No further edits should be made to this discussion. - What's hard to understand about that ?..... He shouldn't of added it and you shouldn't of blindly reverted the reverter,
WP:WIKILAWYERING isn't going to help you at all - Accept you were wrong and move on. –Davey2010Talk 21:57, 28 January 2018 (UTC)[reply]
Hey dude, save the tone for noobs who are impressed by it. When the community (read reasonable consensus here) tells me that a message generated by a template trumps TPO, when neither TPO nor the template message say anything to that effect, I'll gladly defer to community consensus. In almost 5 years, I've yet to defer to intimidation attempts by lone editors. ―Mandruss ☎ 22:13, 28 January 2018 (UTC)[reply]
No one is intimidating you and I'm by no means "The voice of Wikipedia" but it's common sense .... if the bottom of a templates tell you not to edit that discussion then you don't edit it it's that simple and as you've been here for more than 5 years none of this should be new to you, Point is you shouldn't of reverted and point is TPO is wholly unrelated here. –Davey2010Talk 22:54, 28 January 2018 (UTC)[reply]
I have never known "Don't do this on talk pages" to automatically and invariably translate to "It's ok to remove this if somebody does it". Look at the template message produced by {{atop}}. 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. It does not say No further edits should be made within this close box—it says "discussion" and that means thread—and yet experienced editors often add comments below the close box when there is a legitimate reason. Are those comments removed because they violate the letter of the template message? No, they are not. The comments aren't even collapsed, let alone removed. And "legitimate reason" gets a very liberal interpretation, and even pointless humor is tolerated unless it drags on too long.
If your common sense is so common, how do you explain the fact that 12-year editor Blueboar said something completely different above? ―Mandruss ☎ 23:19, 28 January 2018 (UTC)[reply]
Support removal - when someone adds content to a closed discussion, they make it look like this content was part of the content which the closing admin had before him/her and considered when determining the consensus. Such sections should be removed, in order not to mislead subsequent users viewing the discussion. עוד מישהו Od Mishehu 09:14, 29 January 2018 (UTC)[reply]
  • Support removal--Per OD and that's how we normally do things.Winged BladesGodric 11:58, 29 January 2018 (UTC)[reply]
  • Support removal as per the template instruction Atlantic306 (talk) 12:17, 29 January 2018 (UTC)[reply]
  • Keep the comment especially in this case – a newish editor expressing their frustration with Wikipedia, to then have a notification saying that their complaint had been reverted without explanation is a great way to WP:BITE a newbie. How much more work would it have been to move the comment into a new subsection below it, to at least acknowledge them? Either way, WP:TPO should be updated to cover closed discussions, and I don't think it should be used as a reason to silence others' comments on a subject unless in the most extreme cases (e.g. posting personal information, etc.). ‑‑YodinT 12:52, 29 January 2018 (UTC)[reply]
  • Keep the comment in some way We actually do have an established practice by many experienced editors to sometimes add comments after something is "boxed" closed - it usually is placed directly below the box - so, generally do that. Alanscottwalker (talk) 13:04, 29 January 2018 (UTC)[reply]
  • I agree with Alan. It shouldn't be deleted outright, but Od Mishehu is right in that leaving it within the closed discussion box leaves a on incorrect impression of what the closer actually saw. Moving the comment below the close box (possibly with a subheader) is the best solution. oknazevad (talk) 13:22, 29 January 2018 (UTC)[reply]
  • Support removal. Closed discussions are supposed to be a snapshot of what the closer saw – thus the bold, red text that tells you not to modify it. NinjaRobotPirate (talk) 13:27, 29 January 2018 (UTC)[reply]
  • Keep in some way- outside the box is fine, and if it's inside the box then it should be moved out of it. Particularly if someone is writing a comment then gets edit conflicted by the closer. Reyk YO! 13:29, 29 January 2018 (UTC)[reply]
  • Remove and/or Move the comment to outside the box as needed. Each case should be taken of its own accord; as a general policy we should not allow editing within a closed archive box; however if additional commentary is needed, the option should exist to either remove it (for inappropriate comments or ones which are not needed) or move it to outside the box (if necessary; i.e. commentary on the close itself). If an archive box is used with a summary statement, it is inappropriate to add additional commentary inside the box, as it implies the closer had access to that statement when closing. We should leave legitimately closed discussions as-is in most cases, and if additional comments are needed, start a new thread. --Jayron32 15:08, 29 January 2018 (UTC)[reply]
  • Generally Move the comment to outside the box per Alanscottwalker. Although Jayron32 is right that this is a case by case decision. Some comments can probably be removed as disruptive or untimely, but the default rule is (or ought to be) to move a late comment "outside the box".
  • Regarding having comments added after the closed discussion: at least once I've added a comment after the closed discussion and it was removed. I appreciate there are situations where prolonging the discussion is undesirable (such as a discussion that has been going around in circles for some time). I think it will depend a lot on the nature of the comment: if it's yet another repetition of a point that's already been made multiple times, then it can probably be safely deleted without affecting matters. If it's something new, then it may be reasonable to keep the post-closure comment (outside of the closed discussion). isaacl (talk) 21:20, 29 January 2018 (UTC)[reply]
  • The comment should be transferred to the talk page of the closed AfD. Xxanthippe (talk) 21:36, 29 January 2018 (UTC).[reply]
  • Keep in some way outside the close box - Assuming of course that the comment is not qualified for removal per WP:TPO. Completely clueless comments like the one that triggered this discussion are sometimes removed as trolling (TPO bullet 3), but that word gets as much misuse as the V word. Actual trolling has no purpose but to disrupt and produce a big negative reaction, and there needs to be fairly clear evidence of that intent. Outright removal should be used very conservatively, and we should err on the side of retention. ―Mandruss ☎ 02:09, 30 January 2018 (UTC)[reply]
  • Keep, but move outside the box. Adding comments to a closed discussion is discouraged simply because they're most likely to be ignored: the community has discussed the matter, a decision has been taken and then everyone has moved on. But if an editor decides to add a comment, then there's nothing stopping them. There are many cases where it's useful to add such comments – say, for an update or a follow-up comment, and even in cases where it isn't (for example when the poster is venting about the injustice of the close), they're tolerated. And obviously, the comment should be moved outside the box because otherwise it would be misleading. – Uanfala (talk) 00:20, 31 January 2018 (UTC)[reply]
  • Support removal the person can move them outside the box themselves afterwards if they feel like it. Reversion is fine. TonyBallioni (talk) 00:24, 31 January 2018 (UTC)[reply]
  • Keep but move outside the box per Uanfala. Double sharp (talk) 06:32, 31 January 2018 (UTC)[reply]
  • Keep, outside the box. It is useful to have, for example, a link to a further discussion about implementing the agreed action, without it being either removed on procedural grounds or mistaken for part of the decision process. Certes (talk) 15:31, 1 February 2018 (UTC)[reply]

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

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

DYK and COI/paid editors

  1. If an article was created and/or nominated by paid a COI editor, should that be explicitly disclosed in the nomination?
  2. Should articles created and/or nominated by paid COI editors be eligible for DYK?

Discussion at Wikipedia talk:Did you know#DYK_and_COI/paid_editors. --BrownHairedGirl (talk) • (contribs) 20:41, 29 January 2018 (UTC)[reply]

Infoboxes on Biographies

RfC withdrawn. power~enwiki (π, ν) 19:13, 4 February 2018 (UTC)[reply]

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

Should infobox policy (i.e. WP:INFOBOXUSE) be amended to state that all biographies rated at B-Class or higher should include an infobox? power~enwiki (π, ν) 02:43, 30 January 2018 (UTC)[reply]

Note: it's clear that this proposal isn't going to pass as-written. I've withdrawn the RfC but am leaving the discussion sections open. This is both because there continues to be some useful discussion, and because I feel a close should include an assessment of any consensus by someone uninvolved. power~enwiki (π, ν) 19:13, 4 February 2018 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Votes: Infoboxes on Biographies

  • Support as nom. In my opinion, the infobox wars are over, and infoboxes have won. My estimate is that about 98% of high-profile biographies contain infoboxes. A few articles, such as Cary Grant do not have infoboxes. While the current status is that "Infoboxes are a decision on a per article basis and consensus should be made there", in practice this simply allows for the pro-infobox and anti-infobox crowds to repeat the same arguments on many similar articles. The simplest way to eliminate this controversy is to standardize on including infoboxes on biographical articles, once they are sufficiently developed as to justify them. In general, biographies contain several pieces of information which are suitable to an infobox, including a photograph, date and place of birth/death, familial relations, and primary occupation, so the question of whether there is sufficient information to include an infobox should not be relevant. power~enwiki (π,ν) 02:43, 30 January 2018 (UTC)[reply]
    • The purpose of an infobox is to provide a summary of the article. Not all articles about people are easily summarisable in a tabular format. If the infobox can't represent the relevant key points of a poet or a composer's biography, then it's worse than useless as it skews in the direction of trivia. And frankly, if a person's biography could be meaningfully summarised by the places of their birth and death, their occupation and who they married, then well... that person would not be notable. – Uanfala (talk) 05:33, 31 January 2018 (UTC)[reply]
  • Oppose no need to dumb down. - Sitush (talk) 03:27, 30 January 2018 (UTC)[reply]
  • Support: There is very little reason, for not including an infobox. Wikipedia should be standard across all biogrophies and the claims that it makes an article "ugly" does not hold up to me. Articles should be focused on providing information first and foremost. --Deathawk (talk) 09:16, 30 January 2018 (UTC).[reply]
  • Oppose Infobox use is subject to local consensus at the article and varies in usefulness. this is just another attempt to shoehorn in pointless infoboxs to a huge selection of articles. Only in death does duty end (talk) 09:56, 30 January 2018 (UTC)[reply]
  • Weak support One caveat here -- firstly, whether an article is B-class or not is an assessment by decree, so WP:GAME could become an issue with those pesky folks who like to argue about these matters. Therefore, to avoid this, I would like to see the standard upgraded to Good Article status, which means that unless the article is delisted, it enshrines the infobox onto the article, and avoids anyone downgrading an article to C-class and then removing the infobox. But it should stop the arguments in a few cases. Going in the right direction. !dave 12:55, 30 January 2018 (UTC)[reply]
  • Oppose yet another attempt to force these on the community. Sitush's comments below is particularly on point. MarnetteD|Talk 13:02, 30 January 2018 (UTC)[reply]
  • Drop the stick In just the last week we have had Wikipedia:Administrators' noticeboard/IncidentArchive974#The toxicity of Cassianto and his bullying tactics; Wikipedia:Arbitration/Requests/Case#Civility issues; Wikipedia:Village pump (proposals)#RFC: Infoboxes should be collapsable, in non-politician & non-sports bio articles.; Wikipedia talk:Manual of Style/Infoboxes#Infobox; and Wikipedia:Village pump (policy)#RfC: All Wikipedia articles should have infoboxes (straw poll) - and that's just the ones that I became aware of through my watchlist. Some of these are still open: enough already. --Redrose64 🌹 (talk) 13:20, 30 January 2018 (UTC)[reply]
  • This was bound to happen sooner or later. Personally, I Support standardising on infoboxes in articles which contain enough information to fill out an infobox. As a Wikipedia reader When I am quickly looking up a fact about a person, filtering through a load of prose takes a lot more time than just looking at the person's DoB in the infobox. This is what they're for, and they're exceptionally useful. I also find the WP:BATTLEGROUND behaviour on talk pages incredibly disruptive - whatever happens, that needs to stop. I concur with notdave, however - there's a risk of the passionate-about-infoboxes crowd attemping to WP:GAME the article class system to forcibly add/remove infoboxes. -- Cheers, Alfie. (Say Hi!) 13:32, 30 January 2018 (UTC)[reply]
    Not a bad way to incentivize substantial article improvements. Upgrade an article and get an infobox today!! ―Mandruss ☎ 13:50, 30 January 2018 (UTC)[reply]
    That is not necessarily how it would be gamed. See my comments in the discussion section. - Sitush (talk) 14:19, 30 January 2018 (UTC)[reply]
  • Support with caveats Personally, I want the consistency of data that infoboxes provide, and would fully agree that they should be used across all biographical articles. However, I do agree that they should only be used where there is a minimum amount of accurate/verified information that can be used to fill it (ala the Homer example brought up should not have one, far too many questions), and there should be a broader discussion regarding infoboxes in general along the lines of the "religion=" field, in which where data fields should not be filled in to avoid drive-by-filling-in of fields. (If you leave it blank, they will come). I know the arguments for Kubrick et al is that the infobox is aesthetically unpleasing, but I think that since our missing is dissemination of data first, and niceness of a page far below that (as long as assessibility is met). --Masem (t) 14:17, 30 January 2018 (UTC)[reply]
  • Support per Masem + I think there are some fields (awards, notable works) that would help reduce the trivialness of the infobox too. I'm not sure about this exact formulation though, (concerns about gaming + I think all non-stub articles, or even stub ones should have infoboxes) Galobtter (pingó mió) 14:51, 30 January 2018 (UTC)[reply]
  • Oppose, saying this as someone who routinely includes infoboxes, but let's get away from prescriptiveness on things. There will be situations where even a biography doesn't really need an infobox. Trying to set out "rules" for when and when-not will just cause more issues. We're better off with the current situation in the guidelines. This will not solve the "infobox wars" because that is driven by editor behavior - not the infobox rules. Ealdgyth - Talk 15:34, 30 January 2018 (UTC)[reply]
  • Oppose. While infoboxes are excellent and essential on some articles, sometimes they're not, and a blanket "rule" isn't the best way to avoid dealing with the positives and negatives on an individual basis. - SchroCat (talk) 15:38, 30 January 2018 (UTC)[reply]
  • Support with caveats I hold a similar view to Masem. In general infoboxes are good but there are some cases where they have a minimal amount of information and it is better to just not include it. Emir of Wikipedia (talk) 16:29, 30 January 2018 (UTC)[reply]
  • Comment The proposal is to modify a MOS Guideline. Guidelines are just that not hard rule or policy. Every usage is open to discussion on the talk page. Nothing changes in effect, other than giving the inclusionsists a little more weight in consensus discussions. It doesn't mean they can do mass inclusions because that will be controversial, and controversial edits are supposed to be discussed first. -- GreenC 16:41, 30 January 2018 (UTC)[reply]
  • Oppose - I think it's fairly clear from the recent goings on that this is not going to get a strong consensus. I like infoboxes. I use them in almost everything I write. Not everyone does, and I would oppose this either way for trying to use B-class as an arbitrary cutoff point. GA itself has a lot of variation, and other than stub, everything below that varies in consistency to the point of being nearly meaningless. That's only setting people up to get into conflicts about article assessments as a by-proxy infobox conflict. GMGtalk 16:42, 30 January 2018 (UTC)[reply]
  • I have often thought that we should divide Wikipedia into two complimentary projects: Wikipedia and a new sister project called “WikiAlmanac”. A main difference would be that the two projects would display information in different formats... Wikipedia would present its information in prose format (like other encyclopedias), while WikiAlmanac would present its information in charts, lists and info-boxy format (like other almanacs). Blueboar (talk) 16:57, 30 January 2018 (UTC)[reply]
  • Oppose - (edit conflict) They should be removed on a case-by-case basis - Infoboxes can be and are extremely helpful however in some cases (like with small articles) they're not .... but again these should be removed on a case-by-case basis not just blanket-removed. –Davey2010Talk 16:58, 30 January 2018 (UTC)[reply]
  • Oppose Infoboxes can be very useful on biographies where the subject's notability has a statistical context (such as sport) or in the case of politicans, but I have seen enough biographies where the infobox doesn't particularly enhance the article, so they shouldn't be mandated Betty Logan (talk) 17:49, 30 January 2018 (UTC)[reply]
  • Goodness gravy. Can this just stop. The community consensus on Infobox use is clearly to have no guidance on infobox use. Its not that the community is neatly divided into camps supporting their use or opposed to their use. The community at large has a clear viewpoint on this, and the consensus is "there is to be no guideline or policy for or against the use of infoboxes". Holding the same discussion over, and over, and over, and over again is not going to produce a different result, and it is starting to get disruptive. Drop the effin stick already and let it go. --Jayron32 18:28, 30 January 2018 (UTC)[reply]
  • Oppose. Let the relevant wikiprojects decide how articles within their area of interest display information. We don't need a site-wide policy when there are going to be cases where an infobox is unnecessary or not useful. Natureium (talk) 18:35, 30 January 2018 (UTC)[reply]
  • Oppose - Concerning biographies? infoboxes should be limited to politicians, sports figures, religious leaders. GoodDay (talk) 18:40, 30 January 2018 (UTC)[reply]
    • Only commenting that this actually potentially gives a good delineating idea where infoboxes should be used when the person falls into some type of hierarchical larger structure and their notable is due to that - an athlete on a sports team, a politician within a government, a businessman within a corporation. This leaves things like artists, writers, musicians, actors/directors, professors/scientists, etc. that could have more flexibility. I'm not 100% sure on this but it is an interesting thought. --Masem (t) 18:54, 30 January 2018 (UTC)[reply]
      • I've seen several people come up with this sort of rule of thumb for biographies (with a lot of flexibility for including others as and when circumstances suggest it), and I think it's a good one. An IB works brilliantly on anyone who has worked through "positions" (politicians, military, clergy, businessmen, etc) where these positions or ranks can be clearly identified; it is also excellent on those with statistics (mostly sportsmen, etc), where a career record can be summed up in appearances, medals, etc. For those in the liberal arts they are less clear in their benefits. Even politicians can be overdone tho: the German article for Angela Merkel has her signature only (too little IMO), while our version is a bloated monstrosity that should be trimmed by about 50%. - SchroCat (talk) 20:07, 30 January 2018 (UTC)[reply]
        • For any bios considered iffy concerning infoboxes? We have the option of a collapsed infobox. -- GoodDay (talk) 21:04, 30 January 2018 (UTC)[reply]
        • There's definitely an idea there. I have yet to see editors fight over infoboxes about people that are easily slotted in organizations. (There's the infobox kudzo as you point out that we have to weed out, but that's different) and it would be great for these to be consistent, whereas for the liberal arts its less of importance. I'm mulling on this point. --Masem (t) 23:30, 30 January 2018 (UTC)[reply]
          • As the person who suggested the compromise of a collapsed IB there, and as I've already pointed out elsewhere, this does not work as the pro-boxers very quickly start demanding it is uncollapsed and/or just start doing so. SagaciousPhil - Chat 08:13, 31 January 2018 (UTC)[reply]
  • Oppose - Info-boxes are useful for some articles (sporting stats, political offices, ecclesiatical benefices etc) but look amateurish for many biographies where the essential facts cannot be boiled down to info-box simplicity. Tim riley talk 21:49, 30 January 2018 (UTC)[reply]
  • Oppose Most bios benefit from a box, but some do not, especially some older historical figures for whom none of the basic facts are actually certain - infoboxes handle lack of certainty badly. In the case of artists they take up space that would be better used for an image, and tend to be incompetently filled. For composers they are not liked by local editors, whose views I respect. Johnbod (talk) 22:13, 30 January 2018 (UTC)[reply]
  • Weak support an infobox is useful to get a quick standard view of known facts. Since it is structured it is easily machine readable and crawled for databases. I do not however think that B-class needs to require it in the text of infobox. The generic B class already says that articles should have infoboxes, templates, tables and pictures. So an infobox is to be expected already for B-class, and should be essential for GA class. Even where very little is known about a real person, an infobox can include a name and some other facts. Graeme Bartlett (talk) 23:00, 30 January 2018 (UTC)[reply]
    The criteria for B-class (which are transcluded to most WikiProject assessmsnt guides) say
    Diagrams and an infobox etc. should be included where they are relevant and useful to the content.
    The words "should be" are not synonymous with "must be", and the words "where they are relevant and useful to the content" serve to further weaken the requirement. Infoboxes are not "to be expected" and there is no mention of infoboxes in the GA criteria, hence nothing to make them in any way "essential" for a GA. --Redrose64 🌹 (talk) 00:49, 31 January 2018 (UTC)[reply]
  • Oppose - As I mentioned in the previous discussion, while a good proposal in theory, in practice it's unnecessary and could lead to instruction creep. It's good practice to have infoboxes, particularly in long articles, but absolutely mandating them every single time is not a good idea, since some kinds of articles are better off without infoboxes. If this was proposed instead as an essay where mentioning that it's encouraged but not required, that would be a better option. Narutolovehinata5 tccsdnew 00:22, 31 January 2018 (UTC)[reply]
  • Oppose. Even if it were the case that adding an infobox made sense for all biographies (and it obviously isn't), I'm not sure what is the point of stipulating this in the guidelines. Is there some problem out there that this is trying to solve? – Uanfala (talk) 00:29, 31 January 2018 (UTC)[reply]
  • Oppose - If an infobox in an article is that necessary, start by adding it to Wikipedia:Featured article criteria (yes, there could be a criterion that "If it's a biographical article about a person born since 1900, it has an appropriate infobox"), then work your way down to Wikipedia:Good article criteria. עוד מישהו Od Mishehu 07:57, 31 January 2018 (UTC)[reply]
  • Oppose IBs over simplify and do not allow for the nuances necessary in many articles. SagaciousPhil - Chat 08:13, 31 January 2018 (UTC)[reply]
  • Oppose overall site-wide blanket ruling, and per above comments. The recent go-around at the Cary Grant page gives a good indication that infoboxes are a good addition to some pages but not needed on others. Randy Kryn (talk) 18:53, 31 January 2018 (UTC)[reply]
  • Strong oppose. Unnecessary BURO CREEP. Adequately addressed at this time through individualized talk page consensus. James (talk/contribs) 23:51, 31 January 2018 (UTC)[reply]
  • Oppose, WP:CREEP. In some cases (such as sportspeople) where there is meaningful statistical data on a person, an infobox is very helpful on a biography. In other cases, they are just clutter and duplication of information better placed in context in prose. Lankiveil (speak to me) 00:27, 1 February 2018 (UTC).[reply]
  • Oppose. For many cases infoboxes are useful. For many other cases, they're not; biographical achievements often don't break down neatly into individual facts that can be summarised in a box, and even when they do, deciding what is and isn't included in the box can give undue weight to particular aspects of a person's life. As with many of the others above, I'm also extremely unimpressed at the "shoot-till-you-win" approach taken by those people who are constantly forum-shopping variations on the "make infoboxes mandatory proposal" across Wikipedia. ‑ Iridescent 14:56, 1 February 2018 (UTC)[reply]
  • Oppose Policy dictating the details of content of articles is a pretty dumb idea. The nature and content of any given article either lends itself to having an infobox or it does not. A diktat requiring compulsory infoboxes for an entire very broad category of articles is just silly. I'm saying this as an editor who almost always includes infoboxes whenever suitable in articles I have created or when expanding stubs to fuller articles. My "default" action is to add one if it fits, so I'm by no means a member of the supposed "anti-infobox faction". In short; article content is subject to consensus on an individual basis. We're building an encyclopedia, not a census database... Roger (Dodger67) (talk) 20:36, 1 February 2018 (UTC)[reply]
  • Oppose I would like to see infoboxes on every article but I don't find it appropriate to change policy to force adoption. Chris Troutman (talk) 21:04, 1 February 2018 (UTC)[reply]
  • Oppose this creepy proposal. Infoboxes should be added on a case-by-case basis pursuant to local consensus. AdA&D ★ 21:15, 1 February 2018 (UTC)[reply]
  • Support We need an overall rule. It's the only way to eliminate repetitive individual debate. the method of deciding article by article is the worst possible method of deciding, because it ensures that the entire issue will be discussed at every article, saying essentially the same things . The result is wasted effort, increased conflict, and inconsistency. Guideline spevcifyin nte content of articles is what WP needs to actually be an encyclopedia . DGG ( talk ) 00:14, 2 February 2018 (UTC)[reply]
  • Support per DGG and - All such decisions should weigh benefit and cost with equal realism and clarity. While the need for local freedom is nonzero, it's greatly overestimated. If we didn't already have site-wide consistency on style in section headings (sentence case, etc.), for example, we would see this kind of opposition to a proposal to make them consistent via guidelines. "There is no one-size-fits-all section heading, and that should be left to the editors of an article." If some B-class biographies don't really need infoboxes, they aren't really harmed by them either. In my view we need to move away from principles that encourage editor conflict and discourage inter-article consistency. ―Mandruss ☎ 01:07, 2 February 2018 (UTC)[reply]
  • But DGG seems to be saying it should be every bio, which is not the proposal. Furthermore, his argument could equally be turned on its head, ie: saying no to infoboxes in all biographies would fix the issue he claims exists just as well as saying yes to them. - Sitush (talk) 14:01, 2 February 2018 (UTC)[reply]
  • You'll have to ask DGG for clarification, but I don't read his !vote as "all bios". Consistency only among B-class bios is still a hell of a lot more consistency than we have now. As for saying no to infoboxes in all bios, I think that's a far tougher sell, almost a non-starter, so I disagree that his argument could equally be turned on its head. ―Mandruss ☎ 18:56, 2 February 2018 (UTC)[reply]
  • Oppose Sometimes an infobox fits really neatly to the topic without any fuss - I added one to Trellick Tower before nominating it for GA and it worked well. Sometimes it just doesn't do what you want it to do, as was the case with Portway, Bristol when I decided the chosen box didn't really present the most appropriate facts. The problem with mandating them is we'd probably end up with a whole bunch of forked templates just so somebody can create Template:Infobox radio presenter and musician (as I might have when I decided neither of the basic boxes were suitable for Marc Riley), and I see plenty of infobox templates turn up at TfD to know that there is a concerted effort to try and streamline things. Ritchie333 (talk) (cont) 17:10, 2 February 2018 (UTC)[reply]
  • Support L3X1 Participate in a deletion discussion! (distænt write) 18:26, 2 February 2018 (UTC)[reply]
  • Oppose: this isn't even an FA criterion and nor should it be. By all means add an infobox if you see an article that would clearly benefit from one, but this blanket rule would be unnecessary instruction creep. — Bilorv(talk)(c)(e) 04:16, 3 February 2018 (UTC)[reply]
    Indeed; it is unreasonable to make something a criterion for B-class when it is not a criterion for either GA or A-class; and it is similarly unreasonable to make something a criterion for either GA or A-class when it is not a criterion for FA. If, and only if, infoboxes become mandated by WP:WIAFA, we can look at top-down propagation of the requirements via WP:WIAGA on the way. Until then, I refer readers to my comment of 13:20, 30 January 2018 (UTC). --Redrose64 🌹 (talk) 11:37, 3 February 2018 (UTC)[reply]
  • Supportish I am not fan of MOS-type rules crushing the creativity of editors, but this is not going away. At bottom, past the bad behavior - that spins-up and spins-up -- we still have to work through it as a group. It's time for us to seriously consider least painful ways of harmonizing or homogenizing (depending) together. This rule may not be it, and some are right that just throwing something out there for aye and nay is getting us nowhere. So, my thought: those who are deeply engaged in this and anyone else who wants, go to Mediation, a-la Wikipedia:Mediation Cabal/Cases/11 February 2012/Muhammad-images, where you deeply explore the sources on summary use of infobox type things in reference works/textbooks, you deeply explore policy/guideline such as WP:SUMMARYSTYLE and WP:IMAGERELEVANCE and what ever other principles and 'spirits' of policy can be derived - you layout this research, you lay-out various arguments and you formulate RfC questions breaking down issues, and you put it to the community. Please? Alanscottwalker (talk) 15:05, 4 February 2018 (UTC)[reply]
    I think many such problems arise from having too many cooks in the kitchen, and it may work for a task group of perhaps 9 knowledgeable editors to work up proposal(s) to present to the community. No guarantee of success, but I think the odds of it would be significantly improved. If it failed, it would fail with far less total editor time expenditure. ―Mandruss ☎ 23:16, 4 February 2018 (UTC)[reply]
I would actually say the opposite is true, and that the problem with Navbox debates come from an editor, or a group of editors coming up with a solution and then putting it to a "yes" "no" vote via RFC. These fail ultimately because even people who are pro-infobox are hesitant to support some of these proposals. I think the solution is that we should close all of the current infobox RFC's and then open a new, relatively open ended question. I'm not entirely sure what that question would look like, but something along the lines of "what should we do about infoboxes?" --Deathawk (talk) 03:32, 6 February 2018 (UTC)[reply]
  • Support infoboxes are handy and give all relevant information at a single glance, in fact they're an innovation that benefits the readability of online encyclopedias, I am not sure if there are any of the "anti-infobox" camp left, but the main arguments against them were WP:IDONTLIKEIT. --Regards, Donald Trung (Talk) 16:16, 5 February 2018 (UTC)[reply]

Procedural (when to close)

  • ...Is it starting to look to anyone else like keeping this open is just wasting the time of the poor souls who are going to show up and comment on a foregone conclusion? GMGtalk 19:11, 31 January 2018 (UTC)[reply]
    • I'm planning to keep it open at least 72 hours. If an admin thinks it's in SNOW territory and the discussion isn't productive, they can close it. power~enwiki (π, ν) 19:15, 31 January 2018 (UTC)[reply]
      • I would advise keeping it open for the full 30 days. I suspect what's happening is that the anti-infobox crowd is jumping on. I suspect the section might look very different in a months time. --Deathawk (talk) 20:42, 31 January 2018 (UTC)[reply]
        • That's an interesting assessment. Can you indicate which voters are against infoboxes altogether? Because by my count a number close to zero of the opposes indicates they want to get rid of all infoboxes. Most people seem to be indicating that the current policy of dealing with this on a case-by-case basis is preferred. I'd like to know what your methodology is for reaching your conclusion. --Jayron32 21:04, 31 January 2018 (UTC)[reply]
          • Just common sense mostly, this is a heated issue on Wikipedia, with one side very feaverishly against a guideline for infoboxes. In the first few days, reason would dictate that they would come out against this police. Furthermore there seems to be a vestige interest in having this discussion closed, which does not seem completely on the up and up. It's obviously a topic that's been burbling under the surface for a while so it would make sense to have a full 30 day vote. If the vote closes without a consensus no guideline would be implemented, thus I worry that some people in the anti-infobox crowd are attempting to make that happen. --Deathawk (talk) 01:49, 1 February 2018 (UTC)[reply]
            • While I agree there's some bias in anti-infobox voters voting early and often, I consider it unlikely (though not yet impossible) the proposal will get enough support to be implemented. There still is value in discussion; I have no idea whether a policy that allows this decision to be made on the WikiProject level would pass, or if a less-strongly worded version ("Infoboxes are encouraged on biographical articles") might pass. power~enwiki (π, ν) 02:03, 1 February 2018 (UTC)[reply]
            • @Deathawk: there seems to be a vestige interest in having this discussion closed, which does not seem completely on the up and up. Where are you seeing this "vestige" interest? If you're referring only to the comments in this subsection, you might drop by WP:AGF for a read. It's quite common to call for a SNOW close when it's perceived that a proposal cannot pass, and where to draw the line is a legitimate matter for discussion. ―Mandruss ☎ 02:06, 1 February 2018 (UTC)[reply]
              • Yes, I understand that, but I do feel, just from looking around at the different angles of this, that this doesn't feel like a "snow close" case, for one there are at least seven votes in favor of this proposal. The second is that these comments about wanting it to close appeared almost immediately after. I'm not opposed to snowcloses in genreal, but it seems when one side overwhelmingly wants one, it may not be appropriate to grant it. Also I would state that if it was a true snowclose that it'd be obvious and there wouldn't have to be a discussion section calling for one. --Deathawk (talk) 02:15, 1 February 2018 (UTC)[reply]
                • I make it roughly 25% Support at this time, which I agree is not a SNOW situation now. I've suggested (below) waiting until at least 5 Feb, and in my opinion 25% then would be SNOW-worthy. Just my opinion. Maybe all SNOW close discussions should be restricted to uninvolved editors? ―Mandruss ☎ 02:24, 1 February 2018 (UTC)[reply]
                  • As I stated above, the fact that we're having this discussion, should make it obvious that it isn't WP:SNOW and likely never will be. The Clause is not supposed to be used as an indicator of one side "Winning" quite the opposite, it means that the vote was so unanimous that there isn't even a discussion to be had. In other words arguments don't just become "snowed" it's either apparent from the outset or it isn't. --Deathawk (talk) 03:06, 1 February 2018 (UTC)[reply]
                    • Fine, then remove the word SNOW and use "early close" instead. If we're still at 25% or below on 5 Feb, I support an early close. Not that you need any help with the math, but that's at least three times as many Opposes as Supports. The probability of reaching a consensus to pass (which would be well over half, probably at least 60%) by waiting another 23 days would be extremely low as there is no reason why the trend would take such a dramatic turn after 7 days. I ain't no mathimutishon but I think one would support me on this. ―Mandruss ☎ 05:44, 1 February 2018 (UTC)[reply]
    • (uninvolved opinion) Suggest letting it run through one weekend, close 5 Feb at the earliest. This doesn't fall into the "non-starter" category, and poor souls are never required to waste their time. ―Mandruss ☎ 00:58, 1 February 2018 (UTC)[reply]

I'm not going to withdraw this yet. While the combination of "people against infoboxes", "people against rules about infoboxes", and "people who feel this should be a WikiProject-level decision" are likely going to numerically outvote support for this proposal, there continues to be valuable discussion on the topic of infoboxes as a whole, and I feel my withdrawing the RfC now would be disruptive to that discussion. power~enwiki (π, ν) 17:50, 2 February 2018 (UTC)[reply]

Extended discussion: Infoboxes on Biographies

I think one area where infoboxes are generally not used are on composers; unsure about usefulness there and the expectation of having an infobox. Galobtter (pingó mió) 12:30, 30 January 2018 (UTC)[reply]

I can't imagine why an infobox would be less useful because they are a composer. Tradition, and editors' fondness for it, is another matter. ―Mandruss ☎ 12:42, 30 January 2018 (UTC)[reply]
Yeah I don't know. Will have to think of those, though, as it is (as far as I know) the most significant source of non-infobox containing well-developed biographical articles Galobtter (pingó mió) 12:45, 30 January 2018 (UTC)[reply]
  • This is a terrible idea and will just reignite the infobox wars. What is to stop someone who really, really likes infoboxes upgrading an article to B class simply so they can add one? What happens to articles that are downgraded? What about articles where there really isn't much that could go in the thing? It is just wrong to impose something like this. - Sitush (talk) 12:48, 30 January 2018 (UTC)[reply]
Definitely shouldn't be linked to article rating/quality Galobtter (pingó mió) 12:54, 30 January 2018 (UTC)[reply]
Someone has just suggested upping the qualifier to a minimum standard of GA. That doesn't alter my opinion: there are loads of crap GAs, and loads more are added every year because the standard of reviewing is so arbitrary. It is also unnecessary: just why must a B-class or GA+ or whatever have to have an infobox? And what happens if an infobox is imposed because of GA but then the article is delisted? - Sitush (talk) 12:58, 30 January 2018 (UTC)[reply]
This s not understanding the point of this proposal. The idea is the every biography should have an infobox. The B level just gives us a place to start and it allows stubs to exist without them, since the may not have had time for such a box to be created. Upgrading or downgrading an article, shouldn't matter in this respect, the idea is that it states that infoboxes are expected and requires high quality articles to have them. --Deathawk (talk) 04:22, 31 January 2018 (UTC)[reply]
I understand the proposal perfectly well, thank you. It is seeking what is says, which is not infoboxes for every biographical article. If they or anyone else wants one for every such article then they should propose that. You've done the proposal no good whatsoever by suggesting that there is some ulterior motive. - Sitush (talk) 11:22, 31 January 2018 (UTC)[reply]
Well, it is a better idea than having the guideline applied to criteria that is rather arbitrary in application. So it's that, no entry criteria at all, all biographies to have infoboxes, or that this proposal is baseless and silly. !dave 13:05, 30 January 2018 (UTC)[reply]
The last of your options, I suspect. - Sitush (talk) 13:14, 30 January 2018 (UTC)[reply]
Very edge case. Could be excluded as not really known who he was, which is reflected in the lead sentence. the name ascribed by the ancient Greeks to the legendary author; could include notable work I guess.. Galobtter (pingó mió) 13:30, 30 January 2018 (UTC)[reply]
  • This is the current policy. To overturn that would require a motion at WP:ARCA. --Redrose64 🌹 (talk) 13:29, 30 January 2018 (UTC)[reply]
    6) The Arbitration Committee recommends that a well-publicized community discussion be held to address whether to adopt a policy or guideline addressing what factors should weigh in favor of or against including an infobox in a given article. Finding of Fact 2 just reflects the status at the time; ARBCOM cannot dictate policy (and doesn't, and hasn't). Galobtter (pingó mió) 13:34, 30 January 2018 (UTC)[reply]
    You beat me to it. ―Mandruss ☎ 13:42, 30 January 2018 (UTC)[reply]
    The first 2 parts of ArbCom decisions ("Principles" and "Findings of fact") represent the way ArbCom see the current (at the time of the case) situation; it may include an interpretation of the "current" policy, but doesn't prevent changes to policy. עוד מישהו Od Mishehu 14:03, 30 January 2018 (UTC)[reply]
    I'm not sure what the drop the stick is about; discussions about Cassianto et al. are not relevant and the other proposals were quite different; only would be beating a dead horse if it were already decided that this proposal or something very similar relating to infoboxes in biographies was closed as no. Galobtter (pingó mió) 14:54, 30 January 2018 (UTC)[reply]
    I'm guessing Rose is suffering from Generalized Infobox Fatigue (GIF). ―Mandruss ☎ 15:14, 30 January 2018 (UTC)[reply]
    Of the five threads I linked, the one at ANI mentions infobox twice in the first sentence; the one at Arbcom mentions infobox in the first sentence of the first statement (that by Volvlogia); whilst the other three (the one at VPR; the one at MOS; and the one at VPP) concerns nothing but infoboxes. They all directly concern the inclusion (or otherwise) of infoboxes, as does this RfC. Were it not for the fact that they have several different initiators, I would have called WP:FORUMSHOP and closed this as soon as I became aware of it. Can we at least agree that holding multiple simultaneous discussions on the same matter is a Bad Thing? --Redrose64 🌹 (talk) 18:23, 30 January 2018 (UTC)[reply]
    Arbcom have now accepted it as a case. It'll all end in tears, there will be no victors here. --Redrose64 🌹 (talk) 12:22, 3 February 2018 (UTC)[reply]
  • Now someone has mentioned a preference for including them even in stubs. I realise that is not the proposal but I'd love to know what the general experience of maintaining infoboxes may be. Of course, on stubs there is often very little that is verifiable and thus capable of populating the things but my own experience - mostly in the India/Pakistan topic areas - is that the things attract people who can't be bothered to read the article. They make changes to the box that contradict the sourced info in the article on a very frequent basis. I must make tens of reverts every week because of the sheer laziness and dumbing-down effect. Yes, I am sure that they can provide some useful overview for people who do not have three minutes to spare but even that is only the case if the information is correct, and there are plenty of GA articles that do not appear to have many watchers acting in a maintenance capacity. I often think that the infoboxes act as honeypots for "dumb" people: as A. E. Housman said, "Three minutes' thought would have told him he was wrong, but thought is irksome and three minutes is a long time". - Sitush (talk) 15:26, 30 January 2018 (UTC)[reply]
Any article is going to have problems with infobox information matching the body (heck, there's always going to be cross-article inconsistencies too). That's the problem of an open wiki, and not limited to only infoboxes. Yes, infoboxes are honeypots, but so are list/table articles or anything else where it is easy to add "data" without "prose". --Masem (t) 15:29, 30 January 2018 (UTC)[reply]
  • An interesting question on reading some of the opposes: we should list out reasons why a specific bio should not have an infobox in some cases, excluding the subjective "I hate infoboxes" arguments. Eg we can establish Homer as a case where there's just not enough validated information to make the infobox useful. I don't know other cases, but maybe there's something we can pull from those. --Masem (t) 17:06, 30 January 2018 (UTC)[reply]
  • As a reader, I often use infoboxes to quickly verify that I am on the right article. Even simple things like "occupation" and "known for" are useful for this. I would say that infoboxes should be encouraged unless there is an article-specific reason to exclude them. (The primary editors of a particular article not liking infoboxes is not an article-specific reason....) CapitalSasha ~ talk 17:55, 30 January 2018 (UTC)[reply]
  • A frequent comment from those that oppose infoboxes seems to argue that for some articles they're "not appropriate" however there seems to be little explanation as to why. It's often said matter of factly, like everyone will understand the argument, but I don't actually think that many people do. It'd be helpful to understand the issues so that these could be addressed rather than eveything going back and forth as it seems to now. --Deathawk (talk) 03:57, 31 January 2018 (UTC)[reply]
Well, I don't oppose infoboxes generally but I suppose I do oppose them being required for all (B-class) biographies. I raised the example of Homer (and Masem repeated the example) thinking people might understand why an infobox might not be appropriate in such a case. So, to spell it out, there are scarcely any broadly accepted "quick facts" (maybe none) known about the author. Anything substantial in an infobox is highly likely to be disputed for lacking nuance. Now, this article is C class (aren't these classifications almost arbitrary?) but I don't see why a "promotion" should require an infobox or why someone wishing to force an infobox merely needs to up-rate the article first. Thincat (talk) 08:45, 31 January 2018 (UTC)[reply]
I regularly explain why I don't think an infobox is suitable, generally due to layout (particularly on smaller articles with less than about 7K prose) or because the topic falls between two stock types. However, making a civil and well-reasoned argument against (and, indeed, for) an infobox never makes it to the WP:Drama boards, so people aren't really aware of it. Ritchie333 (talk) (cont) 17:20, 2 February 2018 (UTC)[reply]
  • A few comments on the discussion so far:
    1. There's a clear sense that articles on certain ancient figures (i.e. Homer) are better off without an infobox. That's an edge case that I'm sure can be fixed.
    2. Regarding "classical composers": I don't see a significant difference in presentation between Wolfgang Amadeus Mozart and George Frideric Handel, and yet technically only one has an infobox. I also don't understand why composers are different than authors or painters (beyond the obvious point that the editors on that WikiProject tend towards not including infoboxes).
    3. There is an open ARBCOM discussion (currently at WP:ARC) largely about infoboxes, and the general opinion from arbitrators appears to be that they would like the current infobox situation addressed through the RfC process. I feel the complaints about RfCs on this topic to be ignorable.
    power~enwiki (π, ν) 19:37, 31 January 2018 (UTC)[reply]


The Blade of the Northern Lights (話して下さい) 03:57, 4 February 2018 (UTC)[reply]

I think one compromise might be, to come up with an objective criteria for when an infobox is not appropriate, and then require that those articles that don't meet it to have them. I think a lot of the problem comes from those that feel that the people who don't want infoboxes are doing it simply because they don't like them or it makes the article look "messy". However there seems to be an opinion forming that some articles are not appropriate for them on an objective level. So my suggestion is let's kill the ambiguity and come up with a list of valid criteria for not having an infobox. --Deathawk (talk) 06:21, 4 February 2018 (UTC)[reply]

WikiProjects route

If it's not possible to get a consensus across the board for the bio articles. Then perhaps getting a consensus on a WikiProject by WikiProject basis would be more successful. For example: I imagine that WP:HOCKEY is alright with infoboxes in their bios. While WP:COMPOSERS would be opposed to infoboxes in their bios. GoodDay (talk) 20:23, 31 January 2018 (UTC)[reply]

But local consensus cannot over-ride community consensus? - Sitush (talk) 20:26, 31 January 2018 (UTC)[reply]
WikiProjects are usually given leeway. Though sometimes they can clash, when their interests overlap. GoodDay (talk) 20:29, 31 January 2018 (UTC)[reply]
So if the Biography wikiproject doesn't go for this, the entire thing would collapse? - Sitush (talk) 20:30, 31 January 2018 (UTC)[reply]
In this situation, my guess is that WP:BIO would merely reflect the desires of all the bio-related WikiProjects. A question to ponder though - Can one control all, or does all control one. GoodDay (talk) 20:39, 31 January 2018 (UTC)[reply]
To be honest, this entire situation strikes me as being similar to situations where politicians seek referenda and keep on seeking further referenda until they get the result that they want. - Sitush (talk) 20:33, 31 January 2018 (UTC)[reply]
Oh yeah. This scenario happened at Elizabeth II a few years ago. They kept having RM, after RM to finally get what the wanted -- the page moved from Elizabeth II of the United Kingdom to Elizabeth II. Of course, their view is that it's a done deal & therefore nobody should dare call for the page to be moved back to Elizabeth II of the United Kingdom. GoodDay (talk) 20:39, 31 January 2018 (UTC)[reply]
I wasn't aware of that scenario but, yes, it would appear to be an example. We're going off-topic now but it is an interesting issue, perhaps best discussed elsewhere. Consensus on a very specific Wikipedia issue can change and does. However, once it has gone through the first cycle, from A to B, does it ever revert to A? My suspicion is that usually it would not, if only because of the maintenance cost. But, as I say, this is OT. - Sitush (talk) 00:51, 1 February 2018 (UTC)[reply]
What community consensus would be overrided (assuming this rfc fails) if a wikiproject decides whether to include or disinclude infoboxes? Galobtter (pingó mió) 12:56, 1 February 2018 (UTC)[reply]
So what to do when projects disagree? See WP:ADVICEPAGE.--Moxy (talk) 13:03, 1 February 2018 (UTC)[reply]
I'd say at-least if an RfC is held..certainly not informal advice pages but an RfC can reasonably decide. There will be edge-cases of course. Galobtter (pingó mió) 13:09, 1 February 2018 (UTC)[reply]
If the broader community can not agree (ie reach consensus), then the question can certainly be devolved to the project level... and if a given project can not agree then the question devolves to the “article by article” level. And if the editors at a given article can not agree, policy says to fall back on “status quo”. Blueboar (talk) 13:22, 1 February 2018 (UTC)[reply]
But there is a consensus at present. The consensus is to treat on a case-by-case basis. - Sitush (talk) 15:01, 1 February 2018 (UTC)[reply]
I think MOS-style guidelines for consistency would be helpful - not to make infoboxes mandatory, but how they should be used. (As we have for images, punctuation and everything else). For example some articles have two infoboxes, or a large sidebar + infobox. The infoboxes can become overwhelmed with overly detailed statistics, they can become so long that images in the first section of the article don't appear, or it spills over into multiple sections of the article. It creates an unpolished appearance and it is a major ordeal to have even a simple discussion about collapsing sections because a lot of the time POV information is added to the boxes by accounts of dubious provenance who are willing to edit war over it. The situation is out of control, and I think there is a need to reign it in with some style guidelines. Seraphim System (talk) 01:13, 2 February 2018 (UTC)[reply]
Galobtter, saying that "WikiProject Me And My Friends" gets to decide whether to put an infobox on articles that I and my wiki-friends care about overrides the community consensus that infobox decisions are to be made article-by-article, and the principle that WikiProjects don't WP:OWN the pages that they're interested in improving. Also, we've already had significant fights (WikiProject Composers is the classic example, although not the only one) between groups whose members happen to like or dislike infoboxes on "their" articles, or who prefer one infobox over another. Letting self-appointed members of self-created groups determine rules for articles has been a source of significant disputes in the past. Also, the rule is that every group has absolute control over the articles that they want to improve, which means that Wikipedia:WikiProject Infoboxes could declare all articles within their scope (and then editors who disagree could form "WikiProject Lead Improvement", declare the same scope, and make the opposite decision). It's really not functional. WhatamIdoing (talk) 19:12, 2 February 2018 (UTC)[reply]
​Of course not; I was more meaning that we could have RfCs on whether a class of articles (generally linked to a wikiproject) could have or not have infoboxes. Galobtter (pingó mió) 04:22, 3 February 2018 (UTC)[reply]
A "subject matter route" might work out well. Very few people object to (normally/IAR/best judgment applies) having infoboxes on articles about diseases, for example, and I expect that such an RFC would pass easily. OTOH, the areas that would pass easily are the ones where disputes already aren't happening now, so I'm not sure if it would really make a difference in practice. WhatamIdoing (talk) 16:10, 5 February 2018 (UTC)[reply]

Homer Objection?

Homer
Roman bust of Homer from the second century AD, portrayed with traditional iconography, based on a Greek original dating to the Hellenistic Period

@Masem: assuming we treat Homer as a biography and not mythology, an infobox with nothing in it but the subject's name (article title) looks like this, exactly like the present article. In no way does such an infobox cause harm or mislead, at least anymore than the current picture in the article, right? Alanscottwalker (talk) 14:27, 2 February 2018 (UTC)[reply]

If that all that it would show, that would be fine. But as I write this and look at the wikicode for the infobox, there's all these tempting empty template fields that are the honeypots that editors unfamiliar with the topic area will want to be filling in, meaning constant maintenance on those. It is much better in such situations simply to have the same image and caption but without the infobox field. --Masem (t) 14:30, 2 February 2018 (UTC)[reply]
The obviuous compromise then to make every-thing subject to editorial discretion, except box/name/there will be some kind of caption (cap perhaps info artist/photog/date)" Everyone gets what they want, right? Alanscottwalker (talk) 14:46, 2 February 2018 (UTC)[reply]
From above , I think there are a set of intelligent rules where infoboxes should be used (eg where the person falls into a data-heavy field like sports, politics, etc.), where they shouldn't (where there's a lack of data like for Homer), and then a relatively broad grey area that should be handled case-by-case, but I need to think how to flesh those rules out better to provide that. --Masem (t) 14:53, 2 February 2018 (UTC)[reply]
Well sure, the rule compromise I have suggested, would only go for articles with images of the subject, but it extrapolates from the "consensus" we already have: 1) Almost everyone seems to agree that an image belongs upper right, if one is available; 2) Everyone already is forced to agree on the name(title); 3) everyone already has to reach agreement on any details (but never form: TITLE;LEAD;SECTIONS;REF). If we want to come up with "rules" or guides for other info in the box, we could then do so. Alanscottwalker (talk) 15:05, 2 February 2018 (UTC)[reply]
I think adding (according to tradition) for a lot of stuff in the Homer article and other similar cases, as I did with the Ariwara no Narihira article, would be a good idea; with, say, Jesus doing so would be problematic because of the insanely large number of conflicting traditions, but including a few legendary, probably counter-factual details, nuanced so such is obvious, does not seem entirely inappropriate for "historical" figures about whom very little is known. Hijiri 88 (聖やや) 22:24, 2 February 2018 (UTC)[reply]
  • All the infobox templates have fields that can act as honeypots for POV editors to add material that is usually inappropriate. We need better instructions about when to use them. And there are always going to be bios where even some of the standard fields may be inappropriate. None of this is an argument against using them generally. The way to handle exceptions is wording such as "normally", or "unless there is some special reason to do otherwise". IAR remains the fundamental policy of WP. DGG ( talk ) 06:00, 3 February 2018 (UTC)[reply]
    Virtually all infoboxes are constructed in such a way that leaving a parameter blank, or having it contain only a HTML comment, is treated in the same manner as omitting it entirely, so the example at the top of this subsection could have been constructed as 
    {{Infobox person
| name          = Homer
| image         = Homer British Museum.jpg
| caption       = Roman bust of Homer from the second century AD, portrayed with traditional [[iconography]], based on a Greek original dating to the [[Hellenistic Period]]
}}
    and it would look exactly the same. The omission of unused parameters will be less of a honeypot. If somebody later comes along with something valid that could be added - such as a death date that has been verified by reputable historians - the appropriate parameter may then be added. When adding infoboxes to articles, I usually remove unused parameters; I only leave them present when I don't have the information but feel that there is a reasonable chance that somebody else does have it. --Redrose64 🌹 (talk) 11:31, 3 February 2018 (UTC)[reply]
  • It's too bad we couldn't harness this honey-box effect to populate Wikidata. Infoboxes and Wikidata are the same thing - a key:data database. But infobox users generally don't care about Wikidata, they just want to enter data up top article space. -- GreenC 05:12, 4 February 2018 (UTC)[reply]

Well, speaking as a member of WikiProject Classical Greece & Rome, which is concerned with the article about Homer, there would be one good use for Infoboxes: to provide reference information to the relevant article in Realencyclopädie der classischen Altertumswissenschaft & Prosopographia Imperii Romani for the subject. (A third field would be the tribe a Roman belonged to -- which is important when known, but can only be added in a clumsy way to a given biographical article.) The way these two important reference works are organized, it is a challenge to find biographical articles on certain people. For example, to find the article on Julius Caesar, one must skim through hundreds of articles having the title "Iulius" & a number; even for people fluent in German, this is a pain. However -- & this is an important point -- the Infobox person template does not include a field to add these referents to. And without this feature, I feel this template is of little use to our WikiProject -- so I don't see any support for Infoboxes from us. -- llywrch (talk) 18:39, 8 February 2018 (UTC)[reply]

Amendment to WP:ALSO regarding vital article permissibly

I'd like to propose vital articles should be excepted from style rules limitations on the rationale of promoting convenient navigation to and from exceptional articles. Currently they state: "As a general rule, the "See also" section should not repeat links that appear in the article's body or its navigation boxes." This generally implies there is no comparative example, and I'd like vital articles to be this comparative standard in order to define the rule's specific meaning. For example, "As a general rule, the "See also" section should not repeat links that appear in the article's body or its navigation boxes with the exception of any vital articles." My Wiki work mostly revolves around overseeing these particular articles and I would much appreciate their universal accessibility -- it would, I feel, be beneficial if all those articles were part of a perceptibly underlying network. Additionally, regarding the potential question of the "See also" section's validity, I would urge consideration of different site browsing styles meaning some users are drawn to the easy nature of this section and use it widely. Thanks. - Thrif (talk) 03:14, 1 February 2018 (UTC)[reply]

  • Oppose I don't see any value in listing River in the see also section on the Yangtze article, or anything similar. power~enwiki (π, ν) 03:19, 1 February 2018 (UTC)[reply]
  • Oppose It's pointless to list common words like China and River, whether in the See also section or not. See WP:OVERLINK. -Zanhe (talk) 03:23, 1 February 2018 (UTC)[reply]
  • Oppose see also sections should be avoided as much as possible. Navigation templates could include related links. But many vital article titles are so well known that they do not need to be linked. A link in an article should do for some use, and often then that will do. Graeme Bartlett (talk) 00:13, 2 February 2018 (UTC)[reply]
  • Oppose. Aside from anything else, WP:VITAL is a totally arbitrary list made up by the half-dozen people who run it; the article that's "vital" to any given reader is the article about whatever topic they're looking for, not the article a self-appointed clique feel is more important than the article about whatever topic they're looking for. ‑ Iridescent 19:20, 2 February 2018 (UTC)[reply]
  • Oppose: That list is massive. Level Five alone intends to have fifty thousand articles. You say your concern is that you want an "underlying network" but that underlying network exists, and it's inherent to the Wiki format My other concern is that the articles subject don't always warrant a "See Also" to an vital article. If someone just met Mohammad Ali in passing, than it would be inappropriate to create a "See Also" link to them. --Deathawk (talk) 06:00, 5 February 2018 (UTC)[reply]
  • Oppose If those words are already in the article there is nothing to prevent a reader from clicking on the link at that spot. Scrolling back to it takes but a moment. The "search wikipedia" box is also always available. MarnetteD|Talk 06:12, 5 February 2018 (UTC)[reply]

RFC: Is “(anime)” a suitable disambiguator?

In general, should articles about anime media use the disambiguator (anime), rather than more general ones like ([animated] TV series) or (film) or, more broadly, (franchise)? There is some disagreement over whether an earlier discussion, WP:VPP#RfC: Is "telenovela" a suitable disambiguator? (permalink), is applicable.

Sub-question: Should Wikipedia:Naming conventions (anime) be created? —67.14.236.50 (talk) 05:16, 1 February 2018 (UTC)[reply]

(anime) responses

  • Oppose (as nom). I agree with the participants of that earlier discussion, where this was only brought up as an example of what not to do: Why are these exceptions just because they originate in non-English countries/languages? The argument that this is a "format" vs a genre is flawed as no one can define this "format" in a way that doesn't also fit other (TV series) unless you bring up language, storyline types, or run length - all of which could apply to any other TV series. None of these is sufficient. —67.14.236.50 (talk) 05:21, 1 February 2018 (UTC)[reply]
  • Oppose only anime people think anime is more recognizable than having "tv series" in the name, which is what used in more general sources. Galobtter (pingó mió) 05:56, 1 February 2018 (UTC)[reply]
  • Oppose/No (anime) as a disambiguator should be deprecated. We should not use a specialized word that vaguely defines a particular genre from a single country. Those anime that aired on TV or are release on home media exclusively and arranged as a television series into seasons/episodes should use (TV series). Those that are single productions (aka short films, films, most OVA, etc.) should use (film). For this reason, there is no need for a new/additional naming convention, as all disambiguation within the anime/manga genre can be covered in existing naming conventions. MOS:ANIME can just summarize this on for convenience while linking to the fuller NCs. -- Netoholic @ 06:24, 1 February 2018 (UTC)[reply]
  • Comment regarding using "(film)" for OVAs: No. They are not films. They are always direct to video releases, and many are serials (meaning they are released in multiple parts). They should not ever be disambiguated as "(film)". In the same vein, they are not TV series, either, as they are never aired on TV as their first release. Disambiguating them as "(TV series)" when they are not TV series would only confuse people, in addition to being flat out incorrect. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 07:25, 1 February 2018 (UTC)[reply]
    • How is a direct to video release of a serial anime any different to a production like The Crown or The Man in the High Castle, only released online by a streaming service? Those shows have not been produced/released as broadcast TV series either, but there's no confusion around calling them TV series.--Nilfanion (talk) 07:59, 1 February 2018 (UTC)[reply]
    • WP:NCTV also supports the use of (serial), if that's more appropriate. -- Netoholic @ 10:15, 1 February 2018 (UTC)[reply]
      • That may work for OVAs that have more than one episode. It won't work for singles. Again, any reliable source will refer to them as either a video series or an OVA, so per WP:V, that's what we need to call them. Using "(film)" or "(TV series)" will only confuse people as no reliable sources anywhere will refer to them that way. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 18:42, 1 February 2018 (UTC)[reply]
        • A TV series is something viewed on a television screen not broadcast on a television channel - that's why direct-to-video and streaming-only shows are treated as such; all episodic anime would fall into that group. "Film" can naturally apply to any media that isn't a series. That necessarily includes any animes that are not over multiple episodes. WP:V is primarily about article content, not article naming. Furthermore, reliable sources will call the Witchblade produced in 2006 "anime", they will not ever refer to it as "Witchblade (anime)" - just "Witchblade". The addition (anime) is an artificial construct backed up by zero sources, it is only used out of necessity due to the way Wikipedia works - the same would be true of any other term.--Nilfanion (talk) 19:18, 1 February 2018 (UTC)[reply]
          • Using your logic, watching the Star Trek film series on a TV would make it a TV series. I would be fine using "(series)" for OVA series, and using "(film)" for any standalone OVA would also be fine. I absolutely oppose using "(TV series)" for any OVA as that makes no logical sense. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 19:38, 1 February 2018 (UTC)[reply]
            • At the time of release, it was not possible to watch any (let alone all) of the Star Trek movies on a television screen. But here’s a converse that actually happened: The Day of the Doctor, a Doctor Who television episode that was simulcast in movie theaters, could be considered a film under this logic, even though it’s primarily a TV episode. —67.14.236.50 (talk) 23:05, 1 February 2018 (UTC)[reply]
              • Yes, but disambiguating it as "The Day of the Doctor (TV series)" wouldn't make any sense. Since it's a TV film, it would be "The Day of the Doctor (film)" (if this title needed disambiguating at all). As for your argument regarding the Star Trek films, my point still stands. Nilfanion stated that a "TV series is something viewed on a television screen not broadcast on a television channel". Technically, his argument is also invalid, since anything broadcast on a TV channel is also something which is (or can be) viewed on a TV screen. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 23:31, 1 February 2018 (UTC)[reply]
                • Why “film”? It’s a TV episode (so use “TV episode”). My whole point was that calling it a “film” falls into the same flawed logic as calling a home-video serial a TV series. —67.14.236.50 (talk) 23:58, 1 February 2018 (UTC)[reply]
        • If an OVA is only one "episode", then its a (film) - regardless of length ie, short film, feature length, or epic all use (film). -- Netoholic @ 20:15, 1 February 2018 (UTC)[reply]
  • Oppose per Netoholic. As noted the need for consistency is the primary factor in choice of disambiguator, not the common name. I see no reason to have "anime" when "TV series" and "film" are perfectly adequate. That's no different to always using "video game" over "arcade game" and "computer game" (which strictly speaking are more accurate for games that have only ever been in those formats).--Nilfanion (talk) 07:59, 1 February 2018 (UTC)[reply]
    • So you are willing to forgo truth and accuracy over consistency? There is a reason why Common name is a policy here. — Preceding unsigned comment added by Knowledgekid87 (talk • contribs) 08:18, 1 February 2018 (UTC)[reply]
      • We already do that for the "TV" shows I mention above, along with any other original production for a streaming service. A direct-to-video series is still a TV series. WP:COMMONNAME is not about the choice of disambiguator, it is about the primary title itself - as in the bit before the parentheses. With other classes of video productions its unusual to use "TV series", you'd more commonly refer to it using a genre-based label "soap opera" or "drama" or whatever. For consistency we don't use those more common descriptions, preferring the overall "TV series". That also reduces arguments about edge-cases, like an anime version of Who Framed Roger Rabbit.--Nilfanion (talk) 08:24, 1 February 2018 (UTC)[reply]
      • WP:COMMONNAME rules for the main, undisambiguated, part of the title because that is what the real world refers to it as. WP:CONSISTENCY rules the disambiguator because that is how Wikipedia internally handles duplicate articles for technical reasons. -- Netoholic @ 10:25, 1 February 2018 (UTC)[reply]
  • Oppose per Netoholic. And the general public just refers to these things as cartoons, specifying "Japanese cartoons" if they feel the need for clarification.--Khajidha (talk) 12:05, 1 February 2018 (UTC)[reply]
  • Keep dabs per WP:NCCDAB & WP:ATDAB as outlined in the arguments presented at Wikipedia talk:Manual of Style/Anime- and manga-related articles#Parenthetical disambiguators. - Knowledgekid87 (talk) 14:26, 1 February 2018 (UTC)[reply]
  • Oppose for the reasons that Netoholic gives. The desire to use anime in the title seems almost to be a fancruft thing, as indeed is the content at many of those articles. - Sitush (talk) 15:05, 1 February 2018 (UTC)[reply]
  • Keep dabs Most of the (anime) articles could be converted to (TV series) in titles, however redirects will still need to be preserved for (anime) as these have been proven to be useful search terms. WP:RFD#KEEP #3 (aid searches on certain terms), and #5 (Someone finds them useful). People will want to look up Pokemon (anime) or Pokemon anime even if it goes to Pokemon (TV series). Further disambiguations may be necessary such as with Aladdin (animated TV series) and Aladdin (Indian TV series). Direct-to-video titles may have to dab to (series), (film series), (video series), (web series), but they should not be called TV series if they aren't released as such in their primary market. It also means more "redirects here" hatnotes. Example Witchblade (TV series) currently points to the TNT series aired in 2001-02 while Witchblade (anime) points to the anime series aired in 2006. If you want to make Witchblade (2001 TV series) and Witchblade (2006 TV series), that's fine, but then the hatnotes will have to say "this is the live-action version, for the anime see 2006" and "this is the anime version, for the live-action one see 2001". With (anime) the second hatnote is not necessary as the title as well as the lead paragraph already describe it. AngusWOOF (bark • sniff) 16:28, 1 February 2018 (UTC)[reply]
    1) There's lots of non-standard disambigs that make good search redirects, I don't see how that affects anything here. 2) Why would you use "anime" instead of "animated" to contrast with "live-action"? --Khajidha (talk) 16:48, 1 February 2018 (UTC)[reply]
    In the case of Witchblade, it was originally an American comic book series, so if someone saw "this is about the animated TV series", they might think there is an American comic book cartoon, so then you'd have to specify "Japanese-animated" and then you'd might as well use anime. AngusWOOF (bark • sniff) 17:07, 1 February 2018 (UTC)[reply]
    That isn't something that needs to be clarified in the disambiguation, that's what the article text is for. There's probably all sorts of misunderstandings that could be taken from just reading disambigs without reading the articles, but that isn't something we really need to worry about. --Khajidha (talk) 17:29, 1 February 2018 (UTC)[reply]
    What is wrong with using a disambiguation that is used by a majority of sources, and is easily identifiable? There is a need to clarify as in some cases you are talking about oranges versus apples. - Knowledgekid87 (talk) 18:00, 1 February 2018 (UTC)[reply]
    It isn't easily identifiable to most readers. And I question whether it is used in the majority of sources about animation in general or TV/films/video in general or just in anime-centric sources. It is jargon and (at best) only borderline English. And your "apples and oranges" comment seems misplaced as you are proposing the use of "OVA" as a disambig to separate one Japanese cartoon from another, which would be a "types of apples" thing. --Khajidha (talk) 16:05, 5 February 2018 (UTC)[reply]
    It's something to worry about for the disambiguation page entry and the hatnote, as it would greatly facilitate the searcher who is trying to figure out how to select their desired show. See Peyton List, with two actresses whose birth years can get confused. AngusWOOF (bark • sniff) 19:12, 1 February 2018 (UTC)[reply]
  • No. Per pretty much everyone. Note that this does not in any way impede the creations of (anime) redirects. Headbomb {t · c · p · b} 17:26, 1 February 2018 (UTC)[reply]
  • No Disambiguate by form of media, not genre. (TV series) or (film) is sufficient. --Jayron32 19:19, 1 February 2018 (UTC)[reply]
  • I've notified WP:DAB AngusWOOF (bark • sniff) 19:53, 1 February 2018 (UTC)[reply]
  • As for the second question of whether we need Naming Conventions for anime, that depends on whether MOS:ANIME is good enough to indicate naming conventions. If it's not, then let's get some created. AngusWOOF (bark • sniff) 17:20, 2 February 2018 (UTC)[reply]
  • Oppose: DABs must always be as general as possible. (film) or (TV series) are thus prefereable DABs, followed by (animated film)/(Japanese film) and (animated TV series)/(Japanese TV series) ... (1967 animated Japanese film) ... (anime) would be appropriate in only the edgiest of edge cases. Curly "JFC" Turkey 🍁 ¡gobble! 23:57, 4 February 2018 (UTC)[reply]
    @Curly Turkey: Are you thinking of a specific article with (1967 animated Japanese film)? I can't imagine any article where four parenthetical disambiguators would be preferable to simply using the native title, especially when most anime from the 1960s are really only known in English-speaking countries to specialists and fans who would be more likely than the general public to know the Japanese title, like we did back in 2013. Hijiri 88 (聖やや) 10:38, 6 February 2018 (UTC)[reply]
    No, that was just an off-the-cuff example for something that might need some ridiculous amount of disambiguation. Imagine there were both an animated and non-animated Black Jack film in Japan in the same year that there were a British film called Black Jack—not likely, but ありえる with such a generic-sounding title. Curly "JFC" Turkey 🍁 ¡gobble! 11:18, 6 February 2018 (UTC)[reply]
  • Comment - What bothers me here is the "I think it fits..." type of responses here. Wikipedia is not a place for original research, we should be following what the reliable sources say rather than try to label and define what anime is and should be labeled under. - Knowledgekid87 (talk) 14:35, 6 February 2018 (UTC)[reply]
    • Knowledgekid87: anime is animation (and in fact is short for animation). Claiming otherwise doesn't even amount to WP:OR—it's counterfactual. We thus default to (animation). Give us a concrete example of when (anime) would be required when when have (animation) and (Japanese animation) to fall back on. Without resorting to OR, please. Curly "JFC" Turkey 🍁 ¡gobble! 22:44, 6 February 2018 (UTC)[reply]
      Oh geez, let's not argue about defining anime by the Japanese definition, otherwise you'll get The Simpsons as anime. AngusWOOF (bark • sniff) 02:51, 7 February 2018 (UTC)[reply]
      AngusWOOF: "animation" is English, and the jargon anime is animation. Thus we use (animation) and not (anime). Nobody has "argue[d] about defining anime by the Japanese definition"—we've argued not to use jargon when plain English does a better job. Curly "JFC" Turkey 🍁 ¡gobble! 03:08, 7 February 2018 (UTC)[reply]
      No, in English Anime is strictly referred to as Japanese animation. There is no jargon here if the term is widely known which it is. - Knowledgekid87 (talk) 03:13, 7 February 2018 (UTC)[reply]
      Knowledgekid87: it's not anywhere near as widely known as you'd like, and regardless, DABs are required to be as general as possible, and all anime is animation—"animation" takes precedence over "anime" regardless of whether it's "jargon" (which it is). Curly "JFC" Turkey 🍁 ¡gobble! 03:20, 7 February 2018 (UTC)[reply]
      @Curly Turkey: Anime, like karaoke and kamikaze, is widely accepted as an ordinary English word. Check your dictionary of choice; mine defines it as a style of Japanese animation. So it’s not a question of jargon; it’s a question of whether we otherwise disambiguate based on filming/animation style. As far as I know, we do not. —67.14.236.50 (talk) 00:35, 8 February 2018 (UTC)[reply]
      I have no idea what you're trying to get at. Whether it's in the dictionary is irrelevant—most words in the dictionary are unknown to most people. Anime does not have anywhere near the recognition amongst average people that karaoke and kamikaze do, but that's also utterly irrelevant—all anime, without exception, is animation, and DABs mmust be general—(film) takes precedence over (documentary), for instance, and (animation)/(animated), of course, takes precedence over any genre or style of animation. Curly "JFC" Turkey 🍁 ¡gobble! 01:31, 8 February 2018 (UTC)[reply]
      Agreed, absolutely; I only disagreed with one of your premises, not your conclusion. You’d never see something like Home Movies (squigglevision). At least, I hope not. If I do, I’m giving up on Wikipedia. —67.14.236.50 (talk) 02:41, 8 February 2018 (UTC)[reply]
  • Oppose – We should not disambiguate TV programming by genre in all but exceptional cases. As redirects is fine. But the base articles should reside at disambiguation using "(TV series)" not by "(anime)". --IJBall (contribs • talk) 05:27, 8 February 2018 (UTC)[reply]
  • Oppose. We should not be disambiguating by genre unless all other disambiguation options are exhausted. --woodensuperman 16:45, 9 February 2018 (UTC)[reply]


What about OVAs?

A large part of the pro-“anime” rationale is that OVAs, released directly to physical media (VHS, DVD, BD), are not rightly TV series, although they are often episodic. If (anime) is discouraged, how should these be disambiguated? (OVA)? (DVD series)? Something else? —67.14.236.50 (talk) 23:15, 1 February 2018 (UTC)[reply]

I already addressed this above. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 23:24, 1 February 2018 (UTC)[reply]
You would use an unqualified (series)? Then how would we disambiguate it from a related series that aired on TV? I would go for (serial), as mentioned in the same thread I think you’re referring to. —67.14.236.50 (talk) 23:50, 1 February 2018 (UTC)[reply]
Using (serial) would be fine, though it's more of a poe-tay-toe/poe-tah-toe thing from my view. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 19:10, 2 February 2018 (UTC)[reply]
One thing to keep in mind is that this whole discussion actually affects very few articles. Anime usually have very distinct names which help avoid the need to disambiguation. Mostly, you're just disambiguating between the original manga and its adaptations. Non-Japanese direct-to-video animation has this same issue (see Batman: The Dark Knight Returns (film)) and if we can use existing naming conventions for those productions to solve the problem, so can we use them for anime.
  • If arranged using the season-episode paradigm, use (TV series). Home media is designed for television, its just a different medium of delivery. The same goes for ONAs (web series).
  • If its a single production, use (film). This is true regardless of run-time (short films are films too), and even if the film is split into parts due to the format.
  • (miniseries)/(serial) is also available if the release is a single production split into several episodes like a miniseries.
I believe all can be handled by careful consideration of existing naming conventions at WP:NCTV and WP:NCFILM. -- Netoholic @ 23:37, 1 February 2018 (UTC)[reply]
This. So much this. --Khajidha (talk) 14:29, 2 February 2018 (UTC)[reply]
  • Comment I'm neutral on the main RFC question, but this side-question struck me as a bit of a non sequitur since, in reality, hardly anyone in the English-speaking world watches anime either on broadcast television or in a movie theatre, so OVAs are not formally different for said audiences (who are also the main readership of English Wikipedia) just because their original Japanese release was in a different format. Most OVAs are either (a) straight-to-video movies (which I'm pretty sure we already classify as "films" for disambig purposes -- correct me if I'm wrong) or (b) episodic television series that were meant to be viewed on a television by means of a VCR or DVD player, as opposed to via broadcast. The latter group may have been different from the rest of what we categorize as "TV series" in their original Japanese release, but are not different from regular animated Japanese TV series from the perspective of the majority of English Wikipedia's readership. And in reality, if the distinction between Japanese OVAs, Japanese animated films and Japanese animated television series is substantial enough to raise a concern, the same problem would be had by lumping them all under the "anime" label. Hijiri 88 (聖やや) 00:02, 2 February 2018 (UTC)[reply]
  • Would (video series) be acceptable? Video encompasses most of the formats including VHS, Laserdisc, DVD, Blu-ray, and video on demand services. (OAV), (OVA), (OAD) would still serve as useful redirects where appropriate, since that is how they are commonly known in the original media as distributed. AngusWOOF (bark • sniff) 17:30, 2 February 2018 (UTC)[reply]
  • (animated series)? Curly "JFC" Turkey 🍁 ¡gobble! 00:00, 5 February 2018 (UTC)[reply]
    • Only if “[video] series” is too ambiguous. I’m still iffy on using “series” alone to refer to anything. —67.14.236.50 (talk) 00:40, 5 February 2018 (UTC)[reply]
      • I'm not sure it's a good idea to tie these things to a particular medium ("video"). Twenty years from now you'll be more likely to consume these things online or as downloadable content than on a spinning platter. However they get served, they'll always be "animated". Curly "JFC" Turkey 🍁 ¡gobble! 00:51, 5 February 2018 (UTC)[reply]
        • Animation is always video, so it’s implied. By “video,” I don’t mean a physical medium; I mean the medium of a sequence of still images shown in rapid succession on literally any device with a screen. But if we call something a “series” (of what?) that could be a book series, a film series, a series of entrepreneurial failures, a series of potholes on a road… the word’s just unworkably broad to use as a standalone dab, IMO. “Video series” is unambiguous in cases where “animated series” is more precise than necessary. —67.14.236.50 (talk) 01:13, 5 February 2018 (UTC)[reply]

Then I ask again: What dab would you suggest for a non-TV episodic audiovisual series that may or may not be animated? A series, yes, but a series of what? —67.14.236.50 (talk) 04:22, 5 February 2018 (UTC)[reply]

Give us a real-world example of some such series that actually needs to be DABbed before we start wringing out hands over it. We use DABs to solve actual problems, and the default is to avoid using them at all. Curly "JFC" Turkey 🍁 ¡gobble! 06:54, 5 February 2018 (UTC)[reply]
Following the precedent of Bibleman, it would appear that such would be categorized as television programs and described as "direct-to-video" releases. Either of these would be fine as the disambiguation. Aside from the aforementioned objection to OVA as jargon, it could even be argued that the usage of isolated English words and phrases by a Japanese company does not really fall within the limits of "use English". --Khajidha (talk) 15:32, 5 February 2018 (UTC)[reply]
How about Giant Robo (OVA)? It's a direct-to-video series, released on a not so regular schedule. It wasn't formatted for television. It's one of the old ones where it was released direct-to-video from the get go, i.e. not one of these new "web series" or on demand-released TV series like Devilman Crybaby. The main series already has a TV series. Gatchaman (OVA) would be another direct-to-video series. Again, released in the 1990s, and not associated with any new "web series" / on-demand released series. Appleseed (OVA) on the other hand could be considered more of a film as it's featured length 66 minutes. AngusWOOF (bark • sniff) 01:39, 6 February 2018 (UTC)[reply]
Seems like film series would apply.--Khajidha (talk) 10:20, 6 February 2018 (UTC)[reply]
Afteranother look at the articles I'm not sure where you get the idea that they weren't formatted for television. Seems to the idea was to make a tv series sold directly to the consumer. --Khajidha (talk) 12:23, 6 February 2018 (UTC)[reply]
Oppose for all the reasons already given. (OVA) will be archaic, jargon, and inaccurate twenty years from now when it's no longer consumed as a series of tapes or DVDs. The physical means of delivery should not be used as a DAB, nor should specialized jargon—we have this problem with Giant Robo (tokusatsu) as well. Curly "JFC" Turkey 🍁 ¡gobble! 11:24, 6 February 2018 (UTC)[reply]
Please don't start going into "will be" here per WP:CRYSTAL. I said it before and I will say it again, I think we should follow the name most used in WP:RS to avoid any WP:OR. - Knowledgekid87 (talk) 14:32, 6 February 2018 (UTC)[reply]
Knowledgekid87: did you just accuse me of OR for suggesting it be called (animated series)? We do not use obscure jargon in DABs, so (OVA) is unaccaeptable no matter what irrelevant WP:ALLCAPSGUIDELINE you link to. Curly "JFC" Turkey 🍁 ¡gobble! 22:39, 6 February 2018 (UTC)[reply]
I agree It has to be classified by its original format. It's not a TV series back then, but a direct-to-video series. Interpreting it by 2018 'on demand' standards like TV series because it would have been on Netflix would be WP:OR and WP:SYNTH. AngusWOOF (bark • sniff) 15:11, 6 February 2018 (UTC)[reply]
If it wasn't a TV series back then, then just how did the producers expect the purchaser to view it? Telepathically? It was a TV series released directly to the viewer. ---Khajidha (talk) 15:25, 6 February 2018 (UTC)[reply]
Khajidha: "how did the producers expect the purchaser to view it? Telepathically?": Irrelevant. We don't DAB old record albums with (LP)—the method of delivery should not be used as a DAB. Curly "JFC" Turkey 🍁 ¡gobble! 22:50, 6 February 2018 (UTC)[reply]
I would find a source to figure out the format rather than saying that this is x because I know it is x. - Knowledgekid87 (talk) 15:43, 6 February 2018 (UTC)[reply]
It's released as a direct-to-video, so that's how the purchasers view it. Then at some point there's enough interest based on sales of the video, they make more videos. Like List of VeggieTales videos and The Wiggles videography. Those franchises have TV series later on, but their original series of videos are not television series. so (video series) or Giant Robo (1992 video series) would be a better disambiguator than TV series. AngusWOOF (bark • sniff) 18:40, 6 February 2018 (UTC)[reply]
This would be like arguing how the Tom and Jerry film shorts should be reclassified as a TV series because newsreels on film are an obsolete media format, and that those cartoon shorts are actually episodes because they are shown as episodes in later bundles of the show for television purposes. AngusWOOF (bark • sniff) 18:46, 6 February 2018 (UTC)[reply]
AngusWOOF: "... reclassified as a TV series ...": don't be absurd—I explicitly argued against DABbing by delivery format. Curly "JFC" Turkey 🍁 ¡gobble! 22:39, 6 February 2018 (UTC)[reply]
The claim that it's not a TV series because it was released on video first is flawed, as I discussed above. If it's viewed on a TV, then it can be reasonably called a TV series. And that's Japan; most of English Wikipedia's readership can't meaningfully distinguish between Japanese series that were originally released on video and watched on a TV and Japanese series that were originally released via broadcast and watched on a TV, since most of them are only really available on video to begin with. Or streaming, but we refer to Netflix original programming as "TV series" anyway. Hijiri 88 (聖やや) 20:33, 6 February 2018 (UTC)[reply]
The problem with calling it a (TV series) is that then you get major confusion when there are regular TV series that follows. Like with Tenchi Muyo Ryo-Ohki which showed as 2 OVA series, followed by the "first TV series" Tenchi Universe, also referred to as Tenchi Muyo TV1 and a "second TV series" Tenchi in Tokyo, also referred to as Tenchi Muyo TV2. Now if the series did not have unique names, it would be incorrect to call Ryo-Ohki "Tenchi Muyo (1992 TV series)" or make awkward statements saying it was the third TV series overall and the second to be shown on Japanese television. At least using a disambiguator like (1992 video series) it's more helpful. AngusWOOF (bark • sniff) 03:08, 7 February 2018 (UTC)[reply]
@AngusWOOF: All titles must be fully disambiguated, though, so if there is one broadcast television series and one television series that was originally released via straight-to-video, streaming or other, unless the latter is the PRIMARYTOPIC and needs no disambiguator, we can't disambiguate the former as "(television series)", even if some Wikipedia editors and sources (sources on Japanese media written by people who don't read Japanese are not "reliable", mind) insist that the latter is not a television series for some reason. The case you describe is very specific -- how many instances could there really be when they came out the same year? The fact that your specific example doesn't need disambiguation because they all have different names is quite telling, and I don't think any really critical situations are likely to exist. If they do, then they can be dealt with case-by-case, either with a unique solution to a unique problem, or maybe even falling back on a disambiguator we are formally deprecating. Hijiri 88 (聖やや) 05:13, 7 February 2018 (UTC)[reply]

Disambiguation using (OVA), even moreso than (anime) above, should be swiftly deprecated due to it being a jargon-y word used within the fandom for this specific genre and doesn't conform to how similar media in other countries is disambiguated. Existing methods on WP:NCTV and WP:NCFILM should be used, and each case will have to be looked at individually, as (TV series), (film), (serial), etc. could apply to any of them. No one, I think, is advocating for any one-size-fits-all solution, so arguments that (TV series) doesn't apply to Such-and-Such is a distraction - people just don't want this particular fandom to be an exception anymore. Once this closes, the anime wikiproject can work through them, finding the right disambiguation among the existing NCs that fits. I expect a healthy number of the most complicated ones will have to hit the WP:RM process. That's fine. -- Netoholic @ 21:22, 6 February 2018 (UTC)[reply]

What do you mean by "swiftly deprecated"? Are you trying to discourage it from being used in general? Or just for article titles? You'll get much more resistance over the general especially for RFD purposes. No, it should not be condemned or swifty deprecated. That makes it sound like editors have done some heinous actions. AngusWOOF (bark • sniff) 23:26, 6 February 2018 (UTC)[reply]
@AngusWOOF: - I was only speaking about the use of (OVA) as a disambiguator. That's the scope of this RFC, the usage in article text is up for future discussion. -- Netoholic @ 05:41, 7 February 2018 (UTC)[reply]
Well, I would honestly argue against its being used inline atnall, if that was a hill I wanted to die on, since, like I said above, it's ungrammatical wasei-eigo that anime fans (most of whom don't know Japanese and so don't understand the confusion over countable and uncountable nouns) use in their fan publications, but is unlikely to appear in, say, Monumenta Nipponica even in an article discussing contemporary Japanese straight-to-video animation. So it really depends on what KnowledgeKid and some others have been calling "reliable sources". Hijiri 88 (聖やや) 23:35, 6 February 2018 (UTC)[reply]
It certainly shouldn't be dropped into text without at the very least a gloss as to what it means. "Banana yori Mango is an OVA series from Dai-Nippon Entertainment" is an example of how it should never, ever be used. Curly "JFC" Turkey 🍁 ¡gobble! 01:19, 7 February 2018 (UTC)[reply]
We are getting off topic here, the discussion is about disambiguation. - Knowledgekid87 (talk) 02:37, 7 February 2018 (UTC)[reply]
As long as we’re slightly off-topic, @Hijiri88: thank you for introducing me to the term wasei-eigo. Much more respectful than Engrish. —67.14.236.50 (talk) 01:20, 8 February 2018 (UTC)[reply]
You're welcome, but that was actually Hijiri who brought up the term. Wasei eigo's not the same thing as "Engrish", though—"Engrish" is a disparaging term used against Asians trying to speak English, while wasei eigo is terms coined in Japanese from English roots, such as sararīman and sukinshippu. Curly "JFC" Turkey 🍁 ¡gobble! 01:36, 8 February 2018 (UTC)[reply]
Right, thanks. Corrected. Guess I got the two comments above confused. —67.14.236.50 (talk) 02:46, 8 February 2018 (UTC)[reply]
  • Random further comment (I saw CT's Simpsons comment, and someone else Land Before Time comment, further up, but was actually thinking about this earlier) Japanese Wikipedia defines both Batman and Harley Quinn and (if memory serves) all of the Land Before Time sequels as "OVAs". The fact that the term is used among some western fans of Japanese anime to arbitrarily describe specifically Japanese OVAs seems kinda irrelevant, since the Japanese clearly refer to Japanese OVAs and foreign OVAs using the same word. This on top of the ungrammatical nature of "animations". Hijiri 88 (聖やや) 05:01, 7 February 2018 (UTC)[reply]
    Hijiri 88: That wasn't my "Simpsons comment", that was AngusWOOF totally misinterpreting what I said. I said that anime is animation—I didn't argue that The Simpsons was anime. Anime (in any language) is unambiguously and undeniably animation. Curly "JFC" Turkey 🍁 ¡gobble! 05:51, 7 February 2018 (UTC)[reply]
    Oh, I know you didn't say The Simpsons was anime; I meant simply that both words are Japanese words of English origin, which have been imported back into English with an arbitrary addition to their meaning of "... originating in Japan". I see a different between "anime" and "OVA", though, in that the former is widely recognized by general readers (even if I don't think it should be a disambiguator) and doesn't invite questions like "What's that an acronym for? Is it just a stylistic way of writing the Latin word for eggs?" and "Oh, that's what it means? Can you say an animation or some animations in English? That feels awkward to me..." Hijiri 88 (聖やや) 08:01, 7 February 2018 (UTC)[reply]
    I'm not sure where countable animations popped up in the conversation, but it does seem to have become somewhat widespread in the 21st century. I don't have a source to back it up, but I think it started in the sense of having pieces of animation in software or on webpages ("add an animation to this button, and another couple animations here"), and it seems to have started generalizing from there. I don't think it's generalized enough to be acceptible in Wikipedia articles yet, but give it another generation and I'm fairly confident it will. You won't catch me talking like that, though. Curly "JFC" Turkey 🍁 ¡gobble! 08:20, 7 February 2018 (UTC)[reply]

Has there been a discussion about the definition of “TV series”? Some of the rationale in this discussion hinges on disagreement over the meaning of that term, so if there is some established consensus on that matter, that could settle it. —67.14.236.50 (talk) 01:04, 8 February 2018 (UTC).[reply]

  • We're moving into a post-TV age—I doubt you'll see a term settled on in the near future, and whatever Wikipedia decides on will likely be displaced in the coming generation. I wouldn't waste much breath on discussing something that's going to be unstable for the foreseeable future. Curly "JFC" Turkey 🍁 ¡gobble! 02:00, 8 February 2018 (UTC)[reply]
    Not really as there are Smart TVs, the term refers to a telecommunication medium. - Knowledgekid87 (talk) 02:09, 8 February 2018 (UTC)[reply]
    Not if others say it doesn’t. There are people here who think it refers only to recurring broadcasts by TV networks, there are those who think it refers to literally anything meant to be viewed on a television screen by any means, and I’m sure there are people in between. Hence the question. —67.14.236.50 (talk) 02:33, 8 February 2018 (UTC)[reply]
Off-topic WP:NPA argument: this is not the appropriate forum for such discussion (for example, the other editor's talk page, or WP:Administrators' noticeboard/Incidents).

A discussion has been started (or has been ongoing for some time, depending on how you look at it) regarding some clarifications to Wikipedia's no legal threats policy. Interested editors are invited to participate in the discussion. Thanks. Ivanvector (Talk/Edits) 20:24, 1 February 2018 (UTC)[reply]

WP:TPO clarification

[7][8][9]

This is another case where there appears to be a disconnect from talk space guidelines. WP:TPO says that trolling may be removed, but this was not trolling. The IP's intent was to criticize the neutrality of an entire article, not to evoke a negative reaction, as far as can be discerned without mind-reading.

Does this otherwise fall into the "harmful posts" category (TPO bullet 3)? I don't see the harm, and the collapse probably would have been enough to prevent responses to the comment.

If this is considered a legitimate removal case, TPO needs to be updated to bring it in line with common practice. Otherwise, shouldn't we adhere to TPO, or are we all free to remove whatever posts we deem useless? ―Mandruss ☎ 18:41, 2 February 2018 (UTC)[reply]

I'm unconcerned either way. The post wasn't particularly useful towards improving the article, and I'm not sure it matters much whether it is preserved for posterity or goes away. The current guidelines are sufficient; difference in interpretation of any guideline is going to exist, and you can't make that go away merely by adding more rules. If you disagree, and think that the post was actually useful to the purpose of Wikipedia, perhaps starting a meta-discussion and hold a vote to restore it. That sounds like a phenomenal waste of time and energy to me, but you're free to. But no, rules don't need to be ammended because there will always be disagreements over how rules are to be interpreted; it's an endless fools errand to chase down every edge case and demand that rules be rewritten every time there's a disagreement over an odd case. Hard cases make bad law. --Jayron32 18:51, 2 February 2018 (UTC)[reply]
  • The IP posted and I quote "This article in itself seems racist, and ignorant. It seems to take a stab at calling our president racist, which is completely untrue. How original btw!" .... You Mandruss closed this as "Article talk pages are for improving articles, not attacking them" ...
So please enlighten every person here what part of that IPs comment is helping to improve the article ? ..... The comment IMHO was an attack (and you yourself stated this in the close) and so warranted removal,
Might I suggest you go and do something actually productive instead of continuously arguing over TPO ... it's rather sad. –Davey2010Talk 21:37, 2 February 2018 (UTC)[reply]
I reiterate the point I made in the earlier discussion. NOTFORUM vios, for example, are not "helping to improve the article", and they generally are collapsed rather than removed. The criterion for removal, therefore, is not solely whether the comment is helping to improve the article.
Please try to moderate your imperious and condescending tone especially when addressing established editors. This editor does not need schooling on the importance of contribution to articles, and I think you're aware of that. ―Mandruss ☎ 21:50, 2 February 2018 (UTC)[reply]
Attacks aren't collapsed - They're removed (and I will go as far as to say some are revdelled), Point is those sorts of comments aren't helpful and as the article is edited by millions a month I doubt the article could be racial etc .... It's an attack and wholly deserves removal. –Davey2010Talk 21:59, 2 February 2018 (UTC)[reply]
Well I admit it's been a while since I've do that much in article talk pages, from the little I've seen I don't think things have changed that much. Off-topic commentary is often hatted. But sometimes they are simply deleted when it's a clear cut case and it's the main post itself which is the problem. This tends to happen more in active talk pages where you get a lot of the NOTFORUM stuff. TPO already seems to deal with this well enough, notably while it refers to hatting that part is primarily referring to where there is a on-topic discussion and part of it goes off-topic rather than where the first post is off-topic. Remember one advantage with hatting is that while the discussion may be off-topic in some rare instances it may still be useful in a general sense. Also it may have been referred to by other participants. Finally it's easier for others to assess if the case was more borderline. None of this applies to the random comments people sometimes leave on article talk pages which are sometimes simply deleted. I don't see any real reason we need to add more complexity about when we should or should not delete off-topic commentary. And most complaints I've seen about the deletion of off-topic commentary have not been cases of "I think this material although off-topic is useful and so should not have been deleted" but rather, "I don't think this is supported by policy so it shouldn't have been done", which to me means to me it's not that important to deal with. In this particular case, I do agree with the comments below. While it's very unlikely the comment will be useful, since it was referring to the article it wasn't off-topic so was probably best left as is. Nil Einne (talk) 00:31, 9 February 2018 (UTC)[reply]
  • The IP was referring to the overall tone of the article, so I don't see how that is an attack or trolling in any way. It can't be a violation of FORUM because he was talking about the article directly, not just the subject matter generally. It wasn't particularly helpful by itself, but it could have started a discussion on what was not neutral about the article. I would not have deleted it and would support restoring it. Polite criticism of an article's tone is absolutely what the talk page is for. I don't see a need to modify policy, btw. I can't help but wonder if that comment had been posted by a long time editor rather than an IP, if someone would still have removed it. The IP was trying to improve the article....by discussing the shortcomings in the exact place he should have been, the article talk page. Again, this is perfectly acceptable. Dennis Brown - 2¢ 14:18, 4 February 2018 (UTC)[reply]
    • How about impolite criticism? How original btw! doesn’t strike me as “polite,” and I fail to see how flatly denying the claims of many sources (calling our president racist […] is completely untrue) is germane. I don’t think being in denial is a NOTFORUM vio, though. The comment wasn’t completely without merit; the article might as well be titled Donald Trump is racist, which (regardless of whether one agrees) would clearly be an unacceptable attack article. —67.14.236.50 (talk) 01:37, 5 February 2018 (UTC)[reply]
      • If this thread is limited to discussion of one narrow case, and it has no effect except maybe on some of the very few editors who read it, I agree that it is largely a waste of time and all of us should "go and do something actually productive". Nobody is going to cite this discussion to resolve future such issues, and it would have very little weight if they did. But that was not my intent here. ―Mandruss ☎ 01:49, 5 February 2018 (UTC)[reply]
    Well, the point is that you've brought up a specific dispute which your using to ammend a general policy. You've not established that this one dispute is representative of a widespread problem that policy needs to be addressed. With one dispute like this, one side or the other is interpreting the policy wrong; OR neither side may be and this is an edge case for which WP:IAR was intended to deal with. Either way, one single odd case is not a sign that policy needs changing. --Jayron32 16:14, 5 February 2018 (UTC)[reply]
        • Granted, it wasn't as polite as I like, but considering the average tone of discussions about politics, I wouldn't have blinked an eye at a little sarcasm. If that is the most offensive thing that hits that page this week, I would call that a great week. Dennis Brown - 2¢ 23:39, 5 February 2018 (UTC)[reply]
  • Just to note I've restored the comment pretty much per Dennis Brown - We all percieve things differently but for me if Dennis says it's not an attack then it's not an attack, Anyway reinstated the comment, Thanks, –Davey2010Talk 22:54, 5 February 2018 (UTC)[reply]

Recent user interface change discussion

Hello ... Is this the right place to talk about the recent user interface change which puts pop-ups on the screen when you hover over a wiki link? Regards, Jonathan. 82.69.229.22 (talk) 14:55, 4 February 2018 (UTC)[reply]

Welcome to Wikipedia Johanathan. You're referring to the semi-new Page Previews feature (also known as Hovercards). These Village Pump pages are the central location for discussing issues that broadly affect Wikipedia, like Page Previews. If this becomes an extended discussion, and depending on the exact issue, the discussion might shift to a different location. But it's fine to start the discussion here.
Tip: You might want to click Create account at the top of the page. Creating an account is not required, but it makes it easier for us to talk to you and it can make things easier for you as well. Alsee (talk) 16:48, 4 February 2018 (UTC)[reply]
Thanks for reply. I just wanted to register how awful a change I think it is. I respect and commend the utility of the feature; my comments are solely about forcing it on people. Some of us specifically like the Wikipedia interface for its simplicity and lack of movement. An 80-year-old user I know specifically complains about "all that moving stuff" which prevents her using many sites. I agree there is a difficulty in letting people know about the feature, but -- while respecting how hard people must have worked on it -- I think there are other ways to bring it to people's attention which would be adequate and less disruptive. Thanks for reading. Kind regards, Jonathan. 82.69.229.22 (talk) 12:48, 5 February 2018 (UTC)[reply]
You may be interested in following the discussion at phab:T91201 and mw:Page_Previews/preferences. — xaosflux Talk 14:14, 5 February 2018 (UTC)[reply]
"I think there are other ways to bring it to people's attention which would be adequate and less disruptive." Well, some examples of other ways would be nice.... Because I have trouble coming up with alternative ideas. —TheDJ (talk • contribs) 16:41, 6 February 2018 (UTC)[reply]
Hello Jonathan. Are you seeing this feature on the English Wikipedia or another Wikipedia? The Page Preview feature is not currently deployed to English Wikipedia, but there is currently an A/B test running. A small set of users may see the feature. If you are seeing the feature as part of the test you can opt-out by clicking the gear in the Page Preview. I've passed along your feedback to the product team. CKoerner (WMF) (talk) 17:48, 5 February 2018 (UTC)[reply]

In April of 2016 there was a Proposal: Enable Hovercards by default. The closing result is phrased as "no consensus" for activating Hovercards, however that appears to be soft phrasing for an effective "consensus against" activating Hovercards. As far as I'm aware, that is the last and only English Wikipedia community consensus on the issue. As far as I have been able to determine this feature is not active (by default) on English Wikipedia.

Jonathan, please provide more information if you are seeing this feature on English Wikipedia. I would be very interested in investigating further. If your concern is that you are seeing this feature on other language versions of Wikipedia, that is a lot more complicated. There can be some discussion of the topic here, and it is possible it could lead to raising the issue elsewhere. However the English Wikipedia Village Pump has no direct authority over decisions for other language versions of Wikipedia. Alsee (talk) 16:12, 5 February 2018 (UTC)[reply]

Hi Alsee and CKoerner: Yes, this was on English Wikipedia, which I use pretty much all day (it's my default search in the browser), and I made no changes to any configuration locally. There is is a gearwheel on the popup, but it can be off the screen so you can't see it; when disabled it puts "Enable previews" at the bottom of the page after "... Cookie statement Mobile view". It doesn't appear to be controlled by a cookie (I couldn't find it) perhaps it's on the session. The following screengrab (https://pasteboard.co/H6qqxhW.png) which shows an image of Encyclopaedia Britannica inexplicably taking up about half the content area, without any additional text, and with no visible controls. Thanks for interest. Kind regards, Jonathan. 82.69.229.22 (talk) 19:41, 6 February 2018 (UTC)[reply]
Hi Xaosflux: thanks, will look there. Jonathan.
Hi TheDJ: Regarding other ways to publicise new features, I think something like a "January's New features, why not try them" top-banner for the first few days of a month (like "Wikivoyage is celebrating 5 years" banner, see https://pasteboard.co/H6qAuxq.png) might be a good idea; it tells everything, without the issues I was critical of. If you click on it, you will find changes, if you don't, you won't. It appears in a predictable place with predictable controls. There would be no surprises or unintelligible user-interface issues. What do you think? Kind regards, Jonathan 82.69.229.22 (talk) 19:41, 6 February 2018 (UTC)[reply]
Jonathan, Yep, it looks like you are seeing the A/B test. I see the issue you mentioned. Again, I'll pass it along to the product team. I've created a task for the team to look at. Good feedback. Thank you.
I'd like to shamelessly mention Tech News, a weekly newsletter contributors and foundation staff publish about tech changes. You can subscribe via a few different methods. Might be something you'd be interested in. Cheers. CKoerner (WMF) (talk) 20:55, 6 February 2018 (UTC)[reply]

Stigmatizing language regarding suicide

Forgive me if this is not the proper place for this. I don't have a whole lot of experience with policy/meta stuff. I was directed here by another editor. Let me know if this is not the right place, and if so, where I should go.

I made a few edits that were reversed by someone claiming that I was breaking rules on censorship. I had changed a couple articles containing the phrase "committed suicide" to more neutral phrases like "died by suicide."

The phrase “committed suicide” has been declared by many experts to be outdated and stigmatizing because of its association with criminality (suicide has been decriminalized in many places). (Sources: 1 2 ) Phrases like “died by suicide” focus more on what is objectively and technically correct. While it is not Wikipedia’s job to play judge and jury on disputes over language, more neutral phrasing doesn’t change or dampen the meaning, and therefore I believe that it is better to use that then to go with language that is contested by many in relevant fields of study.

I am interested in seeing what sort of consensus could be reached on this issue.TylerRDavis (talk) 18:37, 5 February 2018 (UTC)[reply]

  • "Died by suicide" is inherently redundant (suicide IS death). "Committed suicide" indicates that the person took action which caused their death. Its simply more accurate. It was irresponsible of you to go on a tear changing this phrasing all over the place. Use what the sources use. Wikipedia is not censored, Wikipedia doesn't use wording if its sole reason is to avoid a "stigma", especially since presumably the target of the stigma is already dead. (As a personal aside, maybe if it were more stigmatized, fewer people would do it. Romanticizing the concept is a disservice.)
I'll also point out that this editor seems to be doing this sort of language softening in other areas. Recent edits include changed "wheelchair ridden" and "wheelchair bound" to "wheelchair using" in the interest of neutralizing possibly offensive language. Most of these seem to have been quickly reverted, but it might be a developing pattern for this editor. -- Netoholic @ 18:52, 5 February 2018 (UTC)[reply]
How many times have we had this discussion? "Committed suicide" is the common language, and in no way outdated. "died by suicide" is not more objectively and technically correct, it's just softening. Natureium (talk)
For the record, research shows that stigma actually prevents people from seeking help and therefore is a factor that potentially causes suicide. But I would not characterize the purpose behind my edits as avoiding stigma, but rather separating Wikipedia from a term that is in dispute and therefore is, by definition, not neutral. And yes, this parallels my edits regarding language around disability. But in both instances, I believe I was working in the interest of NPOV. Both of these are instances of idiomatic language being replaced by neutral and more specifically correct language. I fully believe in the rule that Wikipedia is not censored, but not when it is used as a way to avoid evaluating our own biases. What is backing up the claim that it is common language. I've presented expert sources that declare it to be biased language. "Died by suicide" is the term that said experts suggest, but if redundancy is the problem, there are plenty of alternatives (killed him/herself, ended their own life, or the admittedly awkward suicided). EDIT: Although this is not in and of itself a reason to change what we do here, it should be noted that the AP Styleguide recommends avoiding "committed suicide" so this isn't some sort of fringe PC thing. TylerRDavis (talk) 19:25, 5 February 2018 (UTC)[reply]
"[B]y definition, not neutral" — because it's "in dispute"? So then as soon as someone comes up with an objection to any particular phrasing, we should stop using it, to avoid implying that their objection is incorrect?
The claim seems to be that "commit" implies that it's a crime. But that's just plain false. "Commit" does not imply any such thing. --Trovatore (talk) 19:34, 5 February 2018 (UTC)[reply]
That link is to a letter in the correspondence of that journal, not to the research. That letter makes no claim about the phrase "commit suicide" being stigmatizing and I cannot comment on the research that the letter mentions as it is not available at that link. --Khajidha (talk) 20:29, 5 February 2018 (UTC)[reply]
Apologies. I meant to link to this. Admittedly, this says that any specific causality is hard to determine and that more studies are needed. That being said, it seems that the claim that stigma has a positive affect on suicide is unfounded conjecture at best (unless there is a valid sources that says otherewise), and has no place in the conversation. TylerRDavis (talk) 23:07, 5 February 2018 (UTC)[reply]

This was already discussed here recently, with overwhelming opposition; see Wikipedia:Village pump (policy)/Archive 138#Change suicide references to remove criminal allusion. postdlf (talk) 19:49, 5 February 2018 (UTC)[reply]

Forgive my ignorance of how things work around here, but does that mean that this is settled and no longer up for debate? TylerRDavis (talk) 19:58, 5 February 2018 (UTC)[reply]
Not automatically. Consensus can change, but it wouldn't seem likely to in this case given that recent discussion. –Deacon Vorbis (carbon • videos) 20:31, 5 February 2018 (UTC)[reply]
WP:NOTCENSORED is not the correct guideline here, I think you want MOS:EUPHEMISM which directs to use straightforward and familiar definitions rather than fudging with words to minimize their perceived offensiveness. My take on the guideline is simply "tell it like it is". The discussion linked above seems to have been tainted early by someone's faulty logic, it's hardly "using Wikipedia for language reform" when we're just following the documented practice of major publishing organizations, but Wikipedia is historically resistant to change. But also, many respondents to that discussion expressed exasperation at the question being repeatedly asked, and it was very recent, so probably a bad idea to propose it again so soon. Ivanvector (Talk/Edits) 20:44, 5 February 2018 (UTC)[reply]
I think I used that phrase, and I disagree that it is faulty logic. Even if Wikipedia did not initiate it, there is clearly a language-reform effort in play, and some people want to enlist Wikipedia in it. I do not think it should join.
Wikipedia should be resistant to such change. That's not to say that it should never change, but it should be a late adopter. That's the nature of the encyclopedic form. --Trovatore (talk) 20:54, 5 February 2018 (UTC)[reply]
*If WP:NOTCENSORED does not apply, and it was the policy cited in the reverts, then I suppose this falls less under policy and more under a dispute between two editors. The consensus of the previous discussion seemed to be that "died by suicide," or at least language other than committed, is not incorrect, just that a policy was uncalled for. TylerRDavis (talk) 20:44, 9 February 2018 (UTC)[reply]
(Edit conflict) TylerRDavis to summarize how things work, there is a fundamental idea that consensus can change. It's always possible that the community may shift position on any issue. However once an issue has been reasonably addressed, we don't want to waste time re-arguing the same things over and over. Not unless there's a credible expectation that the result might be different. So the answer here is that you should be able to look at that old discussion and see that there is zero chance you're going to get a different answer any time in the near future. In fact there were multiple discussions in multiple places, and the result was overwhelmingly clear. The community overwhelming considers "committed suicide" to be the common accepted English phrase. People consider the topic debated-to-death(pardon the accidental pun) at the moment. It would not be unreasonable to push for a full reconsideration of the issue again in several months... however don't unless you have a good-faith belief that most editors may have shifted to accept your position. Alsee (talk) 20:51, 5 February 2018 (UTC)[reply]
Thank you for the clarification. I do believe that this particular dispute has important consequences, so I hope to readdress it in the future properly and with careful consideration. If I believe there is a compelling reason to come back to this issue, would this still be the correct place to do so in the future?TylerRDavis (talk) 20:56, 5 February 2018 (UTC)[reply]
Wikipedia is not an advocacy platform. We don't change our operating procedures in order to effect real-world change. -- Netoholic @ 21:22, 5 February 2018 (UTC)[reply]
TylerRDavis, yes. Village Pump is for general Encyclopedia-wide business, and Village_Pump_(Policy) is the subpage for this sort of thing. I think there's a ManualOfStyle page that might also be an acceptable location, but I don't recall exactly where that other discussion was. If you do come back to the issue it would be wise to carefully examine the existing discussions first. You can expect some of the same people to show up at a new discussion, and it is likely that many old and new discussion participants will initially have similar positions and concerns as before. I don't think things are likely to change here unless there's a major social shift outside of Wikipedia first. Once of my often repeated comments is "Wikipedia does not lead, Wikipedia follows". There's a distinct aversion to efforts to use Wikipedia to advance a cause. (The comment by Netoholic above edit-conflicted me, and reinforces my last sentence.) Alsee (talk) 21:30, 5 February 2018 (UTC)[reply]
A similar situation is the mention of "black" and "white" in the first sentences of articles like Shooting of Walter Scott. There is a never-ending parade of removals of those words by people (never people with any editing experience) who feel that Wikipedia should not be divisively fanning the flames of racism controversy in the U.S.(latest example) And they are wrong for the same reasons. The words are used very commonly in our sources in these cases, so we use them, end of discussion. The only legitimate debate would be if the sources were not fairly consistent in their use of the words. (Black vs. African American is a separate issue.)
Until WP:NOTADVOCATE and WP:RIGHTGREATWRONGS are eliminated or substantially changed, or some other phrase becomes predominant in our sources, I don't see much point in further discussion of "committed suicide". ―Mandruss ☎ 23:39, 5 February 2018 (UTC)[reply]
  • Do we need to redo this discussion again? I thought we worked this out a couple of months ago. Commit is a perfectly common English word and does not stigmatize anything. Maybe some people need to commit that to memory. Commit themselves to working in another area of Wikipedia. Go watch The Commitments. Maybe we should commit this to the WP:PEREN file. I think I've committed enough time to it. --Jayron32 03:07, 6 February 2018 (UTC)[reply]
  • "Committed suicide" is also stylistically suboptimal because it puts the action in the noun, whereas many folks often consider it more direct to put the action in the verb. So "killed himself" or "took her own life" could be alternatives that are idiomatic, more active, and free of stigma - a win-win-win. CapitalSasha ~ talk 05:10, 6 February 2018 (UTC)[reply]
    So "killed himself" is direct and factual, to be sure. I don't see how it has any less "stigma" than "committed suicide" — if anything, it strikes my ear as blunter and harsher.
    That said, I have no objection to anyone using "killed himself" in any individual article; I certainly wouldn't go around looking for it to change it to "committed suicide". But I can't support any global recommendation to do the reverse, either, at least not until a more convincing case is made. For better or worse, "committed suicide" seems to still be common English, even if the crusaders have managed to convince a newspaper or two. --Trovatore (talk) 05:25, 6 February 2018 (UTC)[reply]
    "Killed himself" is ambiguous because it encompasses accidental deaths, so it's suboptimal. You might consider WP:MEDMOS as a natural "home" for advice on how to write about this. (Note that I'm not promising that you will find a sympathetic audience there. It's just that any such advice is probably going to end up on either that page or at WP:WTW, or both.)
    Netoholic, "died by suicide" is meant to present suicide as the actual cause of death. It's no more redundant than saying "killed by poisoning" or "died of natural causes", and limiting the information presented has the practical effect of not publicizing the specific suicide method (which has a direct, short-term effect on "copycats"). WhatamIdoing (talk) 06:33, 6 February 2018 (UTC)[reply]
    Neither poisoning nor natural causes includes death as part of the definition. "Died by suicide" is as redundant as "died by murder". --Khajidha (talk) 10:24, 6 February 2018 (UTC)[reply]
    Depends upon your definition. Definitions can be slippery things. According to some definitions, if you don't die, then you weren't really poisoned. But if you want matchy-matchy phrases, then "died by homicide" is the modern phrase for that situation. WhatamIdoing (talk) 18:00, 6 February 2018 (UTC)[reply]
    And that should not be used either. Neither suicide nor homicide is a cause of death, they are manners of death. A bullet to the head or a massive dose of poison or .... is the cause of death. --Khajidha (talk) 19:16, 6 February 2018 (UTC)[reply]
    To be clear, I have no particular objection to "died by suicide", in individual articles. If someone writes a new article and uses that phrase, I am unlikely to change it. I have an objection to signing Wikipedia on to a self-aware campaign to get rid of "committed suicide".
    My personal preference is for language to change organically, rather than as the result of self-aware campaigns. However, it is also not our place to oppose it — if they succeed, we will follow their lead. I do not think we are at that point. --Trovatore (talk) 22:49, 6 February 2018 (UTC)[reply]
  • Oppose - as stated in a recent discussion, the word "commit" in this context refers to the permanence of the result - as worded by Graeme Bartlett, It may or may not be a crime, but commit does not imply either way, it means that the choice has been made and cannot be reversed. An other meaning of the word is to promise to do something (such as an example given by Seraphimblade, One can commit to making a delivery by a deadline. And even if the primary meaning of the word is to do a crime, don't use Wikipedia to right great wrongs. עוד מישהו Od Mishehu 07:57, 7 February 2018 (UTC)[reply]
    I have never heard a native English speaker who would consider the word "commit" to be a synonym for a criminal act. I have done nothing criminal by committing something to memory. --Jayron32 15:31, 7 February 2018 (UTC)[reply]
    Suicide legislation is worth a read here, to understand that committing suicide can have legal implications. I disagree with changing the tone, but I understand where the concern arises. --Masem (t) 15:35, 7 February 2018 (UTC)[reply]
    That's neither here nor there. We mirror common English usage in reliable sources. Legal issues don't enter into the linguistic concerns. If reliable sources use the idiom, we use it too. --Jayron32 13:40, 8 February 2018 (UTC)[reply]
    Jayron32: "If reliable sources use the idiom, we use it too."—you don't have to think very hard on that statement to see where it gets very problematic, very quickly. No, Wikipedia should not and does not simply mimic the language used in sources. Curly "JFC" Turkey 🍁 ¡gobble! 22:09, 8 February 2018 (UTC)[reply]
    Really? So you're saying it is up to a Wikipedians to invent new language instead of using what mainstream reliable sources use? What Wikipedia policy or guideline led you to think we should do that?--Jayron32 04:04, 9 February 2018 (UTC)[reply]
    Jayron32: Please, it's painfully obvious I said nothing even remotely resembling any like that. Could you please respond to what I actually wrote? Curly "JFC" Turkey 🍁 ¡gobble! 22:56, 9 February 2018 (UTC)[reply]
  • Oppose as last time. "Commit" can sometimes mean a criminal act, but it doesn't always. In this case, it simply means one committed to an irreversible decision or course of action. Seraphimblade Talk to me 16:15, 7 February 2018 (UTC)[reply]
  • Support To me, it is clear that commit suicide is meant to mirror phrases like "commit murder," and the idea that something like "commit to memory" or "committed relationship" proves otherwise is based on wholly seperate definitions of the word that would not make sense in this usage. This is using the word commit to mean "to carry out" which has a largely negative connotation, and is editorializing. I think it's pretty clear that the phrase does not mean that one has "committed his/herself to suicide" in the sense of a pledge. On the subject of righting great wrongs, I agree. Wikipedia should not take the lead on this issue, but I would argue that committed suicide is no longer all that common place in professional settings. The AP Stylebook, and therefore many U.S. newspapers, is against the term. I would also argue that the criticisms of the clunkiness and redundancy of terms like "died by suicide" are not in and of themselves defenses of the phrase "committed suicide." My argument is not necessarily that Wikipedia exclusively use language advocated by some mental health advocates. My argument is that the phrase "committed suicide" itself is not neutral. TylerRDavis (talk) 19:02, 7 February 2018 (UTC)[reply]
    • You've already stated your position and were disagreed with. We've discussed this topic several times, and it isn't going to change to please people who are easily triggered. Natureium (talk) 19:33, 7 February 2018 (UTC)[reply]
      • The reason I felt the need to restate my position is that I feel like it hasn't actually been directly addressed, or it has at least been misinterpreted. I have no interest in "pleasing people who are easily triggered" as you put it. I believe the phrase carries connotations that make it less than neutral, and that it is possible and preferable to find a more literal phrase. Apologies if I have violated some sort of rule I was unaware of regarding over-posting in a discussion, but I won't stand by while someone assembles a straw man of my argument. TylerRDavis (talk) 19:45, 7 February 2018 (UTC)[reply]
  • Comment -- since this conversation is about connotations, not denotations, dictionary or technical definitions are pretty much entirely beside the point. I also think that given that TylerRDavis is citing sources in support of his position, opposition to his position should include sources as well, not just "I think" or "everyone I know thinks," etc. CapitalSasha ~ talk 07:32, 8 February 2018 (UTC)[reply]
  • I agree that dictionary or technical definitions are beside the point, and mentioning them only tends to cloud the issue and divert focus. Also beside the point are academic studies about the issue of suicide and stigma. The only relevance is in common usage within reliable sources, and TylerRDavis has produced nothing to contradict the stated experience and perception of a majority of editors. I think that burden is on he who wishes to effect change. But I'll go beyond the call of duty and spend 30 seconds finding this recent article in The New York Times, one of your more liberal mainstream news sources. ―Mandruss ☎ 22:52, 8 February 2018 (UTC)[reply]
To be clear, the research on stigma as a cause of suicide was only in response to someone's personal aside that stigma might actually make suicide less likely. Neither that editor's aside or my response are relevant to this issue as far as Wikipedia is concerned, but if someone else is allowed to make such an assertion where it perhaps doesn't along, I think a response is justified. The links in my original post were admittedly opinion pieces, but meant to show that people within the relevant field of study have taken issue with the phrase. Whether that is a majority field among experts I do not know, but I don't understand why anecdotal accounts of how common people speak should guide editorial policy for a research based publication. TylerRDavis (talk) 23:56, 8 February 2018 (UTC)[reply]
  • Oppose Wikipedia is not censored, nor is it the place to play games with what someone thinks the standard English should be. Standard written and spoken English is committed suicide. We use that. If the English language evolves to not use that anymore, than Wikipedia will naturally evolve with it (that is how Wikis work). No need to be the language police. TonyBallioni (talk) 23:02, 8 February 2018 (UTC)[reply]
  • Oppose per NOTCENSORED, News sources have always said "Committed suicide" ..... "Died by suicide" to put it bluntly sounds silly because you're kinda stating the obvious .... Anyway as per above in the English language "Committed suicide" is correct ..... If this is phased out then as Tony says we will evolve but it's for us to decide what should be used and what shouldn't. –Davey2010Talk 23:35, 8 February 2018 (UTC)[reply]

Rfc: Change default <math> to be inline

Should the of "default" <math> be changed to inline in the future?--Debenben (talk) 22:47, 6 February 2018 (UTC)[reply]

Background information

Some time ago I did a little survey in the German Wikipedia on how to resolve several problems with the current markup for inline and block equations. The solution with the most support was turning "default" <math> into true inline equations, equivalent to <math display="inline"> or <math>\textstyle and using <math display="block"> or a new shortcut notation like <math block> for block equations, replacing the current :-indented markup.

Since technical limitations of the current math extension prevent several types of block-formulas from using the new notation and/or such a conversion would negatively impact the appearance on certain devices/browsers, this Rfc does not propose to implement such changes immediately. If this Rfc is successful, the intention for such a change should be written into Wikipedia:Manual of Style/Mathematics along with a recommendation: For formulas that are not block equations but still look better with large symbols, editors should specify \displaystyle explicitly instead of relying on <math> being displaystyle by default.

Some problems the proposed solution might solve in the future

Display options in the VisualEditor (here with German descriptions).
  • "default" exists for historic reasons and backwards compatibility. For most purposes "default" without further modifications like : indentation or \textstyle is technically wrong.
  • Using <math display="inline"> or <math>\textstyle for each inline formula makes the source code difficult to read and type.
  • New editors are confused by the "default" layout. They expect one notation for inline and one for block formulas with the inline markup using textstyle by default.
  • Some editors might not be familiar with the textstyle and displaystyle commands since they are used to LaTeX, MathJax etc. choosing it automatically.
  • Some editors do not bother to select textstyle explicitly, especially if there are only marginal differences e.g. vs .
  • Editors using the VisualEditor cannot create block formulas with : indentation and can get frustrated trying to get a comparable layout example
  • : is a definition list that creates invalid HTML and can be annoying for screen readers. It also creates its own paragraph <p> which is technically wrong and leads to inappropriately large separations in some browsers/devices.
  • Having two markups for block formulas, i.e. :-indentation and display="block" parameter creates inconsistent layout. For most browsers/devices the visual appearance of both is only similar in the English Wikipedia due to common.css.
  • The optimal layout of block equations depends on other layout choices such as placement of figures which can be different for mobile devices. Editors should not hard-code those choices manually e.g. by number of :-indentations. Instead, indentation would be with respect to the surrounding text without creating surplus indentation if block equations are chosen to be centered.
  • Some more advanced features such as a referencing/numbering system for block equations and automatic line breaking require a clear distinction between inline and block-equations.

Some alternatives to this solution

Alternatives that were discussed in the survey:

  • creating new HTML-tags or keywords for inline and block equations and <math> retaining its behavior,

a solution which got slightly less support and people indicated that they regard it as the second best choice only. Alternatives that got mostly oppose-votes were:

  • keeping the :-syntax for block formulas and trying to work around some of the issues
  • solutions that involve templates

Some technical problems that hinder implementing the solution

If people are interested I am happy to write and discuss these further. I don't expect much progress here and it is only worth discussing if the general intention of the proposal receives enough support.

And last but not least: I don't have any experience with Rfcs and the conventions here. Feel free to change things I did wrong and notify people that might have some opinion on this matter.--Debenben (talk) 19:56, 5 February 2018 (UTC)[reply]

@Debenben: We discussed this topic recently. Please review WP:Village pump (policy)/Archive 138#RfC: Accessibility versus convenience in indentation. --Izno (talk) 20:20, 5 February 2018 (UTC)[reply]
And especially, the discussion I started at WP:Village pump (policy)/Archive 138#Math block display. --Izno (talk) 20:22, 5 February 2018 (UTC)[reply]
@Izno: You are right, I should have mentioned this previous Rfc. I got a ping from user:Whatamidoing (WMF) because I discussed the issue with him a year ago [10] and I also left a comment. I had the impression that the closing statement "Final note, since much of the opposition was related to the mode of resolving this screen-reader compliance problem, rather than the underlying idea of addressing the problem in the first place, it's of course all right for someone interested in the discussion to formulate a new proposal without waiting for days or months to pass." referred to my comment. Therefore the above focuses on addressing the problem without providing a technical solution. A possible technical solution (also solving other problems) would have been [11] but it did not get enough support. Still, if this proposal gets through it might encourage Media-Wiki developers to do something about it.--Debenben (talk) 20:52, 5 February 2018 (UTC)[reply]
I added the Question and RFC-template to the above in order to get more input.--Debenben (talk) 22:47, 6 February 2018 (UTC)[reply]

Survey: Change default <math> to be inline

  • Oppose. Surveys of English Wikipedia editors on English Wikipedia policy have no jurisdiction over Wikimedia technical formatting issues. The actual solution is up to the developers, but even if we wanted a survey of readers and editors to suggest better directions for the allocation of the developers' time, the correct place for that would be meta because this affects all Wikimedia sites not just this one. But regardless of all that, this proposal would break the formatting of all displayed (on a line by themselves) equations on Wikipedia. That's a lot of damage in exchange for very intangible benefits. —David Eppstein (talk) 23:42, 6 February 2018 (UTC)[reply]
  • Changing is not a good idea, there must be 100000s or more pages that would need to be altered. It would cause such a huge mess, including in the knowledge of the people that use the tag. Graeme Bartlett (talk) 00:47, 7 February 2018 (UTC)[reply]
  • Oppose unless benefits are clearer. Xxanthippe (talk) 01:47, 7 February 2018 (UTC).[reply]
  • Oppose. In principle this would have been a good idea, but formatting is already entrenched. Among many proposals to do with math formatting that English Wikipedia could decide to approach devs with, this has very minimal benefits. Sławomir Biały (talk) 11:16, 7 February 2018 (UTC)[reply]
Some remarks: For the survey in the German Wikipedia I did a rough estimate on the numbers of affected block-formulas: There were in total 237 779 occurences of math tags (in the main namespace), among those roughly 55 435 block-formulas. A simple algorithm similar to the one implemented in the old MathJax rendering mode or the one still existing today on scholarpedia, transforming all : indented math tags on its own line (without anything except for a space or punctuation mark) into a block formula would recognize around 82% of them correctly. The others have different number of indentations, text-elements or labels on the same line. They would get "broken" (meaning that they get an unconventional, less beautiful layout) and need to be marked as block formulas manually or by a bot using a more sophisticated algorithm. I guess there would be a slightly higher percentage of block formulas on the English Wikipedia and the total number would roughly scale with the article count.
For all those oppose votes I would be interested in their preferred solution. As I said, the alternative of introducing new tags (something like <imath> <dmath> <ichem> <dchem>) and avoid breaking the current math formatting had only slightly less supporters. A similar solution that involved creating a new markup for inline formulas was proposed on phabricator around 2012, but blocked due to the lack of community support. The WMF has no view on the issue, currently all development and maintenance of the math extension is done by one volunteer.--Debenben (talk) 14:00, 7 February 2018 (UTC)[reply]
I think the ideal solution would be to implement \( \) and \[ \] as math delimiters. This would also solve the most recent problem of the non-accessible way that Wikimedia interprets the colon operator as part of a definition list, when the colon is used for indentation of inline equations. Sławomir Biały (talk) 19:47, 7 February 2018 (UTC)[reply]
That is probably the dream of every mathematician and LaTeX fan. It would need an equally strong concensus and I would be concerned that other people don't like it. Like: If you ask for too much you don't get anything.--Debenben (talk) 15:58, 8 February 2018 (UTC)[reply]
On the contrary, I think the approach solves a lot of problems we've been having lately. Offer the developers and editors a solution and they might implement it. Think big! Sławomir Biały (talk) 19:41, 8 February 2018 (UTC)[reply]
Just as a more "stupid" idea: What you suggested would already work today: \(\sum_{n=0}^\infty \frac{x^n}{n!} \text{this should become inline}\) and \[\sum_{n=0}^\infty \frac{x^n}{n!} \text{this should become block}\] if one would simply write something like 
$("head").append("<script type=\"text/x-mathjax-config\">MathJax.Hub.Config({'HTML-CSS': {preferredFont: 'STIX', webFont: 'STIX-Web', mtextFontInherit: true}, 'SVG': {mtextFontInherit: true}});</script>");
$("head").append("<script type=\"text/javascript\" async src=\"https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.2/MathJax.js?config=TeX-AMS_HTML\"></script>");
into Mediawiki:Common.js. --Debenben (talk) 21:40, 8 February 2018 (UTC)[reply]
Fairly easy in principle to implement, I'll grant. Sławomir Biały (talk) 01:16, 9 February 2018 (UTC)[reply]
True. I improved the configuration a little: 
$("head").append("<script type=\"text/x-mathjax-config\">MathJax.Ajax.config.path['mhchem'] = 'https://cdnjs.cloudflare.com/ajax/libs/mathjax-mhchem/3.2.0'; MathJax.Hub.Config({TeX: { extensions: ['mediawiki-texvc.js', 'AMSmath.js', 'AMSsymbols.js', '[mhchem]/mhchem.js'], equationNumbers: { autoNumber: 'AMS' }, mhchem: { legacy: false }}, displayAlign: 'left', displayIndent: '2em', 'HTML-CSS': {preferredFont: 'STIX', webFont: 'STIX-Web', mtextFontInherit: true, linebreaks: { automatic: true }}, 'SVG': {mtextFontInherit: true, linebreaks: { automatic: true }}, 'CommonHTML': {mtextFontInherit: true, linebreaks: { automatic: true }}});</script>");
$("head").append("<script type=\"text/javascript\" async src=\"https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.2/MathJax.js?config=TeX-AMS_HTML\"></script>");
I think cloudflare wouldn't mind if we use their servers since they get an easy way to track all readers, but it probably violates some guidelines. Does anyone have access to something like a Wikipedia-toolserver that he can spare, so we can have our own cdn? I would be really looking forward to present some of the new features:
  • Working math also for devices like Ipads (In case someone is interested delivering the good news to the poor guy [12])
  • Working textmode, especially for all languages that don't use latin charakters
  • Working mhchem package
  • Copyable formulas, proper HTML
  • Fully editable in the VisualEditor (unfortunately the alpha version is lacking support for the visual formula editor)
  • Support of automatic referencing and numbering, support for linebreaking, support for missing commands like \middle
  • Support for defining macros, linking websites, popups etc. (Some of those features should probably be disabled in production)
  • Great user support, if you find a bug and report it at Github you probably get a patch within days
--Debenben (talk) 18:55, 9 February 2018 (UTC)[reply]
Ahh, and I forgot: An excellent accessibility explorer, where you can navigate through the formula with arrow keys and any average screen-reader can read out the generated text piece-by-piece.--Debenben (talk) 19:01, 9 February 2018 (UTC)[reply]
@Xxanthippe: I wanted to avoid a lengthy explanation because I was hoping for other peoples comments to highlight some of the current problems. Since this is not the case and you explicitly asked for the benefits to be clearer, I will attempt to illustrate some of the bullet points above:
A lot of inline formulas use the "default" layout, usually because the editor did not bother to specify it or is not familiar with the \textstyle command. For example if I write , then for me, if I use a standard setting in firefox in combination with the svg rendering that most people get, the expression is just a little bit too large to fit into a normally spaced line, therefore the spacing of the lines in the text is not equal but a little bit different. For most people this is only the case for larger operators like . This can be avoided by using the correct inline formatting, either by adding \textstyle or the parameter display="inline", resulting in or . If you happen to have a browser/device where the example already uses a little bit too much space, then for you there will be more inline formulas that would get fixed by the change than those that get broken. Of course adding an additional \textstyle or the parameter display="inline" for all inline formulas would already be possible today. However the wikitext would become increasingly hard to read. In the survey I used the example of w:de:Satz des Pythagoras having three sentences with seven inline formulas each, where you don't want to clutter the source code with \textstyle or display="inline" parameters for each of them. Pythagorean theorem has a similar amount of inline formulas, however they are, probably due to other deficiencies, not using math-tags. That is what I wanted to express with the flawed "slightly higher percentage of block formulas" comment above. If you had a math extension were formulas are copyable, look good etc. for everyone, then you would want to use inline math for each of them. With the proposed change, editors could forget about \textstyle or display="inline", because it would have the correct formatting by default. This is the behavior people outside of Wikipedia would expect and how it works in LaTeX or any other typesetting system. The reason it is different in Wikipedia is, that originally the math extension was not designed for inline formulas, but as a replacement for images and ascii-art block formulas. Because a lot of mathematical expressions cannot easily be obtained with normal HTML-characters, editors also used the math extension for inline formulas, even though it did not have proper size or alignment for the text (and today this is still a problem, at least for a lot of browsers/devices).
Since the original idea behind math was to create images, and you would want to be able to use those images for example in tables etc., it did not have a proper layout for block equations either (and today this is also still a problem). Editors used the : markup because it is the easiest. However it is part of a definition list markup and produces invalid HTML. As far as I know it gets indented in every major browser, but in principle the layout of a definition list can be anything and the behavior of an invalid definition list is undefined. When I select "print this page" in firefox, everything indented with : gets printed with a large font size, which I guess is due to broken definition lists. An average screenreader would tell you for every :-indented block-formula that a definition will follow, which I guess can be annoying, especially in the middle of a sentence. The other thing that is wrong is the paragraph <p> that gets created, which means that there will be a space before and after every block formula that matches the space of a new paragraph in the text and depending on the browser/device can be inappropriately large. It is also semantically wrong, because the whole point of indenting or centering block formulas is to show readers that the early line-break is not a new paragraph, but just for accommodating a large expression that cannot easily wraparound into the next line. With the proposal above, those 82% of block formulas (or whatever the exact percentage on the English Wikipedia is) would get proper HTML like the one you get on websites like math.stackexchange that is not broken, does not abuse definition list markup or create a new paragraph. The others would get proper HTML if they get fixed manually or with a bot.
Another problem concerns editors unfamiliar with the wikitext or LaTeX markup. I cannot tell first-hand, but only from looking at strange edits of new accounts or when they ask for help. Imagine you are unfamiliar with wikitext-markup. Then you would assume that you can use the VisualEditor to edit mathematical articles. You effectively cannot because you can't add :-indentations or change them. However you would not know what those indentations are. You click on an equation that is clearly an inline equation and it will show you that it is "default". Maybe it begins with \textstyle - a command even some mathematicians or physicists don't know because normally it is not needed in LaTeX. If you click on inline - nothing happens. If you click on "block" you generally get a block formula that is centered (and the English Wikipedia uses commons.css to make it indented, solving this issue and creating different problems). If you want to edit another block formula - it is also "default". If you create a "default" formula yourself you cannot get it indented. With the proposal above this would get fixed, because there would only be one inline and one block option to choose from, and if you add a new formula and don't select anything it would be a correct inline formula. If you select block formula, it would become a true block formula. I believe it would especially help people not familiar with LaTeX because they could use the formula editor of the VisualEditor, since the formula is rendered or the error message is shown immediately. They also wouldn't need to search for a formula they want to edit in the source code, where you often rely on searching for generic LaTeX commands or words somewhere next to it.
These are the main points. As you can see from the bullet points above, there are some other (in my view minor issues) that would get solved. There is also a whole bunch of things problematic with current usages of the display="block" parameter which I have not touched. Since this fortunately only concerns 165 pages at the moment I have left this out for now.--Debenben (talk) 15:58, 8 February 2018 (UTC)[reply]

Guideline 1 below advises that highly relevant links in a navbox should not be repeated in the "See also" section, whereas guideline 2 below implies that highly relevant links in a navbox should be repeated in the "See also" section (if they are not already in the article's body):

  1. MOS:NOTSEEALSO and MOS:NAVLIST both advise: "As a general rule, the 'See also' section should not repeat links that appear in the article's body or its navigation boxes." Similarly, WP:NAVBOX lists as one of the guidelines for good navigation templates: "If not for the navigation template, an editor would be inclined to link many of these articles in the See also sections of the articles."
  2. But, a couple of paragraphs later in WP:NAVBOX, we are advised: "Do not rely solely on navboxes for links to articles highly relevant to a particular article. Navboxes are not displayed on the mobile website for Wikipedia which accounts for around half of readers."

Is this apparent contradiction between guidelines a problem that needs to be fixed? If not, I will continue following guideline 1 above as I always have.

There has already been some discussion of this issue, but nothing that fixed the contradiction mentioned above. These are the major discussions that I could find:

Thanks, Biogeographist (talk) 03:16, 6 February 2018 (UTC)[reply]

  • I don't have an answer on how to resolve the issue, but I believe that the text of (1) above has been functionally in Wikipedia's guidelines for at least 10 years if not more; that may explain the contradiction as this would have predated the mobile version of Wikipedia by some many years; the later addition to deal with the lack of navboxes in the mobile version may have not thought to change the earlier guidance. --Jayron32 03:22, 6 February 2018 (UTC)[reply]
@Hawkeye7: Either you just made an ironic joke or I'm not correctly understanding what you're trying to say, because as I read it, your second sentence above contradicts your first sentence, since the first sentence says there is no contradiction that needs to be fixed, and the second sentence seems to advocate in favor of guideline 1 above ("the 'See also' section should not repeat links" in navboxes) and against guideline 2 above ("Do not rely solely on navboxes for links" but rather put relevant links in the "See also" section for mobile users), which implies fixing the contradiction between guidelines 1 and 2 in favor of guideline 1. Biogeographist (talk) 13:08, 6 February 2018 (UTC)[reply]
I support the idea of Khajidha. --Emir of Wikipedia (talk) 13:28, 6 February 2018 (UTC)[reply]
Khajidha's suggestion would certainly fix the aforementioned contradiction, but I imagine that there may be technical or other obstacles to that fix? Biogeographist (talk) 14:26, 6 February 2018 (UTC)[reply]
  • I want to make sure I understand the underlying issue... the older guidance was intended to limit overlinking. The idea was that if an article already contained a link to another article (whether in the main text or in a navbox), then there was no need to link to that other article again in the "see also" section. However, this instruction seems to have caused a problem when it comes to the mobile view, because mobile view does not display navboxes. This means that a reader will not see a link that is in a navbox (but not in the main text). So... to account for this, the newer instruction was written to tell editors not to rely on navbox links, and to repeat the link in the "see also" section. Is this an accurate summary of the issue? Blueboar (talk) 14:08, 6 February 2018 (UTC)[reply]
@Blueboar: Yes, it seems to me that you understand the issue perfectly. I think you are also right to point out that the practical effect of guideline 1 above is to minimize the number of links in the "See also" section, whereas the practical effect of guideline 2 above is to increase the number of links in the "See also" section. Biogeographist (talk) 14:26, 6 February 2018 (UTC)[reply]
OK... then perhaps we can narrow down the issue... can we agree that the guidance to not repeat links that are in the article TEXT is fine (for both desktop and mobile versions)... and that the potential conflict is purely with links that are ONLY in a navbox?
If so... I think it would be helpful to know WHY the developers of the mobile view decided to NOT include navboxes (we need to understand that decision in order to decide which guidance is best). Does anyone know? Blueboar (talk) 15:04, 6 February 2018 (UTC)[reply]
Nope. I don't even care why they did it. Either a mobile device has the ability to display the entirety of wikipedia (in which case it should do that) or it doesn't (in which case it shouldn't be used to view wikipedia). --Khajidha (talk) 15:21, 6 February 2018 (UTC)[reply]
Wikipedia administrator Mark Hetherington said in a 2016 Quora post titled "Why are Navboxes (navigation templates) not displayed on Wikipedia's mobile website?" that navboxes were excluded from mobile view because they "can't be reliably restyled for mobile", but as I read it, his post also suggests that exclusion of navboxes from mobile view may be a temporary kludge until the code of templates such as navboxes is updated to be compatible with responsive web design, which implies that guideline 2 above addresses a situation that may be temporary. Biogeographist (talk) 15:31, 6 February 2018 (UTC)[reply]
Ah... then perhaps the solution is for our guidance to note that it IS a temporary fix... effectively saying: “because navboxes currently don’t appear in mobile view, we must TEMPORARILY add navbox only links (ie those that appear in navboxes but not in the main text) to the “see also” section. These should be removed once the developers figure out how to incorporate navboxes into mobile view.” Blueboar (talk) 16:06, 6 February 2018 (UTC)[reply]
Why? The onus should be on mobile device designers to make sure that the devices can handle this site, not on us to fit their capabilities. --Khajidha (talk) 16:14, 6 February 2018 (UTC)[reply]
It isn't. Mobile device designers are not going to design around accomodating a single website (and who will ask them, anyway? We only have control over us). Jo-Jo Eumerus (talk, contributions) 16:23, 6 February 2018 (UTC)[reply]
(I wrote this before seeing Jo-Jo Eumerus's comment but I will post it even though it repeats the point of that comment:) I don't think the reasoning in Khajidha's last comment is quite right: the most relevant actors here are not "mobile device designers" but rather web standards developers. And I imagine that in general the adaptation mostly happens in the other direction: the developers of MediaWiki and Wikipedia try to adapt to web standards (most notably, in this case, standards for responsive web design), and not vice versa, since the developers of MediaWiki and Wikipedia have little influence on web standards.
A problem that I see with Blueboar's suggestion (that editors temporarily add links to the "See also" section only to remove them later when navboxes are added to mobile view) is that it doubles the effort required of editors: first they have to figure out which links to add to the "See also" section, and then later they have to figure out which links to remove. A consistent (not temporary) guideline would be a much more efficient use of editors' time and brainpower. Biogeographist (talk) 16:43, 6 February 2018 (UTC)[reply]
My mobile device can be set to "desktop site" allowing me to do anything that I can do here on my laptop computer. Is this not a common feature of mobile devices? And, if it is, why don't people just use that and not have to worry about what the mobile version can or can't do?--Khajidha (talk) 17:07, 6 February 2018 (UTC)[reply]
@Khajidha: In your first comment above you seemed to propose fixing the mobile version of Wikipedia, and later I pointed out that Mark Hetherington's Quora post suggested that might happen in the future; in your last comment you seemed to imply that readers should abandon the mobile version in favor of the desktop version, but I don't see any evidence that will happen in the future. What I really want to know is what editors should be doing about "See also" links: following guideline 1 or 2 above, or doing something else? Biogeographist (talk) 17:30, 6 February 2018 (UTC)[reply]
I'd say follow the "do not duplicate" guidance as the effect on mobile devices is not our problem.--Khajidha (talk) 17:34, 6 February 2018 (UTC)[reply]
  • The updating of the code for the viewing of templates on mobile seems a priority, if the code can be fixed (the templates are maps of the site for the main topic, and are valuable additions to anyone viewing them, desktop or mobile). Until then some links should be allowed on See also. Not every link in a navbox template can be listed in See also, for space and formatting consideration, but should rather be judged on a case by case basis (some links good, overlinking not so much). Randy Kryn (talk) 17:39, 6 February 2018 (UTC)[reply]

Here is my opinion, which may be controversial but I feel quite strongly about this. I am an administrator with 50,000 edits in many areas of this encyclopedia. I complete at least 95% of my editing on Android smartphones and I always use the fully functional desktop site with very few problems. Yes, I have tried the mobile site from time to time over the years, and have consistently found it vastly inferior to the desktop site on a smartphone. The desktop site works exactly like a miniature desktop computer on my Android smartphone. People have said I must have unusually good vision. That is baloney. I have amblyopia, cataracts, glaucoma and vitreal detachment. Despite my vision problems, I find it very easy to edit Wikipedia using the desktop site on an Android smartphone. So, my recommendation is to rename the desktop site to the "fully functional site" and shut down the inadequate mobile site. Cullen328 Let's discuss it 03:02, 7 February 2018 (UTC)[reply]

I agree that the "mobile view" is not very useful. I also usually switch to the so-called "desktop view." The mobile format is unnecessary and archaic, as these days most mobile devices can deal with fully functional web sites. I wouldn't waste resources on it. Jack N. Stock (talk) 05:35, 7 February 2018 (UTC)[reply]
I'm partially with Cullen328 on this; when it first started, the mobile site was a Good Idea, as mobile devices were of lesser power, and a "dumbed down" site was needed to work and display properly on mobile phones at the time. I never use the mobile site on my last two phones because modern equipment and internet strength have evolved to make the desktop site work fine. I don't oppose the existence of the mobile site for people who genuinely prefer it, but I hate that I frequently have to override Wikipedia's default when editing from my phone. --Jayron32 13:48, 8 February 2018 (UTC)[reply]

Thanks to everyone who has responded so far. I don't see a consensus here that would lead me to change my editing behavior, much less lead to a change in the existing guidelines, but I will keep all of these perspectives in mind during my editorial decision making. We will see what the future brings regarding the limitations of Wikipedia's mobile view. The predominant opinion here seems to be that the lack of navboxes in mobile view is a problem that should be fixed in one of various ways. Biogeographist (talk) 15:55, 8 February 2018 (UTC)[reply]

Allowing iMDB as a reliable source for filmographies

I'm raising this as it has been a frequent concern on WP:ITN/C that filmographies be entirely sourced to permit post of recent deaths. I find it odd that we allow plot summaries of movies (and other media) without a secondary source, yet we require secondary sources for filmographies. Just as books that are offline are acceptable sources, are films not acceptable as the source of a credit (exception for uncredited roles)? But, I'll back it up to what is now known as a reliable online resource for film and television: iMDB. Shouldn't we allow this resource to be used for the generally uncontentious filmographies/credited roles?

My proposal is solely limited to filmographies and television credits and would not include the use of iMDB for other purposes. I also propose an exception to WP:EL should this pass, that iMDB still be included as an External link even if it is used as a source. - Floydian τ ¢ 18:15, 6 February 2018 (UTC)[reply]

How do you know the image isn't photoshopped, is there vetting in place? - Knowledgekid87 (talk) 18:23, 6 February 2018 (UTC)[reply]
Sources are not required to be online. The credits for Bladerunner are verifiable by anyone who has access to amazon, a good library or streaming TV services. Screenshots are not required. Only in death does duty end (talk) 18:33, 6 February 2018 (UTC)[reply]
I agree with that, I am talking about IMDB though. It bothers me here that it is used as a reliable source in articles. - Knowledgekid87 (talk) 18:38, 6 February 2018 (UTC)[reply]
It isn't, or it shouldn't be for most things. There are a couple of exceptions, see WP:CITINGIMDB (where the WGA and MPA are the original source). Every time it comes up at RSN the answer is usually 'no' as a general rule. Only in death does duty end (talk) 18:49, 6 February 2018 (UTC)[reply]
I would almost never use IMDB as a reliable source per WP:EL/P#User-submitted contents. The info is user submitted (not noteworthy), and rarely corrected. - Knowledgekid87 (talk) 18:22, 6 February 2018 (UTC)[reply]
WP:RS/IMDB exists for a reason. Knowledgekid87 is spot on in their statement. All you have to do is look at the massive mess here to see the lack of fact checking that goes on there. There are numerous websites including the American Film Institute and the British Film Institute which can be used. MarnetteD|Talk 18:49, 6 February 2018 (UTC)[reply]
Perhaps most IMDb content is accurate, but certainly not all. I am personally aware of two convicted Hollywood con artists who have manipulated IMDb to gain undeserved show business credibility for the purpose of defrauding investors. I oppose using IMDb as a reliable source, except in the very limited circumstances already defined. Cullen328 Let's discuss it 02:47, 7 February 2018 (UTC)[reply]
Sometimes I used information on IMDb as search terms to find more reliable sources, and I feel that it can be appropriate to cite IMDb alongside the other citation to acknowledge this. Most of the "disputed uses" listed on WP:CITEIMDB (such as cast list, character names and so on) can also be verified from the primary source (the credits listed on the film), and the IMDb credit will at least keep most of the "citation needed" nannies happy. Chaney aside, most filmographies and television credits are uncontroversial, I don't see why we would need to find a book authored by a Harvard president as WP:V that Harrison Ford appeared in Blade Runner (the current citation is a "DVD"... whatever that is). Jack N. Stock (talk) 06:18, 7 February 2018 (UTC)[reply]
The issue is less about crediting feature films (which, absolutely the primary source credits should be sufficient save for uncredited or Alan Smithee-type roles). Instead, it more often is related to TV guest spots. I'm not going to question if Carrie Fisher was in Star Wars since I know exactly where to look, but I would have an extreme problem of verifying her guest on Laverne and Shirley, because I'd have to scour every episode to find that credit. One aspect of WP:V is making sure to narrow down where one can verify something if the work is too large to review easily (eg chapter or page number for a book reference), so we'd need that for these TV spots. And because IMDB is user-generated, even if there are paid-for people vetting them, it still prone to error. --Masem (t) 06:36, 7 February 2018 (UTC)[reply]
Except properly formatted Filmographies are supposed to list the episode title for guest stints, so if it's done properly, you'd only need to find the specific episode of Laverne & Shirley listed, and check the credits for that episode... The only place this really becomes an issue is for recurring cast of TV series, as there are too many episodes to list individually for those, and the actor won't be listed in the main credits of the TV show – however, even with recurring cast, the seasons that the actor appeared in as a recurring cast member should be listed in the Filmography which would help narrow down where to look to verify for that. --IJBall (contribs • talk) 19:57, 8 February 2018 (UTC)[reply]
Technically, yes, such guest roles should be id'd by episode name, episode number, and season. Most aren't to start. But even when they are, most episodes do not have stand-alone articles (blue-linked) so these should still have a proper ref even if citing the primary source (a properly cited ref to the episode). IMDB still doesn't work for this. --Masem (t) 20:22, 8 February 2018 (UTC)[reply]
  • Don't cite IMDb It's USERG, and, for what it's worth, if we can implicitly cite films and TV shows themselves as sources for the plot summaries, isn't it, if anything, less unbecoming to implicitly cite the film/TV opening/closing credits for this or that person having worked in this or that capacity on the work? The only case I can think of where that would be a bigger problem than using the works themselves for fictional information is cases of homonymy, and honestly in those cases IMDb is at least as likely to get it wrong as we are. I mean, ideally, we would have professionally published secondary sources written by experts in the field for most of this information, but the films themselves are at least as good as IMDb. Hijiri 88 (聖やや) 07:54, 7 February 2018 (UTC)[reply]
  • What about AllMovie.com. I'm pretty sure that its sister site AllMusic is consider RS. Should we start recommending AllMovies over IMDB for stuff like this? --Jayron32 15:03, 8 February 2018 (UTC)[reply]
  • Absolutely not. IMDb is particularly a disaster about upcoming/future film and TV projects, but even the entries for older releases are subject to fraud and manipulation by unscrupulous submissions to the IMDb/database. FWIW, I don't necessarily agree that Filmographies must be sourced to secondary sources (though it's certainly preferable if they are...) – credits for released films and TV series would actually serve as legitimate primary sources for that. So that's really more of an issue ITN editors to work out... --IJBall (contribs • talk) 19:52, 8 February 2018 (UTC)[reply]
  • Comment The Film project's stance was recently clarified at Wikipedia_talk:WikiProject_Film#IMDb_citations. Basically the IMDB is a WP:TERTIARY source and it is only reliable as a source for content that has come directly from another reliable source. WP:CITEIMDB briefly covers this (for WGA credits and MPAA ratings) but you can find a full list of its partners at IMDb Partners. All other content on the main IMDB site is user-submitted and the IMDB should not be used as a source for user-submitted content. It is probably accurate in most cases but it does not have a reliable error checking procedure. Indeed, it is so frustrating getting corrections into IMDB that one sometimes wonders how anything gets into it all! Betty Logan (talk) 20:31, 8 February 2018 (UTC)[reply]
  • Dear god no - I'd rather add a CN tag than use IMDB as a source!, IMDB should never be added as a source anywhere because A) It's user-submitted which in essence is like our site, and B) It's prone to vandalism and I even come across one that was a BLPVIO and is something that would've without a doubt been revdelled here so no we shouldn't touch that site with a 10ft barge pole!. –Davey2010Talk 21:56, 8 February 2018 (UTC)[reply]
  • Don't cite IMDb. You can use primary sources and "cite AV media" or "cite episode" if you see the actor's name and role appearing in the closing credits. Secondary sources would be better. AngusWOOF (bark • sniff) 03:38, 9 February 2018 (UTC)[reply]

RFC: Should Wikipedia have lists of transportation service destinations?

Should we update WP:NOTDIR to explicitly state that lists of transportation service destinations are outside the scope of Wikipedia? What is the relation ship between WP:NOTDIR and WP:GNG for transportation related lists? BillHPike (talk, contribs) 23:50, 9 February 2018 (UTC)[reply]

Background

For transportation services, we have many lists of verbose lists of destinations served by those services:

In a recent VPP dicussion, a consensus was reached that it was not appropriate for Wikipedia to have lists of airline destinations (special:diff/821923737). In that RFC, the closer noted that, per WP:NOTDIR, these lists were inappropriate. In a related AfD, Spartaz closed by noting that, like WP:BLP1E, WP:NOTDIR supersedes WP:GNG. BillHPike (talk, contribs) 23:50, 9 February 2018 (UTC)[reply]

Notifications

Previous RFCs on this topic has been impacted by canvassing. For transparency, please only leave neutrally worded notifications and list them in this section.

Comments

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