Wikipedia:Village pump (policy)

"WP:VPP" redirects here. For proposals, see Wikipedia:Village pump (proposals).

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

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.

« Archives, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192

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)

---

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)

• 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)
  • Comment. While we're at it, it might be a good time to discuss the use of "miniseries" also. --woodensuperman 09:38, 9 January 2018 (UTC)
• 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)
• 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)

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)

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)

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)

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)

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)

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)

• 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)
• Oppose per SMcCandlish and Netoholic. Would lead to endless special pleading and wheel warring. James (^talk/_contribs) 13:47, 9 January 2018 (UTC)
• 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)
• 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)
• 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)
• 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)

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)

• oppose my views are identical those already expressed BURLEY-XXII 07:32, 15 January 2018 (UTC)

Extended content

Another comment on "miniseries". While having a look at Category:American telenovelas just now, I realised how glaring the inconsistency is. Compare, for example Category:American television sitcoms. One of the articles in the telenovela category is even called The Starter Wife (miniseries)! --woodensuperman 13:55, 11 January 2018 (UTC) 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) Agree, let's keep on topic. -- Netoholic @ 04:59, 12 January 2018 (UTC)

• 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)

• 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)
• 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)

 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)

• 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)

---

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.

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)

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)

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)

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)

• Simple solution.... don’t use the template. Blueboar (talk) 11:44, 24 January 2018 (UTC)
  • 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)
• 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)
  • 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)
    • 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)
      • 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)
• 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)
  • 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)
• 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)
  • 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)

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)

• 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)

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)

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)

• Just axe these sections. They're useless trivia. KMF (talk) 04:12, 28 January 2018 (UTC)

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. Cullen³²⁸ Let's discuss it 05:10, 28 January 2018 (UTC)

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)

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)

• 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. ‑‑Yodin^T 12:19, 28 January 2018 (UTC)
• 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)

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)

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)

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)

• It's simple. Include every single individual who was born/died on any given day. The Rambling Man (talk) 07:34, 29 January 2018 (UTC)

@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)

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)

• 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)
• 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)
  • 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? ‑‑Yodin^T 16:17, 29 January 2018 (UTC)

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)

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)

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)

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)

• No. Critreria is not needed. L3X1 Become a New Page Patroller! (distænt write) 15:29, 31 January 2018 (UTC)

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)

• 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)

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)

• 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)

B-class isn't exactly a objective criteria..anyone can change ratings.Galobtter (pingó mió) 09:44, 4 February 2018 (UTC)

• 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. ‑‑Yodin^T 12:39, 4 February 2018 (UTC)

• 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)
  • The snag with this is - what do we do if, for example, "Michael Jackson" has not achieved GA status? Deb (talk) 09:39, 5 February 2018 (UTC)
    • Work on the Michael Jackson article and GET it to “Good article” status? Blueboar (talk) 11:17, 5 February 2018 (UTC)

• There are 6,490 biographies classified as GA and above,[1] making about 18 per day of the year. No Thomas Jefferson, no Mussolini, no Beethoven, no Mozart ... All these are B's and I'm starting to think we may have to go with B-class and above, recognising the flaws. I'd have preferred to base it on importance of person rather than quality of article, but neither Top-importance nor Vital articles will yield nearly enough names, and the difficulties of establishing any other criterion of importance are obvious: Noyster (talk), 11:10, 5 February 2018 (UTC)

I'm thinking limiting it to B articles might work quite well. Deb (talk) 11:44, 5 February 2018 (UTC)

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)

"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)

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)

@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. ‑‑Yodin^T 21:53, 7 February 2018 (UTC)

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)

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)

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

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)

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)

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)

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)

And it was my bad for not doing that instead of the plain revert. ―Mandruss ☎ 19:28, 28 January 2018 (UTC)

• 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. –Davey2010^Talk 19:43, 28 January 2018 (UTC)

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)

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) 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) 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) 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)

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)

• Support removal--Per OD and that's how we normally do things.Winged Blades^Godric 11:58, 29 January 2018 (UTC)
• Support removal as per the template instruction Atlantic306 (talk) 12:17, 29 January 2018 (UTC)
  • The "template instruction" is only about the text within the box of the closed discussion. It doesn't (and shouldn't) ordain what text should appear outside it. – Uanfala (talk) 00:20, 31 January 2018 (UTC)
• 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.). ‑‑Yodin^T 12:52, 29 January 2018 (UTC)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• The comment should be transferred to the talk page of the closed AfD. Xxanthippe (talk) 21:36, 29 January 2018 (UTC).
• 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)
• 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)
• 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)
• Keep but move outside the box per Uanfala. Double sharp (talk) 06:32, 31 January 2018 (UTC)
• 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)
• Keep but move outside the box. (Technically, that's moving the box and/or the comments in it, in a relativistic way) The whole "WP:consensus can change" thing implies that no discussion is ever truly closed - only the box is closed. Wnt (talk) 12:24, 15 February 2018 (UTC)

Infoboxes on Biographies

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)

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)

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)
  • 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)
• Oppose no need to dumb down. - Sitush (talk) 03:27, 30 January 2018 (UTC)
• 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).
• 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)
• 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)
• 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)
• 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)
• 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)

  Not a bad way to incentivize substantial article improvements. Upgrade an article and get an infobox today!! ―Mandruss ☎ 13:50, 30 January 2018 (UTC)

  That is not necessarily how it would be gamed. See my comments in the discussion section. - Sitush (talk) 14:19, 30 January 2018 (UTC)

• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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. GMG^talk 16:42, 30 January 2018 (UTC)
• 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)
  • Is that not effectively what WikiData is doing? --Masem (t) 17:03, 30 January 2018 (UTC)
• 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. –Davey2010^Talk 16:58, 30 January 2018 (UTC)
• 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)
• 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)
• 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)
• Oppose - Concerning biographies? infoboxes should be limited to politicians, sports figures, religious leaders. GoodDay (talk) 18:40, 30 January 2018 (UTC)
  • 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)
    • 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)
      • For any bios considered iffy concerning infoboxes? We have the option of a collapsed infobox. -- GoodDay (talk) 21:04, 30 January 2018 (UTC)
      • 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)
        • 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)
• 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)
• 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)
• 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)

  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)

• 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)
• 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)
• 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)
• Oppose IBs over simplify and do not allow for the nuances necessary in many articles. SagaciousPhil - Chat 08:13, 31 January 2018 (UTC)
• 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)
• Strong oppose. Unnecessary BURO CREEP. Adequately addressed at this time through individualized talk page consensus. James (^talk/_contribs) 23:51, 31 January 2018 (UTC)
• 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).
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)

• 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)

• 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)

• 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)
• Support L3X1 Participate in a deletion discussion! (distænt write) 18:26, 2 February 2018 (UTC)
• 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)

  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)

• 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)

  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)

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)

We probably have had enough free wheeling 'what to do's?' (just look at above, so many are just rather vaguely giving their own personal standards of use). There are several interrelated issues about process and form, default rules and directions, which a good faith smaller working group (having a structured discussion, ala mediation) could really work and vet, giving several multiple option to the wide body of editors -- Alanscottwalker (talk) 14:18, 10 February 2018 (UTC)

• 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)

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? GMG^talk 19:11, 31 January 2018 (UTC)
  • 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)
    • 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)
      • 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)
        • 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)
          • 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)
          • @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)
            • 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)
              • 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)
                • 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)
                  • 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)
  • (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)

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)

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)

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)

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)

• 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)

Definitely shouldn't be linked to article rating/quality Galobtter (pingó mió) 12:54, 30 January 2018 (UTC)

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)

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)

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)

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)

The last of your options, I suspect. - Sitush (talk) 13:14, 30 January 2018 (UTC)

• Mmm. I'd be interested to see if an infobox for Homer could benefit the article. Last time wasn't a great success but I expect Wikidata will be able to improve things. Thincat (talk) 13:13, 30 January 2018 (UTC)

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)

• This is the current policy. To overturn that would require a motion at WP:ARCA. --Redrose64 🌹 (talk) 13:29, 30 January 2018 (UTC)

  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)

  You beat me to it. ―Mandruss ☎ 13:42, 30 January 2018 (UTC)

  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)

  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)

  I'm guessing Rose is suffering from Generalized Infobox Fatigue (GIF). ―Mandruss ☎ 15:14, 30 January 2018 (UTC)

  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)

  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)

• 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)

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)

• 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)

• 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)

• 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)

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)

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)

• 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)

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

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)

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)

But local consensus cannot over-ride community consensus? - Sitush (talk) 20:26, 31 January 2018 (UTC)

WikiProjects are usually given leeway. Though sometimes they can clash, when their interests overlap. GoodDay (talk) 20:29, 31 January 2018 (UTC)

So if the Biography wikiproject doesn't go for this, the entire thing would collapse? - Sitush (talk) 20:30, 31 January 2018 (UTC)

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)

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)

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)

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)

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)

So what to do when projects disagree? See WP:ADVICEPAGE.--Moxy (talk) 13:03, 1 February 2018 (UTC)

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)

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)

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)

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)

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)

​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)

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)

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)

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)

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)

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)

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)

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)

• 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)

  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)

• 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)

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)

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.

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)

• 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)
• 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)
• 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)
• 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)
• 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)
• 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)

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)

(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)
• 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)
  • As I said before, this information contradicts that (WP:COMMONNAME per WP:RS): [5], [6]. I have seen other sources use "Anime television series" as well. - Knowledgekid87 (talk) 06:07, 1 February 2018 (UTC)

    What's NGRAMMING anime and tv series to each other go to do with anything? (television show is much more used than anime btw). I'm talking about when referring to these animes, TV series and variants (tv show, television series) etc are used more in more general sources than anime. Galobtter (pingó mió) 06:12, 1 February 2018 (UTC)

    Anime doesn't just cover television series so when referring to x work more sources either use Anime, Anime TV series, Movie, or OVA. - Knowledgekid87 (talk) 06:15, 1 February 2018 (UTC)

    TV series are (TV series). The rest are (film). -- Netoholic @ 06:24, 1 February 2018 (UTC)

    We have TV series articles which are about more than just TV series. This is normal when spinoff movies, novelizations, comics, etc. aren’t notable enough for their own articles. The primary subject is still the subject of the article. When it’s an overview article for a media franchise, we use “franchise.” —67.14.236.50 (talk) 12:32, 1 February 2018 (UTC)

    This COMMONNAME argument fails if you realize that almost all TV series are described by their genre, in the general public. Survivor is a reality show, General Hospital is a soap opera, etc. Article disambiguation is more about WP:CONSISTENCY, which is why we generalize to use (TV series), (film), etc. -- Netoholic @ 06:24, 1 February 2018 (UTC)

• 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)
• 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)
  • 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)
    • • Because no reliable sources will refer to it as a TV series. They will call it a video series or an OVA series. WP:V trumps any MOS guideline. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 18:42, 1 February 2018 (UTC)
    • To echo this, a home media release (just like a streaming service) is designed primarily to be viewed on a television - that's why "TV series" is used to describe them. Even when there are potentially other viewing options, such as on a phone or tablet or PC. -- Netoholic @ 10:20, 1 February 2018 (UTC)
      • However, a TV series is a series that originally aired on TV. Go to any reliable source and that's what it will say. See my comment above. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 18:42, 1 February 2018 (UTC)
        • @Nihonjoe: Netflix’s House of Cards did not air on TV. We still dab it as a TV series. Same for the others Netoholic mentioned.
          @Netoholic: The problem I find with applying the same logic to home video releases is the lack of anything analogous to a TV network. With VOD or streaming, that role is filled by Hulu or Amazon Prime or whatever provider. It’s definitely more of a stretch when the primary release is on physical media that you have to get into your house before you can watch it. —67.14.236.50 (talk) 22:48, 1 February 2018 (UTC)
  • WP:NCTV also supports the use of (serial), if that's more appropriate. -- Netoholic @ 10:15, 1 February 2018 (UTC)
    • 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)
      • 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)
        • 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)
          • 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)
            • 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)
              • 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)
      • 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)
        • Oh, did you not read what I wrote above? Let me help you: I would be fine using "(series)" for OVA series, and using "(film)" for any standalone OVA would also be fine. Stop beating a dead horse. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 23:31, 1 February 2018 (UTC)
          • How is this putative OVA series any different from this series? All the installments of that series are films. --Khajidha (talk) 16:19, 2 February 2018 (UTC)
            • @Khajidha: That series is one theatrical film and a bunch of direct-to-video films. Calling them all films is fine. That's what all the reliable sources say they are. I'm saying to use what reliable sources use to disambiguate them. If the sources call them "films", that's fine. If they call them "OVAs", then use that. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 21:52, 2 February 2018 (UTC)
              • OVAs are defined as direct to video films. --Khajidha (talk) 07:57, 3 February 2018 (UTC)
                • Just noting that foreign-language RSes are useless for en.wiki disambig purposes, and most of the English-language "reliable sources" that shun "direct-to-video film", "straight-to-DVD movie", "video movie", "DVD film" and everything in between in favour of "OVA" are generally questionable-at-best fan sources written by authors who (apparently?) don't realize that "original video animation" is wasei-eigo and is ungrammatical in regular English. "Animation" is not a countable noun. My students (in a Japanese junior high school) might think you can say "animations" in English, but native speakers would overwhelmingly (as in 99.999%) prefer "animated films". I have never seen a self-reflective piece on ANN or similar sites that actually addressed this problem; I have seen self-published YouTube videos by anime fans (which by any objective measure are just as good for Wikipedia purposes as ANN articles, honestly, but I know that notion is not popular) that make such cases, but tend to be dismissed as "trolls". Hijiri 88 (聖やや) 22:14, 6 February 2018 (UTC)
          • Or how is it different from this series? Which is described as a TV series. --Khajidha (talk) 16:27, 2 February 2018 (UTC)
            • @Khajidha: Nowhere in the article is it described as a TV series. It's desribed in the lead as a "direct-to-video series". ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 21:52, 2 February 2018 (UTC)
              • You didn't look at the categories. --Khajidha (talk) 07:57, 3 February 2018 (UTC)
• 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)
  • 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)
    • 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)
    • 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)
• 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)
• 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)
• 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)
• 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)

  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)

  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)

  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)

  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)

  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)

  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)

• 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)
• No Disambiguate by form of media, not genre. (TV series) or (film) is sufficient. --Jayron32 19:19, 1 February 2018 (UTC)
• I've notified WP:DAB AngusWOOF (bark • sniff) 19:53, 1 February 2018 (UTC)
• 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)
  • To my mind, no, an MOS page should not be able to override NC pages. I’m not sure what the consensus view on this is. —67.14.236.50 (talk) 23:21, 2 February 2018 (UTC)
    • WP:NCTV, WP:NCFILM, MOS:ANIME, and MOS:JAPAN are all guidelines, so they have equal authority as far as that goes. They each apply to specific areas (or groupings) of articles. It may be good to form a group that creates a WP:NCANIME or WP:NCJAPAN, even if they just point to already existing guidelines. Having them would avoid kerfuffles such as this one. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 00:31, 3 February 2018 (UTC)
      • @Nihonjoe: To my mind, an NC page is an authority (inasmuch as a guideline can be an authority) on how to decide a title, and an MOS page is an authority on presenting an article’s content. They should never conflict, because they have entirely different scopes. If someone decides that the titles of, I don’t know, Greek restaurants need special consideration, that belongs in WP:NCRESTAURANT, not MOS:TAVERNA. If we can’t drum up support to get it in the NC page, clearly we don’t have consensus to insist on its use. —67.14.236.50 (talk) 22:59, 4 February 2018 (UTC)
• 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)

  @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)

  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)

• 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)
  • 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)

    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)

    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)

    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)

    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)

    @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)

    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)

    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)

    We shouldn't have (animation) or (cartoon) as a disambiguator either if it can be relegated to TV series or film series. AngusWOOF (bark • sniff) 23:15, 12 February 2018 (UTC)

• 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)
• Oppose. We should not be disambiguating by genre unless all other disambiguation options are exhausted. --woodensuperman 16:45, 9 February 2018 (UTC)
• Comment, as far as I know in Japan foreign cartoons are also called "Anime" and would this change also mean that something from South Korea becomes an "Animaesyon"? "TV series" works fine. --Donald Trung (Talk) (Articles) 09:31, 12 February 2018 (UTC)

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)

I already addressed this above. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 23:24, 1 February 2018 (UTC)

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)

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)

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)

This. So much this. --Khajidha (talk) 14:29, 2 February 2018 (UTC)

• 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)
• 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)
  • I would think so, yes. —67.14.236.50 (talk) 22:44, 2 February 2018 (UTC)
• (animated series)? Curly "JFC" Turkey 🍁 ¡gobble! 00:00, 5 February 2018 (UTC)
  • 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)
    • 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)
      • 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)
        • "Animation is always video"—no, "video" is not used as a disambiguator if it means "moving pictures". It should be obvious why. Or are you suggesting we move all (film)s to (video)? Curly "JFC" Turkey 🍁 ¡gobble! 01:54, 5 February 2018 (UTC)
          • Films are standalone video productions. TV series are episodic video productions that air on television networks or streaming video services. ????? are episodic video productions that are not aired. Any of these may be animated or not; we don’t use “animated film” unless there’s a conflicting non-animated film, etc. —67.14.236.50 (talk) 02:19, 5 February 2018 (UTC)
            • So suggest we move all (film)s to (video). I could use a good laugh. Curly "JFC" Turkey 🍁 ¡gobble! 02:49, 5 February 2018 (UTC)
              • It would be “video film,” actually, which would be redundant. As would “animated video film.” What dab would you suggest for a non-TV episodic video series that may or may not be animated? A series, yes, but a series of what? —67.14.236.50 (talk) 02:56, 5 February 2018 (UTC)
                • Enough of this back and forth, lets just stick with "OVA" as it is a neural term. - Knowledgekid87 (talk) 03:36, 5 February 2018 (UTC)
                  • Neutral? I consider it jargon. Just say the thing that the OVA is: a film, a video series, whatever. —67.14.236.50 (talk) 03:50, 5 February 2018 (UTC)
                  • OVA is overspecific jargon that will meaning nothing to most readers. Not a chance.
                    "It would be 'video film' ..."—this is headache-inducing. "Video", at the very least, is ambiguous, as to countless millions it refers to the method of delivery (videocassette, DVD, etc). "Video film" doesn't mean to most people what you'd like it to mean. Curly "JFC" Turkey 🍁 ¡gobble! 04:07, 5 February 2018 (UTC)

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)

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)

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)

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)

Seems like film series would apply.--Khajidha (talk) 10:20, 6 February 2018 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

@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)

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)

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)

@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)

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)

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)

We are getting off topic here, the discussion is about disambiguation. - Knowledgekid87 (talk) 02:37, 7 February 2018 (UTC)

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)

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)

Right, thanks. Corrected. Guess I got the two comments above confused. —67.14.236.50 (talk) 02:46, 8 February 2018 (UTC)

• 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)

  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)

  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)

  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)

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).

• 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)

  Not really as there are Smart TVs, the term refers to a telecommunication medium. - Knowledgekid87 (talk) 02:09, 8 February 2018 (UTC)

  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)

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).

There's no point arguing it with Knowledgekid87, who has trouble separating content from method of delivery. Curly "JFC" Turkey 🍁 ¡gobble! 02:37, 8 February 2018 (UTC) Please strike your comment, mudslinging just makes you look bad. - Knowledgekid87 (talk) 04:10, 8 February 2018 (UTC) Please strike your comment—accusations of PA are "a form of personal attack". My comment was directly on point—your refusal to acknowledge the difference between medium of expression and medium of delivery has become a sticking point in the discussion, and I advised the IP not to exasperate themself arguing at cross purposes with you. Curly "JFC" Turkey 🍁 ¡gobble! 07:04, 8 February 2018 (UTC) Sigh... if you had just struck your comment I wouldn't have to go more into this than should be. You can feel free to disagree with me as other editors have over the years I have been here, but you don't see me saying to other editors "there's no point arguing with ....". Even if I knew you were wrong in an argument I wouldn't say that to another editor about you. - Knowledgekid87 (talk) 14:30, 8 February 2018 (UTC) Sigh ... yes, it's obvious that you don't like to be called out, but it's an issue that needs attention drawn to it, and editors should be warned not to get sucked in. You refuse to strike your PA? Curly "JFC" Turkey 🍁 ¡gobble! 22:11, 8 February 2018 (UTC)

• I'm sure there are other venues to discuss this, lets hold off for now. - Knowledgekid87 (talk) 04:10, 8 February 2018 (UTC)

  Then for the time being, let’s prefer “TV/video/film series” over the more jargony “OVA” until this question is settled at another venue. —67.14.236.50 (talk) 23:25, 8 February 2018 (UTC)

• It really depends on whether disambiguation will ever stretch to the point where it would require "original" "animated" "video", and whether year and country of origin would not be enough to do the job. AngusWOOF (bark • sniff) 23:44, 12 February 2018 (UTC)

No legal threats discussion

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)

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)

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)

• 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. –Davey2010^Talk 21:37, 2 February 2018 (UTC)

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)

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. –Davey2010^Talk 21:59, 2 February 2018 (UTC)

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)

• 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)
  • 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)
    • 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)

  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)

  • • • 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)
• 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, –Davey2010^Talk 22:54, 5 February 2018 (UTC)

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)

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)

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)

You may be interested in following the discussion at phab:T91201 and mw:Page_Previews/preferences. — xaosflux ^Talk 14:14, 5 February 2018 (UTC)

"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)

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)

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)

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)

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)

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)

Stigmatizing language regarding suicide

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.

---

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)

• "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)

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)

"[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)

And that excellent point is all too often ignored, often by those with ulterior motives or their useful idiots. Too many want to use Wikipedia as a platform to political correctness, and that is not our goal. An encyclopedia should never be on the edge of cultural change. Dennis Brown - 2¢ 22:01, 11 February 2018 (UTC)

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)

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)

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)

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)

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)

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)

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)

*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)

(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)

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)

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)

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)

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)

• 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)
• "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)

  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)

  "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)

  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)

  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)

  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)

  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)

• 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)

  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)

  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)

  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)

  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)

  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)

  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)

• 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)
• 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)
  • 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)
    • 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)
• 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)

• 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)

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)

• 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)
  • TonyBallioni: English has always had a variety of options, including "kill oneself". I hope you're not suggesting mandating "commit suicide" as the only "[s]tandard [in] written and spoken English". Curly "JFC" Turkey 🍁 ¡gobble! 11:34, 10 February 2018 (UTC)
    • I said nothing resembling that, and languages don’t work that way, so even if we did mandate “committed suicide” it wouldn’t matter as people would use whatever came naturally. That was my entire point: standard English has “committed suicide” as the most frequent way of expressing it. Playing games with language by mandating a different usage wouldn’t work and would be pointless. TonyBallioni (talk) 13:37, 10 February 2018 (UTC)
      • TonyBallioni: So if an editor in good faith believed they were improving the article by changing the wording to something they believed was less problematic, there'd be no grounds to revert, right? Curly "JFC" Turkey 🍁 ¡gobble! 21:25, 11 February 2018 (UTC)
        • That's irrelevant to this conversation, which is asking if we should do it as a matter of course: the answer to that being no. TonyBallioni (talk) 21:28, 11 February 2018 (UTC)
          • Of course it's relevant: you wrote "Standard written and spoken English is committed suicide. We use that."—except that you're admitting that we use others as well. When we recognize problematic wordings, we find ways to avoid them—I assume you're familiar with Wikipedia:Manual of Style/Words to watch ... or is that CENSORSHIP, too? Of course, what I'm getting at is that it's not censorship to you a phrase that has the same intended meaning without all the unintended loaded baggage. "Commit suicide" is one of these loaded terms. Curly "JFC" Turkey 🍁 ¡gobble! 21:36, 11 February 2018 (UTC)
            • Berean Hunter has already explained in great detail below with sourcing as to why this is standard written English and the most commonly used term. N-grams also confirms this, with committed suicide having a 75% higher usage than killed himself, killed themselves, and killed herself combined. If someone were to use killed themselves on their own, it wouldn't be a problem. If someone were to systemically go through removing the phrase committed suicide against consensus and in contravention of the most common English usage, they'd probably get blocked for disruptive editing. It's a difference between allowing alternate uses, and mandating an alternate use as opposed to the most common use. TonyBallioni (talk) 21:53, 11 February 2018 (UTC)
              • TonyBallioni: The terms in Wikipedia:Manual of Style/Words to watch also tend to have statistically high usage—"claim" is an extremely common word in RSes, and yet we have MOS:CLAIM. Would you block someone for making changes to an article in line with MOS:CLAIM, or, say, MOS:LQ if the maintainers of the articles formed a "consensus" against it? After all, changing the punctuation in an AmEng article to LQ would be "in contravention of the most common [AmEng] usage"—far, far more so than "commit suicide". Curly "JFC" Turkey 🍁 ¡gobble! 22:33, 11 February 2018 (UTC)
• 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. –Davey2010^Talk 23:35, 8 February 2018 (UTC)

• Oppose The wording by Senator John Walsh: Far too often, we're leaving our veterans to fight their toughest battles alone, Senator John Walsh told CNN. The Democrat from Montana is the first Iraq War combat veteran to serve in the United States Senate. Last month he introduced legislation aimed at reducing the number of military veterans who commit suicide. The Article in CNN [10].--Maxim Pouska (talk) 07:03, 11 February 2018 (UTC)

• Oppose We use The Chicago Manual of Style to influence our Manual of Style but not the AP Style Guide. The latter offers guidance to reporters but is not an authority on the matter. Indeed, this editorial by a copy editor who has had the situation in their lives multiple times and has chosen to reject the AP Style Guide recommendation carries more weight. It shows that the intent of the guidance misses the mark and doesn't help, but rather complicates. Journalists have not accepted the AP guidance and you can easily spot check (example 1 & example 2) and see that it is not current accepted practice. At the present, we have more than 15,500 occurrences of the phrases "committed suicide", 2000 "committing suicide" and 5500 "commit suicide" which shows that it is not archaic but rather common usage. In professional publications the usage is clear.
   — Berean Hunter (talk) 15:12, 11 February 2018 (UTC)
  • Here is a list of the external style guides that carry weight for MOS. They do not include the AP guide.
     — Berean Hunter (talk) 15:33, 11 February 2018 (UTC)
• Oppose Wikipedia follows, it does not lead. In this case 'commit(ed) suicide' is the proper term, both idiomatically and in formal/technical prose. If there is a de-stigmatization campaign working to change the common usage, more power to them - maybe they will help some people. However, Wikipedia content can not and should not be a trail-blazer on that or any other effort to change social or linguistic norms. We change after the dust settles. We do not contribute to the making of the dust. Jbh ^Talk 20:04, 11 February 2018 (UTC)
• Oppose Per my comment above. Dennis Brown - 2¢ 22:01, 11 February 2018 (UTC)
• Question It's clear that there is a consensus that there shouldn't be a policy against the phrase committed suicide. I've stated my opinion, but I respect the process and concede that this seems to be settled. What I'm still unclear on is what policy specifically prohibits me from changing the phrase to something like "died by suicide." Although it has been correctly stated that many sources still use committed suicide, many also use died by suicide. I don't see how the policy on censorship applies, as that policy seems to mostly describe the removal of content or the significant changing of meaning, and changing word choice does neither in this case. The policies on Advocacy and Righting Great Wrongs seem to address edits that go against Wikipedia's verifiability and neutrality, neither of which I believe my edits did. On what grounds, specifically, are my edits being reverted? TylerRDavis (talk) 16:06, 12 February 2018 (UTC)
  • Now, it is based on the policy of consensus (you don't have it), the guideline of disruptive editing (which is what it will be if you change it again anywhere on Wikipedia since it will be against consensus), and the guideline concerning conflict of interest. Your pushing of the AP guide reflects that conflict of interest, now doesn't it? I know that it does. I think that you also have another COI by pushing the agenda of a known group trying to effectuate changes for their purposes. Trying to right great wrongs...and it doesn't matter that you don't believe your edits fall under that. What matters is what the blocking admin thinks. I see you needling away over at Talk:Kevin Carter, trying to twist how things are going here to still get that change. Drop the stick. If you keep needling away at this in face of what you have been told then an admin will need to block you as a POV pusher. You won't be doing any more of these changes. Let it go.
     — Berean Hunter (talk) 21:34, 12 February 2018 (UTC)
    • Berean Hunter: Are you saying that if this editor changes "committed suicide" in an article to "died by suicide", and nobody at that article opposes it (there's no BRD or anything), and Kevin Carter doesn't revert it back if someone reverts, you'd still have him blocked? Curly "JFC" Turkey 🍁 ¡gobble! 22:46, 12 February 2018 (UTC)
      • It has already been opposed here with a clear consensus so in your scenario above "nobody at that article opposes it" doesn't matter. It has been said here by a wider community consensus. He would be disruptive to try to change this anywhere. A clear signal has been sent and any changing of this phrase is IDHT so yes, I would endorse blocking at that point. This editor has been inactive for five years and then goes active to advocate for a cause that this community does not support...and we're not going to have it pushed on us.
         — Berean Hunter (talk) 23:11, 12 February 2018 (UTC)
        • Berean Hunter: Will blocks be handed out to those who change an established "died by suicide" to "committed suicide"? Curly "JFC" Turkey 🍁 ¡gobble! 00:34, 13 February 2018 (UTC)
    • Gotcha. I was simply asking because the consensus of this previous conversation was not against the phrase "died by suicide" but simply against a policy mandating the removal of "committed suicide" and that seems to be where consensus might fall here. Supposing that this conversation right here hadn't happened, the previous consensus explicitly states that there is no policy against other phrasing. Perhaps you're right that the discussion on the Kevin Carter article was not in good faith, but I believed, I think rightly, that previous consensus and the one forming here supported usage of all language without prohibiting any of it. It's upsetting that my request for comment on that assertion was been met with a threat to ban, and implications of some sort of conflict of interest. I also take issue with your comment below implying that my level of activity has anything to do with the validity of my argument. That being said, I apologize for jumping the gun and will wait for an official consensus. TylerRDavis (talk) 23:45, 12 February 2018 (UTC)
      • Your inactivity stretch of five years is followed by you doing one thing...trying to push your POV about this (perceived) politically correct phrase substitution. You aren't doing that for WP's better interests, you are trying to do it for a cause that initiated you to wake your account up. No one from the WP community asked you to do this word policing. The message here is to stop.
         — Berean Hunter (talk) 00:35, 13 February 2018 (UTC)
        • Understood. Also, I don't know what you mean by your implication of a conflict of interest, but if you believe that I am working on behalf of an organization, please go through the proper process for reporting a conflict of interest. Threatening to divulge personal information on a talk page (which appears to be what you are doing), even regarding a potential conflict of interest, seems to be prohibited under the harassment policy regarding outing. It is also a toxic form of debate. To be clear, I am not editing on behalf of an organization. This may fall under advocacy, but certainly not COI. This is an ad hominem attack.TylerRDavis (talk) 04:58, 13 February 2018 (UTC)
          • Your statement, "The AP Stylebook, and therefore many U.S. newspapers, is against the term." will be used against you when evaluating your position on a COI and your real motives here. Who is against it? Would that be a "those guys over there"? ...or maybe you could select a pronoun that would be more fitting and less disingenuous in its presentation. If "they" are against it then "they" don't have any business trying to sway the community here without revealing who "they" are. To do so is deceptive. Period.
             — Berean Hunter (talk) 09:46, 13 February 2018 (UTC)
            • I'm not seeing anything that looks like a COI in the statement you link to, and your argument is significantly undermined by his statement there: "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." You'll need a stronger argument and far better evidence than this. Curly "JFC" Turkey 🍁 ¡gobble! 10:48, 13 February 2018 (UTC)
  • TylerRDavis I'll try to answer your question: I'm still unclear on is what policy specifically prohibits me from changing the phrase to something like "died by suicide." A big part of how wikipedia works is that we welcome new people to boldly begin editing and making good faith improvements. We don't expect people to know all of the policies and guidelines etc. We expect that attempts to improve will, on average, be helpful. We expect any problems will get cleaned up, and we expect that people will learn as they go. A key part of "good faith" improvements is respect for community consensus. At this point you are aware that multiple people have reverted edits that change "committed suicide", and you are aware that the community does not consider it an "improvement" to go around re-writing articles to remove committed suicide. As much as you personally feel the edit is an improvement, it is not a good-faith contribution to continue making such edits. The community would consider it disruptive to knowingly continue the conflict. The specific guideline answer is WP:Disruptive_editing. Any persistent behavior that distracts from productive work can potentially receive a block.
    It's fine that you tried to make an improvement. Some other editors disputed the edits. It was discussed. Everyone is expected to respect the outcome so we can all get back to other productive work. We want the topic to stay closed for a good long time because there's clearly no chance consensus is going to change any time soon.
    Someone should put a closure on this discussion. It's SNOWed. I'd close it myself if I weren't a participant. Alsee (talk) 11:10, 13 February 2018 (UTC)
• oppose per WP:RIGHTGREATWRONGS, it isn’t Wikipedia’s purpose to change things, merely to report on them. Iff the majority of sources and style guides change this practice, we obviously should follow, but not before. Beeblebrox (talk) 21:56, 12 February 2018 (UTC)
• Oppose - but could change. I'm sorry about that but the evidence provided by the research and correspondence supplied here is that referring to it as committing suicide is by far the most common way of doing it even if they thin it is stigmatizing. It would be reasonable to refer to it as death by suicide if that becomes common in academic sources without it becoming the most common way in popular sources. I don't know what that frequency is like. Perhaps the OP would like to check on that? Dmcq (talk) 22:23, 12 February 2018 (UTC)
• Oppose For reasons given above, emphasizing these: 1. This is the common, widely used term for it in the English language. 2. "Commit" does not equate to being a crime, so I don't agree with that. While I sure that someone made that argument, I find the argument that a stigma against something generally makes people more likely to do it implausible. If it were found true, it would reverse a big portion of how society works.North8000 (talk) 01:18, 13 February 2018 (UTC)

Uninvolved close?

The consensus couldn't be much more clear. Looking only at formal !votes, it's 11–1 Oppose (I oppose but haven't !voted). The issue has received adequate attention over almost 8 days, discussion of the actual issue has become largely circular and repetitive, and I don't see a reason to continue. The opening comment ends with I am interested in seeing what sort of consensus could be reached on this issue. and I submit that TylerRDavis has his answer. Under these circumstances I see nothing to be gained by discussing his suspected motives, perceived disingenuousness, and so forth. I suggest that some uninvolved editor close the discussion and let people get on with it. ―Mandruss ☎ 10:28, 13 February 2018 (UTC)

Given that the admin Berean Hunter is threatening blocks based on the assumption that TylerRDavis is working under a COI, "discussing his suspected motives" is not really anything we can sweep under the carpet now. Does Berean Hunter have a consensus that TylerRDavis is working under a COI? Could he be threatening blocks under an accusation that has not garnered consensus? Curly "JFC" Turkey 🍁 ¡gobble! 11:11, 13 February 2018 (UTC)

In my view discussion of editor behavior is off-topic in this discussion and out-of-venue on this page. We have places and processes for that. ―Mandruss ☎ 11:16, 13 February 2018 (UTC)

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

Rfc: Change default <math> to be inline

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

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. $\textstyle e^{x}$ vs $\displaystyle e^{x}$.
• 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)

@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)

And especially, the discussion I started at WP:Village pump (policy)/Archive 138#Math block display. --Izno (talk) 20:22, 5 February 2018 (UTC)

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

I added the Question and RFC-template to the above in order to get more input.--Debenben (talk) 22:47, 6 February 2018 (UTC)

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)
• 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)
• Oppose unless benefits are clearer. Xxanthippe (talk) 01:47, 7 February 2018 (UTC).
• 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)

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)

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)

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)

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)

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)

Fairly easy in principle to implement, I'll grant. Sławomir Biały (talk) 01:16, 9 February 2018 (UTC)

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

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)

@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 $A^{T}$, 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 $\sum _{i=0}^{\infty }$. This can be avoided by using the correct inline formatting, either by adding \textstyle or the parameter display="inline", resulting in $\textstyle A^{T}$ or $\textstyle \sum _{i=0}^{\infty }$. If you happen to have a browser/device where the $A^{T}$ 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)

• Oppose anything that would break the formatting in thousands of existing pages. Maproom (talk) 08:07, 9 February 2018 (UTC)

I don't know what I did wrong: I did not expect only support votes, but I expected some comments and discussion on the issue. I'll try to discuss with myself the comments so far:

• Its a global issue: True. The purpose of this Rfc is to gather feedback directly from editors affected by such a change that can be used (e.g. in a discussion on meta) to supplement the feedback I got from German Wikipedia and Wikisource editors. So far I get the impression that the English Wikipedia editors just don't care.
• It's up to the developers: As I pointed out, I had a discussion with Whatamidoing. For now it seems, the WMF does not have any resources to spend on working out a solution or fixing some of the problems.
• The proposal breaks a lot of block formulas: True, although I think "breaking" is a strong word for a less beautiful layout for some equations which is compensated by a more beautiful layout for others. I respect people that do not want the existing articles to change at all. For the math tag this essentially means it cannot get fixed (unless someone can come up with a miracle solution nobody has thought of so far). Consequently this translates into the alternative, which is support for introduction and migration to a new notation.
• It causes confusion among the editors: I would say this proposal would rather reduce the confusion. The argument of creating even more confusion was the main reason why at the German Wikipedia this solution was preferred to the alternative of creating a new notation. Editors can continue to use "default" in the text and get the proper inline formatting. If one is worried by a solution that would treat the indentation markup as a modifier as opposed to also replacing those 82% with a bot: This is not part of the proposal and (in my view) can be discussed after it is decided if the current <math> notation should be rescued or not.
• The benefits are unclear: This could be a reason why people don't want to vote on the issue, but please leave a question or comment, this would help others to make up their mind.
• Introducing \( \) and \[ \] as math delimiters: A great solution. Some background: The two delimiters are the minimal set of LaTeX commands required to get all necessary features. For those that wonder about commands like ref, eqref etc: They can be used inside the delimiters like it is done for align today, which, from a LaTeX (and MathJax) point of view is correct, only a bit more complicated than necessary:

The example
\[\begin{align}
one \label{thefirstlabel}\\ 
two \label{mysecondlabel}
\end{align}\]
as a fraction 
\[\begin{equation}
\frac{\eqref{thefirstlabel}}{\eqref{mysecondlabel}}=\frac{ne}{tw} \label{theresult}
\end{equation}\]
does not make sense. Also, equation \(\ref{theresult}\) does not show that \(\ce{H2O}\) means water.

When adding the javascript above to common.js and removing the syntaxhighlight it already works today. The drawback: This is similar to what was proposed around 2012. I am especially worried that it will be me, having to convince people that mixing the HTML-like wikitext notation with LaTeX commands is worth it and that at the end of the day I have wasted even more time with discussions and achieved nothing.

• A question which did not come up: What does it have to do with MathJax? In principle nothing, because all the problems mentioned in the bullet points are caused by the notation and don't get solved by a new rendering system. I wanted to show how other websites handle it, that Wikipedia is essentially the only website with these problems and some features necessary for being able to convert all current block-formulas. There is some hope: The Mathjax-Node spin-of currently generating the svg images and MathML in Wikipedia will be eaten up by MathJax version 3.0 in the future, creating the possibility that some developers take the opportunity to get MathJax 3.0 fully implemented in MediaWiki.

--Debenben (talk) 16:14, 12 February 2018 (UTC)

• Oppose for reasons given. I have not done much (any?) editing along these lines, but would have little or no objection to a new format if it has any clear benefit, even in moderately unusual situations, but not as a new default. It would have to be a newly added facility and would be up to those benefiting, to discover the documentation. JonRichfield (talk) 05:14, 14 February 2018 (UTC)

Contradictory guidelines about "See also" section: repeat navbox links or not?

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:

• January 2013: Wikipedia talk:Manual of Style/Layout/Archive 9 § Repeating links in See also section: This is mostly a discussion of why guideline 1 above is important.
• November 2015: Wikipedia talk:Manual of Style/Layout/Archive 11 § See also and navboxes: This discussion highlights the contradiction between guidelines 1 and 2 above, but the discussion did not lead to fixing the contradiction.
• February 2017: Wikipedia talk:Manual of Style/Layout/Archive 12 § RfC: remove the proscription against previously-linked terms in the "See also" section?: "Summary: There is strong consensus against the proposed change" of removing guideline 1 above.
• July 2017: Wikipedia talk:Manual of Style/Layout/Archive 12 § A suggested edit in the "See also" guideline: This is another proposal to remove guideline 1 above (especially the part about navboxes), apparently with no consensus.

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

• 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)

• I think we need to go for guideline 2, and reword 1. Jayron makes a very good point. The wording appeared in MOS:NAVLIST with this edit. Previously it was "see Wikipedia:Navigational templates". The wording in MOS:NOTSEEALSO appeared with this edit in 2009. ∰Bellezzasolo✡ Discuss 10:59, 6 February 2018 (UTC)

• There is no contradiction that needs to be fixed. Links to articles highly relevant to a particular article should not be in the See Also section. Hawkeye7 (discuss) 11:20, 6 February 2018 (UTC)

@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)

• I just noticed that there is a current (January 2018) discussion of this issue at Wikipedia talk:Manual of Style/Layout § "See also" section and navigation boxes where, again, there is no apparent consensus to change guideline 1 above. Biogeographist (talk) 13:08, 6 February 2018 (UTC)

• Sounds like the problem is with the mobile version. How about fixing it to show the actual wikipedia instead of some cut down extract thereof? --Khajidha (talk) 13:21, 6 February 2018 (UTC)

I support the idea of Khajidha. --Emir of Wikipedia (talk) 13:28, 6 February 2018 (UTC)

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)

• 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)

@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)

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)

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)

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)

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)

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)

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)

(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)

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)

@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)

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)

• 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)

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. Cullen³²⁸ Let's discuss it 03:02, 7 February 2018 (UTC)

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)

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)

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)

I am not sure if this conversation is still open, but why not technically change navboxes so they can be displayed on mobile? This is already the case for Dutch Wikipedia. Also WP:NOTSEEALSO should be amended as mobile readers aren't exactly a minority. --Donald Trung (Talk) (Articles) 09:25, 12 February 2018 (UTC)

@Donald Trung: One answer to your question "why not technically change navboxes so they can be displayed on mobile?" is in the Quora post by Mark Hetherington cited above. Regarding amendment of WP:NOTSEEALSO, it would not be necessary if/when navboxes are added to mobile view, and there does not seem to be consensus for such a change otherwise: see opposing opinions above and in linked discussions above (most recently at Wikipedia talk:Manual of Style/Layout § "See also" section and navigation boxes). Biogeographist (talk) 17:23, 12 February 2018 (UTC)

Allowing iMDB as a reliable source for filmographies

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'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)

• A primary source is reliable for uncontentious information about the primary aource. The credits of a film are reliable for who is listed in the credits. Only in death does duty end (talk) 18:20, 6 February 2018 (UTC)

How do you know the image isn't photoshopped, is there vetting in place? - Knowledgekid87 (talk) 18:23, 6 February 2018 (UTC)

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)

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)

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)

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)

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)

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. Cullen³²⁸ Let's discuss it 02:47, 7 February 2018 (UTC)

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)

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)

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)

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)

• 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)
• 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)
  • There is also [14]] - Behind the Voice Actors. The screenshots are verified through green checks next to the person's role. - Knowledgekid87 (talk) 15:29, 8 February 2018 (UTC)
• 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)
• 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)
• 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!. –Davey2010^Talk 21:56, 8 February 2018 (UTC)
• 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)
• Unreliable for example the Vicky Kadian bio and 35 cast entries are completely false as he has never had a named role and was banned from Wikipedia for faking an autobio and he still pops up every week or so as an iphopper or new account adding bunches of fake cast entrys. IMDB were made aware 2 months ago and have done nothing. Atlantic306 (talk) 20:02, 11 February 2018 (UTC)

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

RFC: 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 relationship between WP:NOTDIR and WP:GNG for transportation related lists? BillHPike (talk, contribs) 23:50, 9 February 2018 (UTC)

Background

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

• Category:Lists of bus routes
• Category:Lists of railway stations
• Category:Lists of airline destinations

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)

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.

• User talk:Spartaz notified by BillHPike (talk, contribs) 23:57, 9 February 2018 (UTC)
• Message left at Wikipedia talk:WikiProject Airlines left by BillHPike (talk, contribs) 00:12, 10 February 2018 (UTC)
• Message left at WT:WikiProject Streetcars BillHPike (talk, contribs) 00:16, 10 February 2018 (UTC)
• Message left at WT:WikiProject Stations BillHPike (talk, contribs) 00:20, 10 February 2018 (UTC)
• Message left at WT:WikiProject Rapid transit BillHPike (talk, contribs) 00:24, 10 February 2018 (UTC)
• Message left at WT:Wikiproject Trains BillHPike (talk, contribs) 00:26, 10 February 2018 (UTC)
• Message left at User Talk:Beeblebrox BillHPike (talk, contribs) 00:32, 10 February 2018 (UTC)
• Message left at WT:WikiProject Buses BillHPike (talk, contribs) 00:48, 10 February 2018 (UTC)
• Comment left at WP:Deletion review/Log/2018 February 9#Adria Airways destinations BillHPike (talk, contribs) 00:56, 10 February 2018 (UTC)
• Comment left at WT:What Wikipedia is not per suggestion of User:Kusma BillHPike (talk, contribs) 08:13, 10 February 2018 (UTC)
• Message left at WT:WikiProject Lists BillHPike (talk, contribs) 08:19, 10 February 2018 (UTC)
• Message left at WT:Notability. BillHPike (talk, contribs) 02:37, 12 February 2018 (UTC)

Comments

• Strongly oppose if what this poorly-worded RFC is actually proposing—as it appears to be—is a ban on mentioning on where a transport firm operates, or lists of routes from an individual station. Particularly when it comes to railways, the routes operated by any given firm are essential to an understanding of that firm (especially in a fragmented market like the UK, where key routes like London–Birmingham and London–Edinburgh are served by multiple operators using different routes); likewise, the services which run to and from any given station and how those services have changed over time are essential to an understanding of the significance of that station. That doesn't mean we have to include such lists if they're not appropriate, but articles about transportation—a topic which varies wildly both from country to country and within individual countries—are pretty much the poster children for "decisions which should always be made on a case-by-case basis". Aside from anything else, even the tightest interpretation of this proposal, as "only delete pages which have titles in the format [[List of destinations served by...]]"—would wipe out (at the time of writing) 24 Featured Lists. ‑ Iridescent 00:28, 10 February 2018 (UTC)
  (adding) I'll also point out—as it seems to have slipped your mind—that mass deletion has literally just been declared inappropriate in this context with a consensus that these should be dealt with on a case-by-case basis. When a decision is reached that you don't like, it's usually good form to at least wait a few days before forum-shopping to try to get it overturned. ‑ Iridescent 00:39, 10 February 2018 (UTC)
• Comment -- A peak at the 2011 backlog of unreferenced articles shows hundreds of Japanese railway stations and trolley stops. The current count of unreferenced rail transport articles is 22,554 [15] , a tenth of all the unreferenced articles in the English language Wikipedia. I'm not sure why this category gets a pass, when high schools lost the presumption of notability that required only one (1) reference.

Lists of airline and bus destinations will be outdated the day after they are edited. They are simply a waste of Wikipedia resources and editors' time. Rhadow (talk) 00:34, 10 February 2018 (UTC)

• WP:SOFIXIT. The category itself is full of articles that have had references added but did not have their talk page templates updated (e.g. Akabuchi Station and 39th Street (Sacramento RT)), so I would not use it for an accurate count.
• In developed cities, bus routes may go unchanged for years, if not decades, but notability will need to be discussed on a case-by-case basis. Some systems even have articles for individual bus routes that clearly pass notability, e.g. Route 41 (King County Metro), so they should not be judged so broadly. SounderBruce 07:22, 10 February 2018 (UTC)

• Regarding The current count of unreferenced rail transport articles is 22,554, Category:Unreferenced rail transport articles is obviously inaccurate. Looking at the first three articles on that list, they're all referenced; it appears that the tag which adds "this article lacks sufficient inline citations" (my emphasis) to the talkpage (e.g. a specific fact is uncited) is categorising the pages as being completely unreferenced. ‑ Iridescent 09:37, 10 February 2018 (UTC)

• Moral support because it appears to be the opinion of many editors that community consensus only counts if it is codified into policy. However, I would need to see specific wording in order to support fully. The phrasing should allow, for instance, lists of destinations of historical companies and perhaps destination lists embedded within articles. AdA&D ★ 00:38, 10 February 2018 (UTC)

On another note, I fear this situation turning into a trainwreck with a simultaneous DRV taking place. Suppose the DRV results in overturn then this RFC succeeds. What then? AdA&D ★ 00:46, 10 February 2018 (UTC)

AdA&D, you are right. Editors ignore the results of RfC. We need a policy here. Case-by-case has been abused. Rail is different from bus, ship, and airline, whose routes can change daily. A train station requires concrete. A train station article should require independent reliable press coverage, else it is not notable. It can go in a list of stations on the line. As to the modes of transport not tied to a fixed origin-destination pair, that's basically a schedule and doesn't belong. Any edits will be out of date the next day. Let the article point to the subject's schedule website. Rhadow (talk) 00:49, 10 February 2018 (UTC)

Procedurally, I believe that DRV should be overturned. The entire procedure of that RfD/AfD/DRV has been bizarre from start to finish, was too limited in scope to be true policy, and is why we're here now. If we decide here transport destination articles aren't encyclopedic, we reopen the deletion discussion - I'll even side with deleting those lists if consensus exists. What's important to me is deciding when and how this information gets displayed. SportingFlyer (talk) 02:19, 10 February 2018 (UTC)

• Oppose The proposer fails to provide any justification for this blatant bias and it is our policy that Wikipedia is not censored. People who don't like planes, trains and automobiles should please read about whatever it is that interests them instead. Per WP:NOTPAPER, there is plenty of room for any number of topics. Andrew D. (talk) 01:05, 10 February 2018 (UTC)
• Speedy Close - We need to wait for the DRV to finish before we start on something like this. - Knowledgekid87 (talk) 01:11, 10 February 2018 (UTC)

Nah. If we wait for the decision on a single article, we'll never get to the policy discussion. There will always be "one more discussion" to finish before we tackle the big issues. Rhadow (talk) 01:18, 10 February 2018 (UTC)

@Knowledgekid87: A major argument made in the deletion discussion was that the previous RFC was binding. I think it is best for us to have an RFC to update the policies so we can avoid wikilawyering at AfDs and DRV. BillHPike (talk, contribs) 01:20, 10 February 2018 (UTC)

This is a mistake though in my opinion as these are three huge topics. I would be fully opposed to railroad stations as they are more concrete in history and notability. - Knowledgekid87 (talk) 01:30, 10 February 2018 (UTC)

Knowledgekid87, please clarify what you mean by "I would be fully opposed to railroad stations." Right now, there are several thousand railway station articles without a single reference. What do you favor? Rhadow (talk) 01:36, 10 February 2018 (UTC)

Those are article fix up issues that can be handled on a case by case basis as would any normal AFD go. - Knowledgekid87 (talk) 01:39, 10 February 2018 (UTC)

Case-by-case is fine for specific and rare cases. The problem with railway articles is systemic. It is pervasive. There are 22,554 of them. If I nominate five of them, the railroad cabal will jump on this girl like a scrum. Rhadow (talk) 02:07, 10 February 2018 (UTC)

Would you mind linking an example railway article? SportingFlyer (talk) 02:11, 10 February 2018 (UTC)

Akechi Station (Ena), Akechi Station (Kani), Aki-Imuro Station, Aki-Nakano Station, and Akiaga Station are all examples of unreferenced railway articles. Ainoki Station is in the list of 22,554. The others aren't. Rhadow (talk) 12:06, 10 February 2018 (UTC)

First, thanks for the links - second, it appears the proper procedure with those articles would be to add references, not to delete them because they don't have references. SportingFlyer (talk) 19:17, 10 February 2018 (UTC)

By contrast, SportingFlyer, it's easy to look on a JR schedule, add the article, then challenge others to find a reference when the article is PRODded. It is up to the creating editor to back the article up with references. Try PRODding any one of those. Likely it will be reverted. If you take it to AfD, you will be attacked for an insufficient BEFORE, then magically, a printed book in Japanese will appear in the references (the same book as for a neighboring station). It's not my desire to delete good work willy-nilly, but to see that rail fans and airline fans -- and school fans like me -- contribute well-referenced material, not just to make fun lists. Rhadow (talk) 15:15, 11 February 2018 (UTC)

From an airline perspective, I don't see adding where an airline flies to as a "fun list." An airline schedule, or a list of airline routes, is clearly uncyclopaedic: that's not what we're fighting for, though! I don't have any problem with a list of train routes, either. They don't need to be blue-linked to be notable; a list of stations could be easily referenced, and indeed Wikipedia even has train route diagram templates. SportingFlyer (talk) 21:08, 11 February 2018 (UTC)

• Strong oppose and ask for speedy close. A broad, sweeping change like this one should not be discussed without a firm case. Railway station lists are widely accepted as having encyclopedic value (which is why they are accepted at WP:FL) and have purpose beyond being mere tourist guides. The stations themselves are individually notable and discussed as a group (in almost all cases), which fufils the requirements at WP:LISTN. At the very least, these lists should be judged on a case-by-case basis, with local editors providing input (unlike some AfDs that are crafted to avoid invovelment from knowledgeable editors). SounderBruce 01:23, 10 February 2018 (UTC)

Many lists individuals airline destinations pass WP:GNG and some lists of destinations were featured lists. If WP:NOTDIR bars lists of airline destinations, surely the same applies to lists of rail stations? I think we need to update our policies to clarify such situations. BillHPike (talk, contribs) 01:36, 10 February 2018 (UTC)

Hello SounderBruce -- The case against lists ... Oh, forget the lists, let's discuss the underlying articles for train stations and airports, for which there are thousands, an enormous number of which are completely unreferenced. In the case of Japanese trolley stops, you cannot even be sure that the photos (with Japanese signs) match the English text of the article. And now we want to make lists of every route? There is a small but vocal interest group here that fights for every station article. Is it encyclopedic? I argue no. Railway articles are ten percent of the unreferenced articles in the English language Wikipedia. Are ten percent of readers looking up trolley stops? I'll bet not. This group likes the status quo; they argue for a speedy close. No speedy close. Let's have the discussion. A little light on this dark corner of Wikipedia would do some good. Rhadow (talk) 01:51, 10 February 2018 (UTC)

I think you're onto something, but I think you're going off topic: this would create policy transportation destination lists violate WP:NOTDIR. A better example than train stations would be List of NSW TrainLink train routes. — Preceding unsigned comment added by SportingFlyer (talk • contribs)

Thank you for linking that, I would say that yes that article is comparable to the lists of airline destinations. - Knowledgekid87 (talk) 02:27, 10 February 2018 (UTC)

Even with a little work, almost every little train station can have a decent article. Either you create separate articles for each station, or you have a horrendously long article for each line that includes this information for each stop's surroundings, history, construction details, layout, public art, and nearby developments. For example, Tukwila International Boulevard station is little more than two platforms on stilts above a parking lot, and yet it easily met FA guidelines. The status quo was worked out long ago by discussions similar to this (which is why editors are sick and tired of this), and it's generally agreed that the current notability guidelines are sufficient for an encyclopedia that will never run out of paper. The proper forum is a non-binding discussion at the WikiProjects involved, or at deletion discussions for individual stations that are nominated. Not as something as broad and without depth as this. SounderBruce 02:57, 10 February 2018 (UTC)

This discussion should be specifically about lists of destinations, not about train stations. I believe the "lists of railway stations" is a mistake. SportingFlyer (talk) 03:34, 10 February 2018 (UTC)

I'm sure most of the members of WP:WikiProject Airlines would prefer to retain the list of airline destinations, but, as noted at the AfD, “cross project consensus on policy has more validity then that from a group of editors enthusiastic about a subject” and it is irrelevant that the lists “pass the GNG and are effectively useful”. We should either accept the same logic for other modes of transportation and update WP:NOTDIR, or overturn the previous consensus. BillHPike (talk, contribs) [[07:21, 10 February 2018 (UTC)

• Oppose.I want to keep this information. This is a badly needed discussion and has a large impact. First, there's a discussion going on regarding the lists of destinations on airport pages and how they should be presented. Second, there's a deletion discussion for lists of airline destinations. The policy at the last Village Pump discussion was limited to airline destination lists but if applied to other topics would have a large impact: as an example, those lists seem almost exactly similar to this article section: https://en.wikipedia.org/wiki/Great_Western_Railway_(train_operating_company)#Routes.

• There have been several past deletion requests for airline destinations and they have survived every time.
• First, railway stations and airports are similar as they are places. I think there's a lot of train stations which aren't notable, but they do exist in real life. For airports and railway stations alike, I believe where these places connect is worth including in list form, and is not directory information.
• Train routes/destinations and airplane destinations also similar as they are not places. Train routes typically are fixed in place due to the nature of railways. Airline routes can change at any time, and I think many editors are having problems with this fact. However, airline destinations - which is what we have lists of - change rarely, and when they do, you almost always get verifiable third-party articles talking about added/dropped routes. Furthermore, we have lists of airline destinations for failed airlines, which will never need to be updated. We haven't had a problem maintaining this information for over a decade, and it's important in being able to show the geographic scope of an airline through time, arguably better than a narrative format. Furthermore, since where an airline flies is an important part of the airline, reducing these lists to a narrative format will cause problems: what constitutes a notable route worth mentioning?
• I'd also like to see which other articles have been deleted for violating WP:NOTDIR. I view a directory as something which involves people: where they live, their phone number, their office number. These clearly don't. SportingFlyer (talk) 02:02, 10 February 2018 (UTC)

• Comment: on an anecdotal level I remember an attempt about 10 years ago to delete a list of mediaeval monasteries based on WP:NOTDIR - like everything else on Wikipedia it's been misused by people pursuing their own agendas. Eustachiusz (talk) 14:40, 11 February 2018 (UTC)

• Comment I find pretty unfair to have this discussion and, simultaneously, the one at DRV.--Jetstreamer ^Talk 02:12, 10 February 2018 (UTC)

• I don't: I think the fact we need better policy shows the DRV needs to be overturned, at least for the time being. SportingFlyer (talk) 02:21, 10 February 2018 (UTC)

• And someone realised we need a better policy after a DRV (the fourth instance of the discussion of articles including airlines destinations) was started? Even though we are in opposite sides of the AfD and the DRV discussion, I'm with Knowledgekid87 in this one.--Jetstreamer ^Talk 12:47, 10 February 2018 (UTC)

• Well, destination lists keep getting AfD'd repeatedly, and they ultimately always get kept (it looks like this time as well). I hoped this discussion would help minimise the risk of another scrum in the future, but it's not really helping anything at the moment and should probably be closed. SportingFlyer (talk) 08:26, 11 February 2018 (UTC)

• Oppose. First of all, this is the wrong venue to ask for deletion of these articles. If what you are asking for is a clarification of NOTDIR (so a change to WP:NOT), you should also post a notification at WT:NOT, the appropriate policy talk page. I find it difficult to understand why you single out transport-related lists. List of programs broadcast by Cartoon Network and List of Nestlé brands seem to be equally worthy of discussion. As to airline destination lists: like airline fleets, their destinations are an integral part of who they are, and both fleets and destinations receive frequent coverage in reliable sources. For other transportation, the List of London Underground stations is an important part of who they are. Some people have argued that we should just point to the transportation providers as sources for the information. That is fine for a travel guide (but Wikipedia is not one), but unacceptable for an encyclopaedia: we can (and should) give critical commentary and historical context for the list items. General-purpose encyclopaedias bound by paper-based restrictions may not have such lists, but detailed information can be found in specialised encyclopaedias, for example this one. Wikipedia is both a general and a collection of specialised encyclopaedias, and all of these lists are perfectly on topic. —Kusma (t·c) 08:05, 10 February 2018 (UTC)
• Comment Some have argued for a speedy close of this RFC. However, Fish and karate and Spartaz, both respected administrators, have closed discussion by stating that WP:NOTDIR meant Wikipedia should not have these articles. Beeblebrox (talk · contribs) also deleted over 400 lists of airline destinations, stating that there was a community policy decision with a clear consensus and that if any other admins undid his deletions, they would wind up at ANI (see diff). It is clear that a significant minority of our community view these changes to WP:NOTDIR as simply codifying a status quo consensus, so our community should have a full discussion on this matter. BillHPike (talk, contribs) 11:48, 10 February 2018 (UTC)
  • This discussion should then include the entire population of lists in Wikipedia, as WP:NOTDIR should apply to all of them. You and me know the result of that discussion well in advance.--Jetstreamer ^Talk 12:55, 10 February 2018 (UTC)
    • Describing Fish & karate as a "respected administrator" is stretching things somewhat—"legacy admin who has been inactive since 2008 and logs in once or twice a year to avoid losing the tools automatically" would be nearer the mark. What you fail to mention is that, while Beeblebrox did indeed threaten that anyone who challenged his unilateral supervote would wind up at ANI, it was, challenged, did wind up at ANI, and the consensus was overwhelming that his deletion was inappropriate. ‑ Iridescent 15:22, 10 February 2018 (UTC)
• Comment -- I have concentrated previously on rail stations. I used the category of unreferenced rail articles as my guide. The counterargument is the category is out of date. As I demonstrated earlier, while the category is out of date, it is also incomplete. The alternative now is to approach individual articles on a case-by-case basis, which will be a tremendous waste of time. It can be done.

As to lists of airline destinations, the problem is best discussed in terms of database architecture. When two tables purport to have the same information, one of them will always be wrong. Take JetBlue destinations for example. It has more than one hundred entries. There are only twenty-three references. The same information is duplicated at John_F._Kennedy_International_Airport#Passenger where only two destinations have citations. A portion of the destination list is found at JetBlue#Mint. Databases are now constructed in third normal form, so that an entry needs to exist only once. A correction made once fixes once every place the entry appears. Perhaps someone is looking after JetBlue. I doubt the same care is being taken with Emirates.

In all of these cases, the bar to entry is low and the cost to correct or delete is high. The transportation fans have staked out their ground, often ten years ago, when article standards were lower. Now they ask for case-by-case review. At AfD, the defense is fierce. Only if we have a reasonable policy can this turned around. Else we are looking at another decade of original research articles plugging up the unreferenced backlog. Rhadow (talk) 13:05, 10 February 2018 (UTC)

I'm in favour of keeping the articles, and I'm perfectly aware of the current article standards, as I've taken (with or without help) several articles to GA status.--Jetstreamer ^Talk 13:27, 10 February 2018 (UTC)

• Oppose per Iridescent. I would also note that the language is far too sweeping and would be more likely to cause confusion and problems than solve them. Dennis Brown - 2¢ 14:10, 10 February 2018 (UTC)
• Summary of opposition arguments thus far

• RFC not specific enough ("too sweeping")
• Deal with unreferenced articles on a case by case basis
• Category:Unreferenced rail transport articles is obviously inaccurate.
• The issue is not tranportation-related, but a general discussion of WP:NOTDIR
• WP is not printed, therefore no limitation is required
• Wait till the Adria Airways DRV is completed

All of these objections are deflective; none addresses the matter of the airline destination lists themselves. Only one objection addresses the matter directly. Airline destinations are a crucial description of the purpose of an airline. Is it international or domestic? What freedoms of the air does it exercise? How do these routes demonstrate economic and social ties?

The policies surrounding lists are stretched when these lists are unreferenced. In the area of schools, to include an alumnus, the list member must be notable (blue-linked) AND have a citation demonstrating that the member is an alum. The same can apply to transport lists. Airports are notable. To get on a destination list, there should be a reference. Rhadow (talk) 15:52, 10 February 2018 (UTC)

• • That is silly. Claiming the RFC is too broad and sweeping is as valid a reason as any. If someone wanted to change policy to "all bad edits should be reverted", I would say the same thing: it is too broad and sweeping. An RFC to change policy has to state the problem, explain why it is a problem, provide the solution and offer a degree of protection from collateral damage. Since this doesn't do that, it is comical that you think opposition should be dismissed out of hand. Your "conclusion" shows why you shouldn't be closing discussions. Dennis Brown - 2¢ 17:24, 10 February 2018 (UTC)
    • Not to mention that this discussion not coming to and end is somewhat disrupting Wikipedia. As many others, I am a contributor to airline destinations articles, for which all my contributions are impeccably sourced, but I'm not making any edits to them in view of the possibility (rapidly vanishing, though) that these articles will be deleted. I don't want to waste my time in such situation.--Jetstreamer ^Talk 17:41, 10 February 2018 (UTC)

• Hello Dennis Brown, Jetstreamer -- This discussion is not twenty-four hours old and you claim that by its protracted nature, it is disrupting Wikipedia. You like the status quo. I get that. Calling my thinking comical is not contributing to that discussion. I looked at El Al destinations. It's great. It's not like JetBlue destinations, John_F._Kennedy_International_Airport#Passenger, or United_Airlines_destinations. Here is a simple solution: agree that a destination must be notable (easy) and that any edit needs a reference. In the airline realm, I don't think that's too much to ask. No one is likely to touch Pan Am destinations. When a destination list includes an unreferenced trolley stop or bus shelter, that's when we say no. But if we agree, then the no must be firm and not subject to special pleadings. Otherwise, someone will add the Moon to the Pan Am article ... and come up with a dodgy reference. We've gone through the same thing with the cricket fans who insisted on retaining articles about players who played in one game, for whom no one knew their first name, and for whom there was no press coverage. Those articles are going. The bad lists of destinations need to be improved or go. That's my two cents. Rhadow (talk) 18:41, 10 February 2018 (UTC)

I said no such thing. Please retract or strike my name as your statement about my "claim" is pure fiction. Dennis Brown - 2¢ 11:09, 11 February 2018 (UTC)

• This type of discussion has stretched on for weeks now in RfCs, AfDs, and deletion reviews. SportingFlyer (talk) 19:10, 10 February 2018 (UTC)
• Furthermore, with regards to destination lists, you shouldn't include only notable destinations: "notable" is meaningless in that case. A list should either be exhaustive or not exist. The destination itself doesn't need to be notable; we don't need to blue-link everything. SportingFlyer (talk) 19:14, 10 February 2018 (UTC)

• As to trains, I've seen articles for some Indian routes that even included schedules, which is something I definitely oppose. As one of the strongest enforcers of WP:VERIFY (at least in the airline-related field) I totally agree with the inclusion of reliable references. As many more, I'm not a fan but an editor, and have plenty knowledge of the content policies. We have, on the other side, occasional contributors that think this is a fansite and make all kind of changes in line with anything but an encyclopedia, likely because they are not familiar wih our policies but pretty familiar with the fact that anyone can contribute; the solution relies on reverting, protecting, or discussing the matter at the corresponding talk page, but not on extraneous interpretations of the policies. One thing is for sure: proposing the deletion of these pages will not solve the problem, as it won't at many, many other topics. The discussion regarding airlines destinations should stop at some point, here or elsewhere.--Jetstreamer ^Talk 20:42, 10 February 2018 (UTC)

@Dennis Brown: An RFC to change policy has to...

• state the problem, ... Many respected users, including several admins, interpret WP:NOTDIR as mandating the deletion of lists of transporation service destinations, notwithstanding WP:GNG
• explain why it is a problem, ... A significant number of users feels that the above users are misinterpreting policy.
• provide the solution ... I’ve proposed two solutions: The first solution is to update WP:NOTDIR to explicitly state, that for lists of transportation service destinations, NOTDIR both disallows these lists and supersedes GNG. The second solution is for our community to come to a consensus that some users are incorrectly interpreting NOTDIR to delete articles they don’t like.
• and offer a degree of protection from collateral damage Each of the two solutions offer the same protection from collateral damage that each of the existing interpretations NOTDIR already provide. BillHPike (talk, contribs) 22:21, 10 February 2018 (UTC)

I could pick it apart, but suffice it to say that there is a lot of conjecture here (admin's opinions don't carry any extra weight on interpretation, btw). It isn't that I'm in love with these lists, but I'm less in love with your solution. Dennis Brown - 2¢ 11:20, 11 February 2018 (UTC)

Jetstreamer is worried about the notability of airports listed in airline destination lists. I venture to guess that all international airports have blue-links. Where train stations are concerned, the path is tortuous. I nominated Akita-Shirakami Station for deletion. It had been unreferenced since 2006. Under my proposal, had it been deleted, it would have been ineligible for a destination list. Two references in Japanese were promptly provided with the argument that the subject had the "same notability as all the other stations on this line." Same is not necessarily sufficient or significant coverage. I cannot be sure that the two books provided include sufficient or significant coverage. The other article includes a mention of the station, not a discussion of it. Certainly it exists. I doubt whether the station is noteworthy in a general Wikipedia sense. I am quite sure, however, that no one party to this discussion wants to go through an AfD for 22,558 articles (or however many there truly are). And I was right, editors did pile on the AfD like a scrum. Rhadow (talk) 12:06, 11 February 2018 (UTC)

• Oppose this proposal seems overly broad. I think it would mandate that we would have to delete, say, List of London railway stations. This is a natural grouping of notable topics, it has obvious navigational value, and I don't see how it's in any way unencyclopedic. I'm sure there are cases where lists of transportation destinations fall foul of WP:NOT, but introducing a sweeping rule like this is not the way to deal with them. And I agree this is the wrong venue, the right place to suggest policy changes is the talk page of the policy. Hut 8.5 18:35, 11 February 2018 (UTC)
• Oppose far too sweeping a proposal that would remove many good articles, each article has its own merits or demerits and need to be judged on a case by case basis Atlantic306 (talk) 19:47, 11 February 2018 (UTC)
• Oppose. First, I don't think the RFC question is too broad or sweeping. I can perfectly well answer. No, WP:NOTDIR should certainly not state that lists of transportation service destinations are outside the scope of Wikipedia. Thincat (talk) 20:04, 11 February 2018 (UTC)
• Oppose WP:NOT has become a means of giving teeth to WP:IDONTLIKEIT. Would prefer to see WP:NOT curtailed, not extended. Hawkeye7 (discuss) 21:14, 11 February 2018 (UTC)
• Oppose. I really don't understand the opposition to lists that neatly summarizes information that lends itself to this kind of presentation. Removing these lists makes information much harder to find for a regular reader, and leads to a messier encyclopedia. Featured lists such as List of London Underground stations are not directories, and it requires a ludicrously pedantic reading of the NOTDIR policy to interpret it as such. Sjakkalle (Check!) 21:18, 11 February 2018 (UTC)

Meh... removing the lists may make it harder to find the information ON WIKIPEDIA... but the information is relatively easy to find elsewhere. That’s why the issue centers on WP:NOT. We don’t just present information for the sake of presenting it (because we can)... There are some kinds of information that Wikipedia leaves for OTHER websites. The question is: is this the kind of information we want Wikipedia to present (or not)? My reading of NOTDIR makes me lean towards saying “not”. Blueboar (talk) 23:05, 11 February 2018 (UTC)

Following your reasoning we may proceed with the removal of the entire project as the content of all Wikipedia articles can be found elsewhere, this encyclopedia is built by using external sources.--Jetstreamer ^Talk 00:00, 12 February 2018 (UTC)

• Oppose - I changed my vote to oppose as this is way too broad of a proposal, as I said above I also believe that the DRV should close first. - Knowledgekid87 (talk) 00:48, 12 February 2018 (UTC)
• Proposed wording A pharasing that would reflect how the previous dicussions have been interpreted would be to add the following to WP:NOTDIR

8. Lists of transportation service destinations. Wikipedia is not a collection of lists of transportation service destinations, such as lists rail stops, airline destinations, or bus services. Such articles should be deleted even if service to the destination passes other inclusion criteria such as WP:GNG.

See previous VP RFC close and AfD Close. I would personally be opposed to this change, but since several admins have indicated that they feel this wording represents the status quo, it is worth having a full discussion on clarifying the meaning of WP:NOTDIR. BillHPike (talk, contribs) 00:57, 12 February 2018 (UTC)

• We are not discussing WP:NOTDIR's bullet number 8 because it does not exist at all. Presenting it this way is at least confusing and I strongly suggest to strike this text out.--Jetstreamer ^Talk 02:21, 12 February 2018 (UTC)

• The proposed text would be inserted after WP:NOTDIR#simplelists and become bullet point number 8. BillHPike (talk, contribs) 02:29, 12 February 2018 (UTC)

• How are these being claimed to meet the GNG? Or more specifically, while there are definitely a few routes on these lists that meet the GNG, the whole of the lists do not - sourcing doesn't appear to be independent nor secondary. --Masem (t) 02:45, 12 February 2018 (UTC)
• Strong oppose I still have yet to see a compelling reason to remove these valuable, sourced, accurate, and informative pages from WP. We should be focused on building the project, not taking it down, no? Some of these are featured lists--and editors have spend a long time ensuring they are a valuable addition to the project. Tofutwitch11 ^(TALK) 02:50, 12 February 2018 (UTC)
• Oppose per WP:CREEP. We don't need special rules to outlaw topics we don't like. Their notability should stand or fall like that of other lists. —David Eppstein (talk) 03:24, 12 February 2018 (UTC)
• Oppose. I tend to think that many of the lists are notable, and in general that there are no issues with the usual AfD process for these lists if there are some that need to be deleted. Policy should not be this granular; issues like this should be interpreted at AfD. CapitalSasha ~ talk 04:14, 12 February 2018 (UTC)
• Oppose many lists mentioned under this policy are lists of notable entries and actually help organise Wikipedia and make it easier to navigate. --Donald Trung (Talk) (Articles) 09:22, 12 February 2018 (UTC)
• Oppose we have WP:NOTDIR...aaaand this isn't in it. We have WP:GNG. The proposal seems to be wanting to delete material which would otherwsie fulfil notability criteria. Which I don't agree with. Cas Liber (talk · contribs) 11:58, 12 February 2018 (UTC)

• Comment Reading some of the discussion, I think we need to reapproach this. We can't group airline, train, and bus equivalently here. I do think that there is appropriateness of airports, train stations, and main bus terminal articles (these are fixed structures, typically built by tax money, so there's going to be attention given to them. Bus stops by themselves do not have the same aspect here.) The schedules however are much more transient which is the issue from the prior airline destination discussion - but this is more true for airlines and buses - trains you really can't change all that much, and hence why I'd not be surprised at volumes of books I could read on the London Underground or any major city's subway lines. I would say that - barring true GNG notability for an airline/bus route - where there is nothing that forces them to follow the same path - that their transient nature makes them inappropriate. --Masem (t) 14:33, 12 February 2018 (UTC)

I had argued for a speedy close earlier but now it seems like a lost cause. I fully agree that this discussion is too broad which should be the central flaw here. - Knowledgekid87 (talk) 15:08, 12 February 2018 (UTC)

• Please consider List of MBTA crosstown bus routes -- which relies on a single source and whose content has not been updated since 2012. Better yet is the sprawl of New Jersey bus-route writing, which has required the creation of an article Lists of New Jersey Transit bus routes, which is a list of lists. Another egregious example is List of bus routes in Hong Kong, a 120,000 character article with one (1) reference. This is the future of a Wikipedia without a sensible standard for transportation-related lists. Rhadow (talk) 14:42, 12 February 2018 (UTC)

You really should read WP:PROBLEM. - Knowledgekid87 (talk) 15:20, 12 February 2018 (UTC)

• Hello Knowledgekid87 -- Thank you for the reading I summarize as, "No article is beyond redemption." I interpret it as an excuse for "one bad apple." My point is that the family of articles List of bus routes in ... is a systemic problem, not just a couple of bad examples. List of bus routes in Lahore includes every route and every stop. It has two references. The rest is original research. List of Chennai Metropolitan Bus Routes has one reference, but every stop on every route. Some lists are very specific, an example is List of night buses in London, which includes stops as well as routes, and is a fork of List of bus routes in London. Sure, Knowledgekid87, none of these articles has an insurmountable editing problem. As a group, however, there is a big problem that allows low-quality articles like these. Rhadow (talk) 16:22, 12 February 2018 (UTC)

Hello Masem -- Perhaps the proposal should have been that all transportation lists are notable. Then the chorus would disagree. Here are a few examples that have been discussed in both academic works and in the popular media: Rhadow (talk) 16:59, 12 February 2018 (UTC)

• List of public transport routes numbered 1
• List of public transport routes numbered 2
• List of public transport routes numbered 3
• List of public transport routes numbered 4
• List of public transport routes numbered 5
• List of public transport routes numbered 6
• List of public transport routes numbered 7
• List of public transport routes numbered 8
• List of public transport routes numbered 9
• List of public transport routes numbered 10
• List of public transport routes numbered 11
• List of public transport routes numbered 12
• List of public transport routes numbered 13
• List of public transport routes numbered 14
• List of public transport routes numbered 15
• List of public transport routes numbered 16
• List of public transport routes numbered 17
• List of public transport routes numbered 18
• List of public transport routes numbered 19
• List of public transport routes numbered 20

• Strong oppose Where a transportation company serves is relevant, and notable. It provides important context that is needed to understand the subject, not to mention it receives significant coverage in reliable sources. Arguments against basically boil down to WP:IDONTLIKEIT as people throw out irrelevant policies. Smartyllama (talk) 18:10, 12 February 2018 (UTC)
• Oppose - Not only is the proposal overly broad, NOTDIR doesn't apply as these lists are very discriminate and very specific, not at all indiscriminate which is what NOTDIR applies to. There has been zero lessoning to encyclopedic value of WP as a whole since these have existed, which is basically as long as WP existed. These have only been complemental enhancements of this project. --Oakshade (talk) 03:55, 13 February 2018 (UTC)

A different direction

Considering that the RFC above perhaps a bit too diffuse, I would like to propose (for discussion, no formal proposal) considering "permanence" when talking about transportation lists. In this frame, the following would very much likely be notable due to the fact that they typically are permanent structures and will have good documenting in local newssources about their cost of construction, changes over the years, etc.:

• Roads (highways/interstates)
• Train/subway stations
• Train/subway lines (lists of stations a line serves, but not its schedule)
• Bus terminals
• Port/Ferry terminals
• Airports, including hub airports for air carriers

While the following have too much temporal variation (they are not forced to travel a fixed route) and should not be considered appropriate for WP, unless one can show it meets the GNG. These are primarily only going to be sourcable to the agency running the service, and since they can be changed on a whim, difficult to document.

• Bus route/schedules and intermediate bus stops, and lists thereof
• Air route/schedules and destination cities, and lists thereof
• Ship/ferry route/schedules and lists thereof.

How to put that into any type of policy or not, I don't know, but I'd like to open that up for discussion. --Masem (t) 16:32, 12 February 2018 (UTC)

• Support - Any discussion that leads to a proposal to establish a line when it comes to "permanence" in transportation lists. Railroad stations aren't going anywhere anytime soon, but for airline destinations those are advertised and fall under schedules. - Knowledgekid87 (talk) 16:45, 12 February 2018 (UTC)

Would you support the removal of information about which trains services stops at specific stations? For example, service to Tacoma station is clearly ephemeral. BillHPike (talk, contribs) 16:50, 12 February 2018 (UTC)

Many specific flight numbers have served the same origin / destination pair for over 50 years and pass WP:GNG. It would be silly to carve out an exception to GNG to bar any reference to these flights, but keep entries on trivial rail stations. BillHPike (talk, contribs) 16:53, 12 February 2018 (UTC)

Lets get the lists sorted out before talking about article issues. Any proposal given should talk about what transportation lists are right/not right for Wikipedia to maintain. - Knowledgekid87 (talk) 16:55, 12 February 2018 (UTC)

• Comment Airlines typically have more staff and more permanent assets at minor outstations compared to what railroad maintain at minor stops. Many rail stations are unstaffed and the permanent facilities are little more than a few signs and and maybe an awning. Furthermore, what about ferry services operated by railroads, like the Gravesend–Tilbury Ferry, which has operated for over 150 years? We need to have a consistent policy that doesn't carve out exemptions because certain editors like trains and dislike airplanes. BillHPike (talk, contribs) 17:17, 12 February 2018 (UTC)
  • If we have a better measure of permanence for not-quite-hub airports, that would be great. For example, I know there's coverage of Delta establishing a major route through Seattle lately, though I dare not say Seattle is a Delta hub, but it's more than an outlier. What we don't want is the list of all destination cities an airline services. Maybe it's based on airport size or capacity? I don't know, but I feel there's something we can determine as a clear line to avoid indiscriminate while still reflecting the importance of these routes. --Masem (t) 17:29, 12 February 2018 (UTC)
    • Could the info just be placed within the main article or a split-off that focuses on the airline's history? - Knowledgekid87 (talk) 17:31, 12 February 2018 (UTC)
      • Oh, easily. You probably don't need a separate list per-carrier for this. I would figure for the largest airlines, this is probably somewhere between 6 to 12 cities long if you narrow it down to hubs and not-quite-hubs, so that fits easily in the airline's article, and can be mentioned on the airport's page. But this still gets back to the idea of permanance, does this make sense here? Somethings, airlines cannot change on a whim. --Masem (t) 17:45, 12 February 2018 (UTC)
        • I disagree. There's nothing wrong with the destination lists as they exist right now. They are binary: has this airline ever served this airport? Do they currently serve this airport? They aren't lists of routes, nor are they schedules, and while the "do they currently serve this airport" isn't permanent, the fact they have served the airport is permanent. It's also easily verified and doesn't change all that much. Furthermore, including all destinations both helps demonstrate an airline's reach (including historical reach) better than limiting which destinations are mentioned, plus then you get into a slippery slope argument of when should a specific destination be mentioned. SportingFlyer (talk) 23:07, 12 February 2018 (UTC)
  • Further point: It would be absurd for Wikipedia to have articles dedicated to the Heathrow Express service to LHR or the Narita Express service to NRT, but bar any mention of the fact that Japan Airlines has operated a direct flight between those airports for longer then either rail service has existed. (Reference: Fairhall, David (May 16, 1968). "Flight Plans that's stuck in the crowd". The Guardian. p. 20 – via Newspapers.com.) BillHPike (talk, contribs) 17:56, 12 February 2018 (UTC)
• Oppose. The guiding principle should be what we can write fully verifiable articles about. I don't see why "permanence" should have a huge influence. Many lists are not permanent at all (List of current heads of state and government etc.). Why make a special case for "non-permanent transportation-related lists"? Non-permanent sports or television-related lists (List of current NBA team rosters, List of programs broadcast by American Broadcasting Company) do not seem to be inherently better or worse than transportation-related ones. By all means delete or merge unreferenced and unmaintained lists to a suitable parent, but do not outlaw a random class of articles based on random criteria. —Kusma (t·c) 17:46, 12 February 2018 (UTC)
  • For all those cases (current government, current team lineups, current TV schedules), those all then filter to per-year or per-term articles that have historic significance. For example, it is not that we have the current lineup for a given team, but that we end up writing the article about the team's season, which stays historical from then on; we keep broad-stroke TV schedules because there is interest in historical competition between networks, and so forth.

Transportation routes on the other hand do not get that type of historic treatment. I'm sure that there are "trainspotters" here that have keen interest in what the London bus routes were in 1998, for example, but this doesn't get - from what I've seen - the same type of secondary coverage we'd see from the other venues. There certainly can be historically significant routes and those should be documented if they meet the GNG, but not ones that can only be listed from official timetables or databases.

Permanance is not a random criteria here: to have any of the "permanent" items I gave above requires millions of investment often using local taxes, so it's going to be reported on. Schedule changes are not. --Masem (t) 17:56, 12 February 2018 (UTC)

Would you favor deleting the articles in Category:Former Amtrak routes since they are obviously not permanent sevices? For rail services, the capital investment for a new service over existing rail infrastructure is far less than the capital investment associated with a new route served by widebody airliners. Furthermore, many airlines are state owned, so providing air service also requires a significant investment of tax dollars. BillHPike (talk, contribs) 18:06, 12 February 2018 (UTC)

"Transportation routes on the other hand do not get that type of historic treatment". Well, that is just wrong, they do. I used to care about trams when I was a kid, and had a book about Trams in Mainz that included a complete history of line changes (not just for trams, but also trolleybuses and the replacement by bus lines) and of the rolling stock used. You will find books about the transportation history of any major European city in any good local library. —Kusma (t·c) 20:49, 12 February 2018 (UTC)

As long as you can show GNG notability, then you're fine; I would not be surprised to find such books exist for the world's oldest public transit systems (which will start with Europe). However, I doubt every major city will have a similar level of detail for their transit.

But this case brings up the key point here: We're looking at parts of transportation that have been recognized as historically significant in their field. Selected air routes that haven't changed for 50 years will likely have that, but the current full list of routes today from an air carrier is not. The point of starting with permenance, with GNG as a backup if needed, is that permanent routes or structures will have the type of documentation one expects these to have, not any random schedule or flexible route. --Masem (t) 20:58, 12 February 2018 (UTC)

As I noted above, these aren't lists of routes: they're lists of destinations, both current and historic. SportingFlyer (talk) 23:08, 12 February 2018 (UTC)

Given the hub-and-spoke approach used by most carriers, while it is true that we're not listing out all routes with a list of destinations, it's pretty dang close to one. But as I mentioned above, if we limited those lists to larger airports as to where an airline having a presence is a significant undertaking, that might be something better. For example, I'd fully approve that the list of hubs (past and present) in Delta Airlines is appropriately encyclopedic and significant. --Masem (t) 23:14, 12 February 2018 (UTC)

The fact Delta flies to, say, Huntsville, Alabama is appropriately encyclopedic and significant for both the scope of where Delta flies and to understand the level of connectivity of the Huntsville Airport, connectivity being important for transportation-related articles. An article with a list showing Delta flies from Atlanta to Huntsville would not be encyclopedic, or an article on the Delta to Huntsville route would not be encyclopedic. Also, "significant undertaking" would be really hard to define. SportingFlyer (talk) 01:35, 13 February 2018 (UTC)

• Oppose Permanence is irrelevant to notability, and airlines rarely change destinations randomly on a whim unless there's some intervening factor (natural disaster, war, etc.), which is rare. Usually there's some advance notice and clear announcements. Smartyllama (talk) 18:14, 12 February 2018 (UTC)

I thinks its worth emphasizing that while airlines frequently update flight times and tweak schedules, it is less common for airlines to add or remove all service to a destination. BillHPike (talk, contribs) 18:25, 12 February 2018 (UTC)

• Here is what administrator Necrothesp says, "We generally regard all railway stations as notable. I'm not sure if she is speaking for Wikipedia editors in general, or for administrators. In either case, I see now how foolish I was to point out that that this railway station failed the WP:N standard. The law, apparently, is irrelevant when the judge has already made up her mind. Rhadow (talk) 19:02, 12 February 2018 (UTC)

• Per WP:NTS, Services with likely notability include... train stations. (Note that NTS was withdrawn as policy in 2009). BillHPike (talk, contribs) 21:57, 12 February 2018 (UTC)
• I am a he, not a she, if you'd bothered to look. I have never known a railway station deleted at AfD (and many have been nominated for deletion over the years). That is consensus and consensus is how we determine notability on Wikipedia. No idea why you mention I'm an admin. It's utterly irrelevant. -- Necrothesp (talk) 10:42, 13 February 2018 (UTC)

• Oppose. Agreed with Smartyllama. Permanence is not required for notability. Sjakkalle (Check!) 21:08, 12 February 2018 (UTC)
• Oppose Too broad. Air route schedules (airlines/destinations) are fairly consistent, and notable. The lists on the other hand are an entirely different argument. Bus and train schedules less consistent, though, and perhaps this would work for them. Tofutwitch11 ^(TALK) 21:55, 12 February 2018 (UTC)
  • I want to stress that permanence here is not meant to be the sole deciding factor, only that we can see the defining line between what we agree is acceptable and what is seen as problematic is when the element lacks the permanence expected. A transient element like an air travel route can still be notable on its own. What is not appropriate based on the previous discussion is a listing of all those routes just because one can, unless you can show that the whole of that schedule is of note. --Masem (t) 22:01, 12 February 2018 (UTC)

• I tried to start with what I thought were the least defensible lists of this nature, but there is a whole world of these destination and route list articles. Why? To me it makes no sense. Literally nobody is using these to plan anything, and even if they were, Wikipedia is explicitly not a travel guide. This type of content is just information as opposed to actual knowledge.

That being said I find it extremely unlikely that this RFC will or could succeeed in arriving at a decision not to host any of this. Beeblebrox (talk) 22:02, 12 February 2018 (UTC)

If nobody is using these to plan anything , then surely WP:NOTTRAVEL does not apply? Perhaps the contributors to these pages wanted Wikipedia coverage of airlines to be as comprehensive as specialised print encyclopedias (Example: 1942-, Endres, Günter G., (2002). Major airlines of the world (2nd ed ed.). Shrewsbury, England: Airlife. ISBN 1840373407. OCLC 51781211. {{cite book}}: |edition= has extra text (help); |last= has numeric name (help)CS1 maint: extra punctuation (link) CS1 maint: multiple names: authors list (link) BillHPike (talk, contribs) 22:41, 12 February 2018 (UTC)

A good list of airline destinations provides knowledge about the airline's current route network, the airline's route network over time and how the airline developed historically in the same way as the development of a fixed transport network such as a tram, though. It has nothing to do with being a travel guide. Not all lists are "good" yet, true, but that doesn't mean they should be deleted. SportingFlyer (talk) 23:23, 12 February 2018 (UTC)

And let me add that the concept of knowledge is totally subjective.--Jetstreamer ^Talk 23:57, 12 February 2018 (UTC)

• Comment (I'm willing to plainly ″oppose″, but I want to hear what other editors have to say). Per proposer, transportation infrastructure seems to be notable enough for stand-alone articles. I therefore don't fully understand what the proposal is, as nobody should add information without a reliable source. It seems to be a rewording of WP:VERIFY, a very basic policy. And this discussion started because of the mass deletion of airline destinations: why is this topic not explicitly mentioned?--Jetstreamer ^Talk 22:50, 12 February 2018 (UTC)
• Oppose. I don't actually mind the proposal that much - I think adding weight to permanence would be helpful for determining whether a transportation article has notability or violates WP:NOTTRAVEL. I've found a couple bus route articles like Stagecoach Gold bus route S5 which although sourced I would consider proposing for deletion under WP:N and WP:NOTTRAVEL, however something like London Buses route 1 has survived two AfDs (they were both bulk deletes of all routes, and one was withdrawn) and has some history. However using it as the main criteria doesn't seem like it works, plus then you get into an argument about whether a list of airline destinations are routes or not. SportingFlyer (talk) 23:40, 12 February 2018 (UTC)
• Comment. Yes, most of the first section should be considered notable as individual items (although the proposal actually appears to be about lists). We have generally consistently found all of them to be notable at AfD over many years, so there is clear consensus for this. The only exceptions are bus terminals, where we have generally found only the most significant to be notable, and ports, which haven't been tested very much at AfD. But main roads, stations, rail lines and airports? Definitely. -- Necrothesp (talk) 10:55, 13 February 2018 (UTC)
• Comment -- No discussion about whether it is practical to retain all these lists. Take, for example Caribair, likely out of business since 2009. Its list of Caribair destinations still reads, "This is a list of destinations that Caribair currently serves,". It is a completely unreferenced article. It survived AfD in 2015. Rhadow (talk) 14:36, 13 February 2018 (UTC)

• In this particular case, I'd support to merge into the parent article. Meanwhile, I've tagged the article as unreferenced, that is the first step. How can anyone knows the page lacks references without proper tagging? By the way, I've jumped into Category:All articles lacking sources. Are you going to propose the deletion of all these articles just because they don't have references?--Jetstreamer ^Talk 15:47, 13 February 2018 (UTC)

• Hello Jetstreamer -- I know better than to propose it for deletion. The crowd already spoke. They like it just fine with no references. Destination lists are a protected class, just like railway stations. Here's another article I like Air Arabia destinations. An editor asserts that discontinued destinations come from the subject's commercial website. Rhadow (talk) 17:29, 13 February 2018 (UTC)

• That's patently false - there needs to be more references for these articles. The lack of references doesn't mean they can't be cleaned up, though. SportingFlyer (talk) 17:37, 13 February 2018 (UTC)

Comment - began referencing the Air Arabia article. It's very easy to do. SportingFlyer (talk) 18:23, 13 February 2018 (UTC)

Cool.--Jetstreamer ^Talk 20:47, 13 February 2018 (UTC)

Allow for emoji's in signatures

Currently some users can get permabanned for having emoji's in their signature, but some users like having emoji's because it makes their signatures more easy to recognise, the signature policy doesn't advise against emoji's but it's not uncommon for people to be requested not to use them. I would like to propose that all users can add emoji's to their signatures as they are not disruptive and are purely decorative. --Donald Trung (Talk) (Articles) 09:20, 12 February 2018 (UTC)

Emojis are allowed in signatures. What is not allowed is emojis in usernames. —Kusma (t·c) 09:43, 12 February 2018 (UTC)

Donald Trung, note that Kusma is speaking generally, and not with regards to your particular case. You are banned from using emojis (and special characters in general) in "in edit summaries or non-talk pages"—with signatures as implicit in that, since it would otherwise mean you couldn't comment on WP-space pages like this—as part of your unblock conditions. ‑ Iridescent 10:00, 12 February 2018 (UTC)

I would say that any page which is used for discussions (including this one, AN, etc.) is a talk page; any other sort of Wikipedia: namespace page should generally not be signed. עוד מישהו Od Mishehu 16:12, 12 February 2018 (UTC)

The case of a block enacted after a page protection

Hi.

So, please imagine this case: Editor A and B are in a dispute. Nobody else is in that dispute. Admin C protects the disputed page. But then, other things happen and Admin C blocks Editor A for his or her conduct in that said dispute, for a period equal to or longer than the page protection length, and revokes his talk page access. Naturally, at this stage, Editor B has no way of engaging in any sort of discussion, which was the purpose of the protection.

Now what should happen to the protection?

• Should it be left intact even though it serves no purpose?
• Should it be extended to by the period of Editor A's block plus the original protection length?
• Should it be lifted?

Of course, I am open-minded to this issue not being a wholly trinary case.

Best regards,
Codename Lisa (talk) 10:25, 14 February 2018 (UTC)

In your first option you say that, at that point, the page protection "serves no purpose". First, A was blocked for conduct, not for being wrong in the content dispute. I posit that most often B would still need a cool down period too, and that is the "purpose" of leaving the page protection for the time being. B should realise it is not about "winning" a dispute, and cooling down instead of rushing to convert the page to their preferred version is usually best. B can, if they're sure they're "right" on the content issue (when what they consider the "wrong version" got protected), request to implement the improvements they suggest via an {{editprotected}} template on the talk page, and someone uninvolved would evaluate. They can request the page protection be lifted, if it is very obvious that A had disrupted mainspace (i.e. in the article) before being blocked. Also in this case, someone else would evaluate whether the requested unprotection is justified. But generally I suppose B cooling down for the period of the initial page protection period, and making themselves useful elsewhere in the mean while, being the best option. --Francis Schonken (talk) 10:53, 14 February 2018 (UTC)

@Francis Schonken: Hi. Thanks for the reply. I am afraid I find it biased, biased and biased, as it assumes Editor B has the following attributes:

• He or she cannot edit already, because of protection
• He or she wants to edit and the current state isn't to his or her satisfaction
• He or she needs to cool down in the first place
• That cooling down is even possible when he or she has permission to edit other places (Your very strong wording draws a picture of jerk from Editor B. Such a person is already a high risk that might do other not-so-okay things elsewhere.)

Also, {{editprotected}} suggestion is not helpful: In case of a dispute a page is fully protected. Only admins can respond to edit request and they explicitly avoid responding to the edit requests from B, per their "no wheel-warring" mandate, that it is not a good idea to defeat the purpose of a protection by permitting Editor B get his or her way anyway and the controversial "wrong version" issue to which you alluded.

Best regards,
Codename Lisa (talk) 12:57, 14 February 2018 (UTC)

@Codename Lisa: what a nonsense you're writing now (very strong wording intended). I implied nor pre-supposed any of that. --Francis Schonken (talk) 13:23, 14 February 2018 (UTC)

"I implied nor pre-supposed any of that." Then, are you saying a person who can edit, doesn't want to edit, does not need to cool down, and is not struck by any measure that either eases or facilitates his or her cooling down still needs to cool down? Same question about "winning". —Codename Lisa (talk) 14:24, 14 February 2018 (UTC)

Again, what nonsense: I implied nothing of the kind. --Francis Schonken (talk) 14:40, 14 February 2018 (UTC)

Whoa! No need to bite. I didn't come here with the intention of talking nonsense. If you I feel have grossly misinterpretted your comments, then I am afraid your comments are susceptible to gross misinterpretation. But let's not escalate the discussion like what happens in content disputes. At worst, we can bow out and agree to disagree. —Best regards, Codename Lisa (talk) 18:30, 15 February 2018 (UTC)

A page protection does not mean only those previously engaged should discuss the issue. In fact, B can use the time to invite neutral editors D, E and F to give their input, hopefully reaching a consensus before the protection expires. Plus, A's block does not mean they or their sympathizers won't restart the edit-warring if protection is lifted without a consensus on how to handle to issue. Regards SoWhy 13:26, 14 February 2018 (UTC)

@SoWhy: Hi. I can clearly see there is more experience behind your answer. Here is a couple of things though:

• You argued against option 1. Still, that begs the question: do you endorse option 2 or 3?
• Is a consensus established in absence of Editor A even valid? I am just asking; this not a rhetorical question. Because there are arguments in favor and against it. One is that an in absentia consensus does not resolve the dispute, for Editor A can argue that if "I were there, I would have argued my case successfully." Furthermore, it does not improve the relation between A and B. The counter-argument is: Editor B's privilege to participate has been revoked because of his or her own failure to use it. But then again, if he or she has lost the privilege to be part of the consensus, the protection is not necessary either.

Best regards,
Codename Lisa (talk) 14:17, 14 February 2018 (UTC)

SoWhy's reply seems perfectly compatible with option 1. I don't see in what sense they "argued against option 1"? --Francis Schonken (talk) 14:25, 14 February 2018 (UTC)

(edit conflict) No, I argued for option 1: The protection (and its length) are not void just because one editor is (forcibly) absent. And consensus is not valid or invalid based on whether certain people participated or not. If A disqualified themselves from editing because of his behavior after the protection, they have no leg to stand on claiming a consensus invalid. After all, they removed themselves from the discussion by behaving like they did after protection was set. Consider this to understand my point: What if A was not blocked but chose to go offline for a few days. Should we also wait for them to return to find a consensus? And if so, why?

As for the other part, I already noted why protection should not be lifted, mainly because A's block alone neither means they won't come back (as socks) nor that others won't "fight" their battle for them. Regards SoWhy 14:26, 14 February 2018 (UTC)

I see. I also see why I thought you argued against it: When you said "they won't come back", you actually meant WP:EVADE. Alright, that's a lot clearer now. —Codename Lisa (talk) 14:30, 14 February 2018 (UTC)

Here are a couple of other things though:

• When an edit war is resolved by blocking one of the parties, no page protection is enforced out of the fear of WP:EVADE or illegitimate canvassing. Hence, your argument seems to permit a flaw.
• There is still room for option 2.
• What if these other who "fight their war for them" actually fight fair? Isn't assuming good faith a policy here? Even better, these additional editors might actual improve other areas of the article or improve the disputed area to the point that the dispute becomes moot.

Best regards,
Codename Lisa (talk) 14:38, 14 February 2018 (UTC)

Re. "Is a consensus established in absence of Editor A even valid" – taking this as an example (editor A "indeffed for undisclosed paid editing" and for "plenty of WP:NOTGETTINGIT" during page protection), any consensus "established in absence of Editor A" would be valid. So it largely depends on circumstances (in different circumstances it may be better to involve the A editor in reaching consensus). --Francis Schonken (talk) 14:40, 14 February 2018 (UTC)

Hence, my message above. —Codename Lisa (talk) 18:30, 15 February 2018 (UTC)

• @Codename Lisa: Sorry, it's clear that you have a specific case in mind. I'm afraid that speaking in the general without being able to review the specific case you are disputing is not helpful here. If you can refer us to the specific case (rather than your partial characterization of it) we can review it and speak intelligently on it. --Jayron32 04:13, 15 February 2018 (UTC)

• Hi, Jayron32.

None of us come here because one day we wake up and think "Wow! I wonder what happens if an admin did such-and-such." But I can guarantee that I am NOT here seeking appeal to another admin's decision under the facade of a general question. If you feel I have a certain case in my mind, all you have to do is to ignore that feeling and answer generally.

But then again, I can definitely say the same thing about the other participants here. Nobody took each of my three recommended couses of action to analyze its pros and cons individually and objectively. Instead:

• Francis Schonken said highly judgmental things about a totally imaginary editor, for which I had supplied no previous data whatsoever. I shudder to think what this could imply. He assumed bad faith by default, in violation of WP:AGF.
• SoWhy's reply is an example of behavior for which Wikipedia admins have gained notoriety. People outside Wikipedia often judge us and I hear their judgments without letting them know I am their target. One of the comments on admins here is that they go to a ridiculous length and breadth to avoid disagreeing with existing policies and their fellow admins, to the point that if two admins do completely opposite and comflicting things, they are ready to swear that they agree with what both did, and their actions are in no way contradictory. And they are not wrong too. SoWhy is very careful to totally discourage the idea of there being the slightest flaw in the existing policy, so much so that intially, it is not obvious whether he is against option 1 or in favor of it.

Best regards,
Codename Lisa (talk) 18:30, 15 February 2018 (UTC)

Is it canvassing to notify all participants of a previous AFD if they all !voted the same way?

Per WP:CANVASS, notifying all editors who participated in a previous AFD is generally considered allowed, especially when little time has passed since the last nomination. But what if the last AFD closed as straight keep with no delete !votes except the nominator? Then notifying all participants would mean alerting all people who argued to keep the article even though you would not exclude anyway (assuming both AFDs are started by the same person). Is it still allowed to notify those users based on CANVASS's appropriate notification rule or is it now votestacking because you can not avoid notifying people who already expressed an opinion (but who might change it given the new arguments)? Regards SoWhy 14:34, 15 February 2018 (UTC)

As long as no one is excluded, notifying all previous contributors to a discussion in a neutral manner is not canvassing. Only in death does duty end (talk) 14:42, 15 February 2018 (UTC)

I've done such notifications sometimes when people contested my deletions, and never has anyone complained about it. I am minded to agree that so as long as you aren't leaving off some users it should be proper. Jo-Jo Eumerus (talk, contributions) 15:23, 15 February 2018 (UTC)

Votestacking (trying to establish your desired result by selective notifications) is only an issue if your list of notified users is intentionally chosen by the expected result. "Everyone who participated in the most recent relevant discussion" is a truly neutral criterion, even if the discussion went in your favor. Do make sure the nominator of the original discussion is aware of the new discussion (not an issue if this same user is the nominator of the second discussion). עוד מישהו Od Mishehu 15:43, 15 February 2018 (UTC)