Wikipedia:Village pump (policy)/Archive 139

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (policy) archive  

This page contains discussions that have been archived from Village pump (policy). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX, AY, AZ, BA, BB, BC, BD, BE, BF, BG, BH, BI, BJ, BK, BL, BM, BN, BO · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197

Straw poll on the current view of WP:NOT#NEWS

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.

---

Recently I proposed a change at WT:NOT which related to WP:NOT#NEWS (Wikipedia is not a newspaper) which was taken through an RFC that closed recently here (permalink to that) It closed as no consensus, but I would recommended reading the !votes and discussion of that, as it highlights a currently growing issue on en.wiki, how are we supposed to handle current events/news.

A key factor is the current fate of Wikinews. It is, as mentioned several times in the discussion above, effectively a dead project, stuck in a catch-22 problem to get people to use it. There is clearly both editor desire and readership interest to see current news provided in a wiki-style, and en.wiki has generally done well before in covering current events. But events over the last few years (particularly over the last 2 years) have created a lot of editor tension and behavioral problems related to current event coverage (given what passes by AN/ANI/ARBCOM and various policy noticeboards), and highlights the differences between what an encyclopedia is and what a newspaper is. Their goals aren't fully mutually exclusive but there are several conflicting goals. WP:RECENTISM highlights many of these issues.

So I figure that to try to resolve this is to at least start with a straw poll, not designed to establish any immediate change in policy or guideline, but only to see where the current perception is of how en.wiki should be handling NOT#NEWS. Testing the wind, to speak. To that, there's principle three options to consider to get an idea where an editor/reader's interest in this may be as to determine the preferred method to go forward, if needed.

1. The current situation for NOT#NEWS is fine or only needs some small adjustments. This might include defining a guideline to help with writing current events articles (akin to WP:Writing about fiction), but likely no change to policy.
2. NOT#NEWS should be more strongly enforced, and limiting our current event coverage. This might include stronger enforcement of WP:NEVENTS, additional policies relating to NOT#NEWS, encouraging/putting more current news articles to draft space, pushing more content/editors to Wikinews, and the like.
3. NOT#NEWS should be less strong enforced, and expanding our current event coverage. This might include outright removal of NOT#NEWS, adjusting how NOT#NEWS and NEVENTS are written and handled to allow more news, effectively merge Wikinews in en.wiki, and the like.

As this is not an attempt to find a solution right now; I would fully expect that any proposed idea that comes out of that would be under a full Wiki RFC to consider before implementation. So a straw poll is best here. I would request you simply !vote in the appropriate section below, keeping threaded discussion to the provided discussion section. --MASEM (t) 16:23, 25 September 2017 (UTC)

Option 1: WP:NOT#NEWS is working as is

Or: The coverage of current events on en.wiki is about right or only needs fine adjustment

1. What should happen is the creation of a taskforce who routinely checks on news items that don't have longterm impacts. We should be posting items our readers are interested in, without our readers, this is all pointless, but I agree that some things which are instantly recorded as "news" may not have such a long-term impact as to be considered encyclopedic for a long-term view. This is a natural conflict between (say) an "in the news" section and a paper encyclopedia which records genuinely uber-notable events. We should not divest our readers of the things they want to see just because of some snobbish and contrived criterion. The Rambling Man (talk) 20:24, 25 September 2017 (UTC)
2. First choice. Each time I've tried to get articles deleted for violating NOTNEWS (such as Richard Matt) the AfD has gone nowhere - and on each occasion, in hindsight, the judgment of the community has proven correct. There are a good number of editors who like to write about current events and overall I think they do a good job and provide useful articles that bring readers to the project and enhance Wikipedia's reputation. In the discussion at the NOTNEWS talk page there was a great deal of "it's terrible" comments but little in the way of specific examples of a need for change. Coretheapple (talk) 21:25, 25 September 2017 (UTC)
3. I'm not seeing the need for stricter enforcement, and I doubt the practicality of trying to stamp out current events articles. Wikipedia will be what Wikipedians want it to be, and this is what they want it to be. If that doesn't jibe with NOTNEWS, then jettison NOTNEWS. Beyond My Ken (talk) 21:32, 25 September 2017 (UTC)
4. stricter enforcement will not be useful/effective. —TheDJ (talk • contribs) 21:35, 25 September 2017 (UTC)
5. First choice. --Jayron32 14:04, 26 September 2017 (UTC)
6. The folks who are busy AfDing current events article are generally not busy AfDing old-current-events articles from 10+ years ago. Why is that? Because human nature enjoys working with current events, be it inclusionist or deletionist. It's just a manifestation of what people want to work on and how. For those AfDing the old articles, they will need more justification than citing the NOTNEWS alone, like if there has been longer term impacts, consequences of the event. -- GreenC 14:18, 26 September 2017 (UTC)
7. First choice. -- E.M.Gregory (talk) 21:03, 26 September 2017 (UTC)
8. First choice. NOTNEWS, properly applied, strikes a fair balance between keeping encyclopedic material and avoiding the truly mundane topics that also get news coverage. The problem is that there is not much guidance, and too many people think that NOTNEWS is carte-blanche to delete any articles about current events. Wikinews is dead and its writing style is anathema to Wikipedia's. Whether we like it or not, Wikipedia's article on a breaking news event is often the most complete, up-to-date, and unbiased coverage available, which is why so many readers come to us. We should be helping those readers, not hindering them. ---- Patar knight - ^chat/_{contributions} 20:49, 26 September 2017 (UTC)
9. First choice. petrarchan47คุก 18:08, 28 September 2017 (UTC)
10. It is working as it is. The "news articles" are relevant for Wikipedia. So the question here is: should we wait a year or two or longer with writing an article on the topic (since that would be the amount of time needed until the entire investigation and law system is done) or should we write an article on the event and update it. And as we clearly can see: there is a) an interest from Wikipedia users and editors at keeping it the way it is and b) there are enough editors editing it, so the information is from reliable sources and updated very quickly. The "current event" at the head of the article is pointing out, that information can quickly change. The product is actually quite good. Of course we could wait - but that would make Wikipedia less useful (who cares about the event in 5 years from now!?) and the articles would get worse, because less users would edit them.--Albin Schmitt (talk) 14:58, 2 October 2017 (UTC)
11. First choice, lets work on the fine things first before going into major changes. - Knowledgekid87 (talk) 14:59, 2 October 2017 (UTC)
12. First choice. We're never going to get this perfect, when an event is fresh knowing whether it will get persistent coverage over time, etc., is a matter of judgment. On the whole, I think we do okay, I see as many things that appear errors of inclusion as errors of exclusion. --joe decker^talk 15:08, 2 October 2017 (UTC)
13. You're clearly forum shopping, looking for a result that will justify your predetermined solution. No evidence that the policy is a problem other than a few disgruntled editors who won't WP:DROPTHESTICK. Wikinews is dead, editors and readers come here for encyclopedic looks at current topics. They have already spoken loud and clear and have been doing so for years. Gamaliel (talk) 15:17, 2 October 2017 (UTC)
14. I've been working around current events on Wikipedia for 10+ years. During that entire time there have always been people who think we spend too much time covering the news, and there have also been people who think we should do more to cover the news. Personally, I think we get the balance about right most of the time. If I had to choose in the moment, I would probably err on the side of more news articles rather than less. We can always go back and clean-up / delete the less significant news stories later. However, in general, producing a lasting encyclopedic summary out of major breaking news is one of the things we are actually quite good at. This should be encouraged, and for the most part I think it has been. Dragons flight (talk) 15:19, 2 October 2017 (UTC)
15. Disagree with the way this poll has been presented and hope it will not be used as any form of consensus. I don't think a problem has been properly framed – to base it on Wikinews being a "key factor" seems completely out of step with what most Wikipedians do with current events. Wikinews is irrelevant, hasn't been a factor and shouldn't be a factor. As User:Gamaliel alluded to, I cannot avoid thinking that this being the third massive discussion about this (one, two, and this) in as many months is counterproductive and asking the same question over and over again in hopes of getting a different answer. Instead, I'll assume good faith. But I must say this is quite taxing while not really moving the conversation forward. -- Fuzheado | Talk 18:45, 2 October 2017 (UTC)
16. I agree that this appears to be forum-shopping, with essentially the same issues raised with slightly altered language. Even before this is over an effort is being made to generate "observations" i.e., consensus on specific points. Figureofnine (talk • contribs) 18:54, 2 October 2017 (UTC)
17. Seems fine; what should happen is not the creation of new rules, but rather than enforcement of our current ones. And I agree with other editors who say that this "straw poll" was not properly presented. Neutrality^talk 12:28, 3 October 2017 (UTC)
18. I don't see any problem with the current balance; some people are quick to create articles, other people are quick to nominate them for deletion, and there is senseless and futile knee-jerk reaction on both sides, which tends to settle over time into more reasonable results. We'd also need a demonstrated consensus to change anything anyway; we can't just legislate from on high to target the articles we want deleted at AFD. postdlf (talk) 15:10, 3 October 2017 (UTC)
19. First choice Gandydancer (talk) 15:25, 3 October 2017 (UTC)
20. Seems to be working about right the way it is. Some people abuse the guideline to try to get rid of stuff they don't like, but regardless of what happens everything sorts itself out in the end through discussion and becomes obvious with (or without) WP:SUSTAINED coverage. Truly notable subjects will continue to get coverage, and those that are only covered for a short time will get deleted eventually. People on both sides need to realize that there is WP:NORUSH. — Insertcleverphrasehere ^{(or here)} 13:14, 4 October 2017 (UTC)
21. Sure, support aswell. Doc James (talk · contribs · email) 02:27, 14 October 2017 (UTC)
22. Theb alance seems to be working well--as judged by the trend decisions at AfD, there is general agreement on the boundaries, tho sometimes sharp disagreement in specific cases. No change in rules will eliminate that sort of disagreement. DGG ( talk ) 16:49, 14 October 2017 (UTC)
23. Our status quo agreement per RS is the way to go. No need to restrict any further. --QEDK (愛 • 海) 19:30, 14 October 2017 (UTC)
24. Second choice. --Shrike (talk) 10:29, 24 October 2017 (UTC)
25. First Choice The current consensus is adequate with borderline cases being decided at AFD, there is no need for instruction creep Atlantic306 (talk) 20:24, 24 October 2017 (UTC)
26. First Choice - Looks good to me, borderline cases are taken to AfD. The process works, imperfectly, but it works as it is today. XavierItzm (talk) 11:25, 30 October 2017 (UTC)
27. Working fine as is, except in the case of those who interpret it strictly and act like we have no news on Wikipedia or should have no news on Wikipedia. Flyer22 Reborn (talk) 19:51, 12 November 2017 (UTC)
28. I object to this being proposed as a trichotomy, since the question is really "Not The News should be more strongly enforced, Yes or No?" Adding a third option serves as a spoiler, guaranteeing a plurality for the enforce stronger vote, when it does not have consensus. This proposal simply reminds me of IDON'TLIKEIT and those editors who file ANI's and other reports "out of concern for the community" at the drop of a hat or as a modus vivendi. The community is doing just fine, this is an invalidly ill-formed distraction. μηδείς (talk) 20:45, 25 November 2017 (UTC)

Option 2: WP:NOT#NEWS should be more strongly enforced

Or: En.wiki should have significantly less coverage of current events

1. We definitely need to be stricter. Blueboar (talk) 20:11, 25 September 2017 (UTC)
2. Per the fact that WP:TRUMPSCANDALAFD is pretty much standard these days and it can go any way you want. A lot of the keep or no consensus AfDs eventually end up deleted the second go round or merged. Creating clearer standards than the GNG for current events is important, and NOTNEWS is the obvious first place to start with clarifying what is and isn't acceptable to include in Wikipedia immediately. Also, per my comments below, the biggest issue with not enforcing NOTNEWS is that we spend an inordinate amount of time having to deal with enforcing BLP policy amidst shouting and screaming that because something is so notable it must not be covered by BLP policy. This could be avoided both for the good of the encyclopedia and for the subjects of the articles if we encforced NOTNEWS more strongly. TonyBallioni (talk) 20:17, 25 September 2017 (UTC)
3. and this should include daily and weekly updates of sports tallies, film takings and so on. Here we are just acting as a mirror site riding on the websites that specialize in those types of information. Concurrently the main page "in the news" section should be scrapped, it's like a pile of last week's newspapers: Noyster (talk), 23:00, 25 September 2017 (UTC)
4. I think we could strengthen and clarify these guidelines a bit. Kaldari (talk) 00:09, 26 September 2017 (UTC)
5. NOTNEWS needs to be stricter. I don't like inclusionists claiming that a piece of Trumpcruft deserves to be included because it has a couple reliable sources. KMF (talk) 00:50, 26 September 2017 (UTC)
6. I would support allowing for an inter-wiki redirect for these topics, to aid in enforcement. Hurricane Harvey was obviously notable as it was happening, but even there it would be better to have people do live updates of that page on Wikinews. With SUL there's no editor burden to editing on a different Wiki domain. power~enwiki (π, ν) 01:07, 26 September 2017 (UTC)

   Wikinews is largely a failed project that doesn't really report on any of the major news events that we are discussing here. Just pointing that out as an example of why the interwiki links wouldn't likely work. TonyBallioni (talk) 01:51, 26 September 2017 (UTC)

   I'm not familiar with the details of why it failed, but I'm aware that it's mostly dead. Pointing editors from en.wikipedia to it (for certain topics) would need to be part of a plan to revive it. power~enwiki (π, ν) 02:46, 26 September 2017 (UTC)

   From my experiences on WikiNews, there were not enough reviewers and a very short deadline (3 day) to have a review. With no review or updated/additional info, the potential article is deleted. This would even occur when the article would indicate a future event when additional information or action would be taken and was noted by said editor (me). This would frustrate writers as most of their work would be deleted. Spshu (talk) 16:55, 15 November 2017 (UTC)

7. Above points taken on Wikinews and the inanity of repeated "current event" AfDs. I don't know what good additional "rules" will do here, but I do think it would be smart to funnel/interwiki our less encyclopedic topics into Wikinews articles, or at least reach out to the English Wikinews editors to see how the content may be transferred fruitfully. (Has anyone reached out?) On the other end of the predicament, I think better enforcement of summary style for new topics makes for better encyclopedic coverage. Standalone topics tend to collect all kinds of overly specific detail and tone unfit for a general audience. czar 03:05, 26 September 2017 (UTC)
8. As per Tony. While I agree with the Option 1 comments that stronger enforcement of WP:NOTNEWS as a whole in the moment isn't realistic and at times can be counterproductive, there are certain aspects of it (for example WP:BLP as Tony says) which are IMO incredibly important. And although more bureaucracy is really not the best way to deal with anything, I think that it could be useful to have some sort of review of current events articles a certain amount of time after creation to determine if it meets the notability criteria that can't be determined while it's still in the normal news cycle (WP:SUSTAINED, for example). The ideal solution would be for people to wait before creating articles instead of having them nominated for deletion immediately and then having those discussions closed with a "wait and see" type result, but that really isn't going to happen. ansh666 08:57, 26 September 2017 (UTC)
9. For reasons of notability and BLP. Fram (talk) 12:06, 26 September 2017 (UTC)
10. And this can be enforced as soon as admins discount the "wait and see" tactics inclusionists employ at AfD. This has become the most popular rationale to keep an article when it fails the actual substance of WP:EVENTCRIT. Or discredit the "easily passes GNG" votes which is not the case on a news event. Another thing we need consensus for is converting WP:RAPID to an essay; it contradicts itself and has no basis on notability yet inclusionists use it as a safeguard for deletion.TheGracefulSlick (talk) 16:56, 26 September 2017 (UTC)
11. My idea for stronger enforcement would perhaps involve changes to policy for a, presumed, "immediate" forced merger to existing articles of breaking news, say to last for at least a week or two - perhaps with a breaking news merger noticeboard and project, and a simultaneous allowing of a "draft" article that is indexed. -- Alanscottwalker (talk) 20:50, 26 September 2017 (UTC)
12. Wikipedia has stupidly encouraged the hoi polloi to reflexively come here to post their own truth, aided and abetted by the overenthusiastic among us who seek to write about every current event. Not only do many of these creations fail notability criteria, we give their subjects short shrift by parroting the contemporaneous screed from mere journalists. Chris Troutman (talk) 00:58, 27 September 2017 (UTC)
13. News coverage of current events is and should be treated as primary sources. Wikipedia is an encyclopedia. While we err on the side of more coverage by allowing some articles to rely mostly on primary sources, events that are entirely and solely sourceable to news media should not be covered by Wikipedia. This is why we made Wikinews. —/Mendaliv/^2¢/_Δ's/ 02:00, 27 September 2017 (UTC)
14. Per Mendaliv and other above. Whether Wikinews is functioning or not, it doesn't change the fact that we're an encyclopedia, not a news outlet. Ealdgyth - Talk 14:12, 27 September 2017 (UTC)
15. Too many people think if it was in the papers it must be notable. Many things are in the papers becasue they are interesting and satify people's thirst for something to engage their interest - which sells papers - but they are not notable in the scheme of things. The internet has made all this information so much more readily available but run-of-the-mill events have been happening for millenia. One only needs compare the ratio of recent events recorded here to the similar events that happened 30, 50 or 100 years ago. This encyclopedia is fast becoming the Readers Digest version of online newspapers. ClubOranje^T 19:40, 28 September 2017 (UTC)
16. I am not sure we can actually enforce NOTNEWS anymore, as people have become used to Wikipedia being pretty good (and a lot better than Wikinews) at covering current events. However, I think we should at least try. As a first step, maybe we can replace the "In the news" section of the Main Page by a link to Wikinews? —Kusma (t·c) 21:26, 28 September 2017 (UTC)

    @Kusma: For what it's worth, that has been proposed before and shot down because of inactivity at en.wn. ―Justin (koavf)❤T☮C☺M☯ 22:22, 28 September 2017 (UTC)

    @Koavf: I think our ITN section is one of the things that cause inactivity at Wikinews. —Kusma (t·c) 08:56, 29 September 2017 (UTC)

17. We should be stricter with this, especially given the recent influx of political articles being created preemptively. Jdcomix (talk) 17:16, 29 September 2017 (UTC)
18. I think the basic problem here is that Wikipedia operates on an idiosyncratic definition of secondary sources that includes news reports. Everybody outside Wikipedia regards news reports as primary sources, so we should do the same, and follow our basic principle of basing articles on genuine secondary sources, which can include some content published in newspapers, such as profiles and background articles that look at events over a long term, but not contemporaneous news reports. 86.17.222.157 (talk) 19:48, 29 September 2017 (UTC)
    1. I agree with 86.17 on the "secondary source problem": WP:Secondary does not mean independent. However, I think it's a bit more complicated than that. WP:PRIMARYNEWS covers some of the differences between a primary news source (e.g., eyewitness news reports) and a secondary source that is published in a newspaper (e.g., news analysis). WhatamIdoing (talk) 19:16, 17 October 2017 (UTC)
19. Per User:Noyster (great reasoning)....but trying to enforce that would be daunting....endless editwars and RfC's. --Moxy (talk) 19:58, 29 September 2017 (UTC)
20. I agree with several of the points in the comments above, ultimately boiling down to "I support the existence of WP:NOTNEWS for the reasons we have it in the first place." In the interest of thinking about enforcement strategies, I'll say again that this seems like a perfect use of the draftspace. See, although Wikinews hasn't done so well, Wikipedia does sometimes cover news well (that doesn't mean we should be doing so, of course -- I'll bet we could do lots of the things from WP:NOT well). Because many of the subjects do turn out to be notable, I see no reason why we shouldn't use the draft space to capitalize on short-term interest for the benefit of the long-term article. — Rhododendrites ^talk \\ 02:02, 30 September 2017 (UTC)

    That's an interesting observation about draft space. My experience of it has been that it is used as an excuse to delete articles about topics that don't qualify for deletion under policy and that should be developed in main space where they are visible to potential editors, as has always been a central part of the wiki process, but this seems like a valid use of that space. 86.17.222.157 (talk) 09:52, 30 September 2017 (UTC)

21. To abandon or weaken NOTNEWS is a counsel of despair IMO. I hope to have time to leave a longer post over the next few days, but believe we should clarify (to ourselves at least), that we are notnews for good reasons. These include that we undertake a longer-term responsibility to the subject, to give the more complete and rounded picture than that revealed in yesterday's headlines. I agree that it would be nearly impossible to put a 'full embarge' on news articles, and many of the 'big event' ones are well-written and accurate surprisingly quickly. However, IMO, it is a simple mathematical inevitability that the more we become simply a 'news archive', the less we will have any encyc. character or purpose. Pincrete (talk) 11:22, 1 October 2017 (UTC) … … ps I endorse the "is fast becoming the Readers Digest version of online newspapers" comment above, I wish I'd thought of the analogy! Pincrete (talk) 11:28, 1 October 2017 (UTC)
22. Stricter. I agree with Pincrete. BLP is a major issue, as are the seismic changes (hm, is that hyperbole) in not just American but other countries' resulting in a large number of new articles, as mentioned above, and new editors with no knowledge of our guidelines and often SPAs. Doug Weller talk 14:02, 1 October 2017 (UTC)
23. Same fix I've proposed before, which is a policy WP:Criteria for Speedy Incubation which is like WP:CSD.  A new criteria allows a breaking news article to be moved to draftspace, with the mainspace title being salted for 7 to 14 days.  An AfD in progress gets procedurally closed WP:NPASR.  The problem I'm seeing is that AfDs are spinning their wheels analyzing notability with a moving target.  As I posted yesterday at DRV, the problem pushes forward to other forums when decisions are made based on moving-target notability.  Unscintillating (talk) 20:24, 1 October 2017 (UTC)
24. Stricter. I'm glad to see this straw poll because I've often wondered about WP:NOTNEWS myself. While Wikpedia is fast becoming a gutter press, some of the more serious news items also belong on Wikinews. I don't know how we can achieve this. Kudpung กุดผึ้ง (talk) 00:32, 2 October 2017 (UTC)
25. Stricter. There is far too much insertion of trivial news events, commentary about our subjects and lengthy quotations. It gets in the way of knowledge. I am developing a solution. Join me. - Shiftchange (talk) 00:55, 2 October 2017 (UTC)
26. Stricter. Too many articles are being created which have a splash in the news with no lasting notability. - Knowledgekid87 (talk) 14:57, 2 October 2017 (UTC)
27. Agreed. Creating lasting enyclopedic articles with proven information backed by references in solid reliable sources is something the wiki system does (perhaps suprisingly) very well. Mimicking the National Inquirer and TMZ, not so much. Andrew Lenahan - Starblind 17:13, 2 October 2017 (UTC)
    • And the WSJ, NYT, Washington Post, NPR aren't solid reliable sources? Using them to cover fairly recent events would be an issue because we'd be like TMZ? I'm not quite getting your point here. Hobit (talk) 11:24, 23 October 2017 (UTC)
28. Definitely. And in particular the insistence on lasting interest in a subject is widely disregarded. Mangoe (talk) 22:04, 2 October 2017 (UTC)
29. There is definitely a problem of people with WP:RECENTISM forgetting that we want encyclopedic knowledge, not blow-by-blows of unfolding events simply because they are sourced. That can range in the short term of a few hours or events happening over a day or two. Sometimes, an event is going to take a longer time to determine whether it's truly a significant event or not. Lawsuits are a good example of the latter where they came take time, sometimes years, but you get people pushing to things like ambulance chasing suits to articles because a newspaper reported that someone got sued (as opposed to the court decision that establishes the encyclopedic value). I'm not sure how we can stress that Wikipedia takes the long view even more though. Kingofaces43 (talk) 22:25, 2 October 2017 (UTC)
30. I am mostly in sympathy with this view. Many articles about recent events are simply summarized news reports, often contemporaneous to the event, with little or no long-term view. It's basically a news feed. On the other hand, at the beginning stages, a summary of the various news reports is the only thing known about the topic, and many people come to Wikipedia to get a decent overview. It's something Wikipedia does passably well, though there are many distortions involved. My instinct is that Wikipedia should not be summarizing news; that's not its job, and BLP issues also frequently arise. Kingsindian ♝ ♚ 02:12, 3 October 2017 (UTC)
31. Example: Every time someone who works for Big Company A tweets a stupid thing and gets fired, people run screaming to Big Company A's article to tack it on or to create a "Controversies" section. Wp:NotNews needs to be beefed up to be a bulwark against the headline-of-the-moment news cycle. TheValeyard (talk) 04:08, 3 October 2017 (UTC)
32. Stricter. As I often try to parse bias, as opposed to going into edit wars, the "value" of perceived editors over recent events ends up in clear bias and conflated news items, with loooooong talk pages of arguing what is notable or noteworthy, when in reality, if they waited an hour, they'd get confirmation or an RS. I just supported an AfD for "reactions" for the Vegas shooting, because it was full of "my prayers and sympathies"... from Mariah Carey, for example. Just as I support removing conjecture on weapons used, etc., if Wiki is to read like an Encyclopedia, then something that has hard fact that will be released in the coming days or even hours, including wild speculation from people not on the scene is actually the currently supported way to do it on the 2017 Las Vegas Strip shooting. In fact, the name of the page itself is a bit wonky, because it wasn't on the strip and didn't target the strip. (And actually was performed within confines known as the South Strip, which makes a bit of a difference geographically.) As an encyclopedic entry, it would be named something like Jason Aldean Concert Shooting or Route 91 Harvest Music Festival Shooting. Alas, someone had to rush it to Wiki and rush to slam in a bunch of conjecture and unrelated facts. Trying to bring sanity to edit wars when that happens is nigh impossible. Avoiding the mess in the first place would be ideal. Seola (talk) 05:36, 3 October 2017 (UTC)

    I should also add, like others mention, when an event may or may not be notable waxes and wanes. There are a great many stub pages of events that no one can remember and no one looks for. I come across them and try to clean them or if I can't, I nom for AfD. And invariably, some random editor comes by and insists that nothing on Wiki should ever be removed because it was justified "at the time". There is just too many of these junk articles as it is. Putting up stricter guidelines would avoid errant words, phrases or sentences that also often happen when edit wars are going on, especially when vandalism is missed, because so many edits are happening at once.Seola (talk) 05:40, 3 October 2017 (UTC)

33. Wikipedia's structure makes it far too easy for any user to create an article about the latest minor controversy, meme, or viral incident without meeting criteria or consensus that the page should exist, while far too hard to remove an article that shouldn't be here. The proliferation of news sites that piggyback on each other's work without independently providing notability undermines the GNG and in turn the project as ephemeral topics all have their own low-quality articles. We should also encourage more summarizing into main or related articles, rather than permitting subarticles to be made for so many little things. (See also: also the awful "International reaction to..." quotefarm articles). Reywas92^Talk 06:22, 3 October 2017 (UTC)
34. Realised I hadn't actually !voted. Per my comments elsewhere and below regarding current news coverage. Only in death does duty end (talk) 10:12, 4 October 2017 (UTC)
35. It should be more strongly enforced, but in an even-handed manner that treats similar situations similarly, rather than in an ad hoc or partisan manner. I’d suggest that we more strongly discourage material about recent news that relies on primary sources, including newspaper opinion pieces and blog posts that have not been deemed worthy of mention in reliable secondary sources. We could also discourage material about recent news that names people who are expected to remain non-public figures. If we carve out particular areas like this for special treatment, then we can make good progress toward enforcing NotNews in a way that isn’t apt to change e.g. when the political shoe is on the other foot. Anythingyouwant (talk) 23:35, 5 October 2017 (UTC)
36. An encyclopedia does not need any of the transiently popular "stories". Rentier (talk) 23:58, 5 October 2017 (UTC)
37. As as been said, we want to report the controversy, not to be art of it. One of the main issues are probably a nees to clarify notability (say a election result is immediatelly notable, some fact about the latest shooting may be or not - and we should play on the safe side). That WikiNews is not active (or not) is not a reason to have news(ish) articles here. If we have no "news" here, probably WikiNews would work better - better connection / linking to and from may benefit all: editors and readers of both tendencies. "Sell" it as "the wikipedia of recent events", link to it for day-to-day timelines, and so on. - Nabla (talk) 18:27, 7 October 2017 (UTC)
38. Only choice. This also works to counter systemic bias in favour of northern hemisphere, western news. Stifle (talk) 15:56, 9 October 2017 (UTC)
39. Absolutely. Recent news articles are too often irreparable messes created with the presumption that an AP/Reuters report parroted by half a dozen news portals constitutes eternal notability, and hijacked by editors with a chip on their shoulder who edit war until the subject (doomed to "no consensus" on AfD) falls into oblivion a few months later. I think Wikipedia would do better without the product of such labour. Daß Wölf 18:25, 14 October 2017 (UTC)
40. Both as to inclusion of "passing stuff" and misuse of WP as a "live feed", e.g. of questionable and basically OR sports scores, casualty tolls, etc. which we don't know are confirmed until some time has passed. As just one example, a snooker ranking tournament article was recently updated over 300 times in the space of a day or two, to provide live coverage of game results. This is not what WP is for, and there are snooker news sites that are for this. We need not have any results tables at all until the event is over and RS confirm the results. "I was there" isn't a source, and "I saw the win on a televised match" isn't a reliable one. I'm not picking on snooker coverage in particular, I just saw it yesterday. The problem is likely much worse for things like football/soccer.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  01:13, 21 October 2017 (UTC)

    The problem isn't usually so bad with sports, because the running commentary is usually factual. but, more seriously, we get similar running news added to Wikipedia about news events that may or may not be terrorism based on primary news reports. We had an article created recently that was edited by loads of people about a road traffic accident in Exhibition Road, London, because the initial reports speculated that it might be terrorist-related, although it turned out pretty quickly that it was not. Why can't we just do our job as an encyclopedia and wait for secondary sources to appear before rushing to create an article based on editors' own interpretation of primary sources? 86.17.222.157 (talk) 16:32, 22 October 2017 (UTC)

    Um, that's exactly what I'm suggesting.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  15:07, 6 November 2017 (UTC)

41. The problem with such intensive coverage of the news of the day is that you end up with lots of abandoned articles about stories that are forgotten fifteen minutes after they occur. What Wikinews is or is not doing isn't really relevant to a discussion about what is happening here on Wikipedia though. Lankiveil ^{(speak to me)} 00:27, 24 October 2017 (UTC).
42. For several reasons. (1) Articles in news sources are typically primary sources, because they are part of the context in which an event occurs, and just as we follow medicine's definition of primary sourcing when writing about medical topics (WP:MEDRS), we need to follow history's definition of primary sourcing when writing about history, which includes events. Exceptions occur, as a news story may mix primary and secondary coverage of different events, e.g. it talks about an ongoing event and discusses the context in which the event started 100 years ago, or a news source may provide purely secondary coverage, e.g. it only discusses the context in which that event started. Let's ensure that only secondary sources are used, except in the less common situations in which WP:PRIMARY permits primary-source usage. (2) How often is a news editor or a reporter a topic specialist? He's a specialist in good writing or so we wish..., in selecting what subscribers and newsstand-purchasers will want to buy, and in condensing the story down to what will fit on the page, but in nearly all cases, your news editor and your reporter have average knowledge about the topics in which they're writing. See WP:RSBREAKING, which {{Recent news}} links — we're admitting that news coverage is often wrong, so why do we permit it? (3) Finally, an encyclopedia reports what's covered in secondary sources. In most cases, you can't predict that something showing up in a newspaper will be covered in secondary sources that won't be published until months or years in the future. Yes, there are exceptions, e.g. a news report saying that this candidate won 1,234,567 votes, while his competitor won 1,000,481 votes, but unless you can show that exactly this kind of thing has been covered in the past, you're making a statement that secondary sources will cover a topic, and no reliable, published sources exist to support this allegation, to paraphrase the intro to WP:OR. This is particularly a problem with political stuff — how can you be certain that future political historians will care about the latest mini-scandal? Nyttend backup (talk) 21:09, 25 October 2017 (UTC)
43. Trying to keep current events and news is a waste of valuable time, there is always something to do on en.wiki. Kanarya08 (talk) 08:50, 1 November 2017 (UTC)
44. Absolutely - much of today's published news combines publisher/journalist POV, propaganda, and a splattering of facts buried under allegations in order to create the level of sensationalism needed in the highly competitive bait/click news environment. While printed news has pretty much become obsolete, publishers still need to "sell papers". Look at it from the POV of a hungry journalist and publishing execs who need to generate revenue in a highly competitive market. On the other hand, WP's growth has been the result of adherence to our 5 pillars not the bait/click sensationalism used by news sources to attract readers. The importance of maintaining NPOV and factual accuracy cannot be overemphasized. ^{Atsme📞📧} 12:26, 2 November 2017 (UTC)
45. Yes, I think there is way too much rushing to see who can be first to sloppily report something that could be covered better with the passage of time. On the other hand, I don't see a way that we could really enforce this, because so much will depend upon local consensus for each case. --Tryptofish (talk) 21:47, 3 November 2017 (UTC)
46. Trying to police news-like articles will be impossible should wikipedia embrace news-like articles. A trip to WP:AFC shows that POV-Pushing is a massive problem as-is. If Wikinews is dead, revive it. RfCs have previously operated on a principle of "Wikinews is dead", so why not change that? If there's truly interest of news in a Wiki-like environment, then go to wikinews, for god's sake, instead of opening the door for POV-pushers. ProgrammingGeek ^talktome 15:43, 8 November 2017 (UTC)
47. Of the options here, I suppose this comes closest to my own view — but what I mean, in part, is that we should have clearer guidelines and not merely tighter ones. It's undeniably true that some breaking news events do turn into good articles about important events of enduring notability through the collaborative editing process — but it's also undeniably true that some people seem to think every individual bit of flotsam or covfefe that turns up in any media at all always merits its own standalone article. For instance, there is currently 2017 Ottawa Storm, a wholly unremarkable thunderstorm with entirely run of the mill effects whose coverage didn't even extend into the next day, let alone the next year — thankfully it's up for deletion, and I see no prospect of it surviving that, but I'd still prefer that nobody had ever thought it would warrant an article in the first place. There are obviously certain news stories that are almost always going to be valid and enduring article topics that pass the ten-year test (remember, 9/11 was once a "breaking news" story), and certain news stories that are virtually never going to be valid or enduring article topics that pass the ten-year test (we do not need an article about every house fire or every murder or every thunderstorm that happens anywhere at all). But perhaps we could stand to be a little clearer about how to apply some actual discernment to which side of that line any given news story falls on, because it's particularly easy to make the wrong call on a news story in the initial rush of "this just happened" coverage. Bearcat (talk) 19:38, 12 November 2017 (UTC)
48. I support stricter, especially in cases where scholarly sources and news sources conflict, and the scholarly sources are considerably more detailed in their analysis. There are also numerous criticisms of news sources relying on unnamed, anonymous sources. Further, there is a tendency to selectively cherry pick quotes from articles, and when used this way they are basically WP:PRIMARY in support of WP:OR. These issues are all already implicitly addressed by our policies, but stating it more explicitly may help. Seraphim System ^(talk) 20:00, 12 November 2017 (UTC)
49. Second choice, given that each is met:
    • Generally, WP:NOTNEWS-violating articles should always be taken to AFD instead of CSD; as a controversial issue this should be beyond debate.
    • GNG should be assumed until the fact that the article indeed consists of primary sources is proven.
    • Lastly, the quorum is expanded dramatically to allow further opinions.

    ToThAc (talk) 18:29, 13 November 2017 (UTC)

50. As, I once indicate on Meta as to deal with link rot/citation issues by using [1]. With WikiNews articles could be used as sources (as they have to be reviewed/verified) and enforcing NOTNEWS here with a way to move articles to WikiNews should cause an upsurge in writers (and hopefully reviewers) at WikiNews and as WP's rotlink solution. Spshu (talk) 16:55, 15 November 2017 (UTC)
51. Wikipedia is not breaking news. Especially on political topics. PackMecEng (talk) 16:05, 20 November 2017 (UTC)
52. Stricter. Current news is not necessarily notable, even if it's, like, totally on CNN for a week straight. SpartaN (talk) 04:30, 6 December 2017 (UTC)

Option 3: WP:NOT#NEWS should be less strongly enforced

Or: En.wiki should have more expanded coverage of current events

1. Weak support here - I dislike the current push against current events, but I don't think that we should fully become like a newspaper (i.e. we should take into account the lower reliability of reporting on current events and require more sources than usual to pass notability for current events). RileyBugz^会話_投稿記録 18:24, 25 September 2017 (UTC)
2. It'll be what it's going to be, and if that doesn't align with NOTNEWS, get rid of it. Beyond My Ken (talk) 21:34, 25 September 2017 (UTC)
3. Support. The problem with "NOT#News" is that a) it is a badly written policy, like all of WP:NOT, because it is all written as part of a list of negative things rather than as a direct statement of policy, and b) none of its "enforcement" (i.e. taking out articles about things because you dislike them politically, which is what that means in practice) has anything to do with what it says. Conversely, when you see a blindingly obvious violation of the text as written -- like the list of current watches and warnings in Hurricane Maria, temporary content that is being taken out the moment it expires, complete with a special disclaimer at the top of the article -- nobody seems to give a damn. I say if you have a dog that can't hunt and can't point and can't fetch but it can sink its teeth into every car tire, neighbor and postman that goes past, it's time to think about getting rid of the dog. Wnt (talk) 11:54, 26 September 2017 (UTC)
4. Second choice. The problem with WP:NOTNEWS is that it is over-used by people who think it means "If it is reported by newspapers somewhere, it is AUTOMATICALLY not appropriate for Wikipedia." which is fantastic over-reach. News coverage does not disqualify or invalidate Wikipedia content, and yet I would (unscientifically estimate) that WP:NOTNEWS is envoked more than half of the time as a deletion rationale rather than as style guidance. --Jayron32 14:06, 26 September 2017 (UTC)
5. I guess this is my second choice too, thank you Jayron32 for reminding me of that option. I agree with Jayron32 that NOTNEWS is overused, and if any changes are necessary they should be in that direction. Coretheapple (talk) 14:35, 26 September 2017 (UTC)
6. Second choice per Jayron32 and Coretheapple. NOTNEWS should work as it is, but it often doesn't. ---- Patar knight - ^chat/_{contributions} 20:58, 26 September 2017 (UTC)
7. Second choice. The problem with WP:NOTNEWS is that it is over-used by people who think it means "If it is reported by newspapers somewhere, it is AUTOMATICALLY not appropriate for Wikipedia." To this I want to add that our readers expect certain kinds of news stories to appear on Wikipedia, and that is no bad thing, not least because it has long seemed to me that the urge to add a bit of information to a breaking news story - or even to start an article on a news event, seems ot sometimes be an entry point for new editors. Of course, more editors would be the best solution to this and many problems and the nasty aggression on exhibit seems to drive editors away. I think one solution is for editors to hold off bringing articles to AfD on NOTNEWS rationals for about 3 months, a waiting period would reduce the Sturm und Drang factor.E.M.Gregory (talk) 21:02, 26 September 2017 (UTC)
8. Support—Current events are a way to capture editing energy and to rapidly compare developing information. It's one of Wikipedia's unique contributions to global knowledge, based on the fact that it's the only near-real-time encyclopedia. There should be strong enforcement of standards (BLP, V) on current events stories, but patient evaluation of notability for borderline cases. The quick but byzantine disputes over notability during a highly charged time pose emotionally charged questions that new editors are not ready for: are these atrocity victims significant? will that protest affect the course of the state? We're better served having editors focus on sourcing and information gathering than on debating these questions. And we're better off having started articles of borderline permanent notability (e.g., this article on Egyptian protests by midnight of 25 January 2011) Then, after a short-term time window (7 or 14 days, perhaps), evaluate notability and keep, delete (if of poor quality), or export to Wikinews (if not notable).--Carwil (talk) 18:52, 28 September 2017 (UTC)
9. Weak support. The problem with WP:NOTNEWS enforcement right now is that it often causes highly-trafficked articles to be nominated at AfD, with editors spending their efforts arguing for or against deletion instead of trying to improve content viewed by many people. This reflects badly on Wikipedia, and visitors may also perceive Wikipedia to be heartless when they see a large rectangle on top of an article about a significant news event that may or may not be notable. It can be argued that this may be a good opportunity to introduce casual visitors to the world of Wikipedia, but emotionally charged discussions about whether a news topic is WP:N notable or not, often before there is enough time for long-term coverage to be developed, is not an image we want to present to prospective editors. Whether that means NOTNEWS needs to be changed is debatable, but it is best to benefit the most readers efficiently, and ugly AfD discussions right in the face of readers aren't going to accomplish that. feminist 14:51, 29 September 2017 (UTC)
10. Support, with Option 1 as a close second choice. (I notice that the introduction includes "This might include outright removal of NOT#NEWS" as part of option 3 – I would strongly oppose that; what I'm agreeing with is "expanding our current event coverage".) Anything which receives significant coverage should be included in Wikipedia. Readers are not everything, but I think the deletion of reliably sourced content receiving high traffic is a shame when it occurs. Obviously volunteers are allowed to direct their energy anywhere they want, but I think it is suboptimal when we waste time on long AfD discussions instead of improving the article, or large efforts deleting things rather than creating them (in the specific case of well-sourced articles on recent news stories). Per the eloquent arguments of RileyBugz, Carwil, Coretheapple and feminist. — Bilorv_(talk)^(c)(e) 20:14, 29 September 2017 (UTC)
11. Support per Bilorv; similarly, Option 1 is fine as well, but there's no need to outright remove NOT#NEWS. I think a good metric for news stories - as hinted at by The Rambling Man - is "will this be interesting in 10 years time, or even 100 years time." But... actually quite a bit of seemingly transient news IS relevant, and will still matter 100 years later. There've been plenty of AfDs on content that, if it had happened in 1927, would still be a fascinating slice of life of the times - maybe even just that this was considered relevant, even if it blew over eventually. (Like... if 1927 KLM Fokker F.VIII crash was as well-built up and sourced as 2006 New York City plane crash (which was AfD'd on NOTNEWS grounds), that'd be great! SnowFire (talk) 09:26, 30 September 2017 (UTC)
12. Support WP:NOTNEWS should be removed per WP:CREEP and WP:NOTLAW. It is obviously our policy and practice to cover items in the news, including breaking news. The way in which we do this is best covered by other, existing guidelines such as WP:UNDUE, WP:N, WP:OR, WP:SUMMARY which address the issues more clearly. Andrew D. (talk) 12:56, 1 October 2017 (UTC)
13. Support per Andrew Davidson. Current events is a significant aspect of Wikipedia's mission, as recognized by the "in the news" section of the main page. Those who wish to turn this into the Britannica are blind to the realities of the way the project works. Figureofnine (talk • contribs) 15:19, 1 October 2017 (UTC)
14. Full Support.--Albin Schmitt (talk) 14:59, 2 October 2017 (UTC)
15. Support IMO Wikipedia provides an enormous public service by covering news, even (or especially) hot breaking news like Las Vegas Strip shooting. We have not historically had a problem with people putting unconfirmed or incorrect information in such articles; they are usually carefully monitored and vetted by experienced editors. My own experience is that a Wikipedia article about a current event is usually more accurate than any single news report. I'm not saying to abolish NOTNEWS - we don't and shouldn't cover everything as soon as it hits the press - but we should recognize that sometimes it is our duty to our readers to cover this kind of information in a timely fashion. --MelanieN (talk) 23:02, 2 October 2017 (UTC)
16. Support WP:NOTNEWS is generally employed to give teeth to WP:IDONTLIKEIT. The best time to find reliable sources is before link rot sets in. I have found that many articles nominated for deletion under WP:NOTNEWS still have appreciable traffic ten years later. Leaning towards supporting Andrew D.'s suggestion of abolishing WP:NOTNEWS entirely; but it certainly should be added to WP:AADP Hawkeye7 (discuss) 20:17, 3 October 2017 (UTC)
17. Support Agree with MelanieN that breaking news articles are closely monitored and poor-quality content is quickly removed. Our community does a remarkable job of sorting out verifiable facts as they become available and quickly building a high-quality article. We're not running out of space, so I don't see a reason to delete articles simply because they are old news. –dlthewave ☎ 23:00, 3 October 2017 (UTC)
18. Support If it is reliably sourced, there is no reason why we should not have an article. Verifiability concerns I can respect, some news stories are covered in a way that are guaranteed to give a distorted picture of the subject and thus leave an article that can never be accurate (e.g. BLP1E type), but for many events this is not the case. As to 'will this be important in 10 years?', who cares? If you don't want to write articles on things of no lasting importance, you don't have to --but if I want to, let me. Antrocent (♫♬) 04:24, 4 October 2017 (UTC)
19. Support as first choice – Verifiability is the reason we have notability standards. It is very easy to verify information on news items, as there is heaps of news articles about them. I do agree though, that articles made extremely quickly after a news break, articles every time Trump says something, and news reports should still be permitted as part of WP:NOTNEWS. J947^{( c ) (m)} 21:59, 7 October 2017 (UTC)
20. Support NOTNEWS is redundant with WP:N. Smooth alligator (talk) 19:57, 11 October 2017 (UTC)
21. Support Used as an excuse not to cover current events. People expect us to cover current events and we do a generally okay job at that. Of course we do not break stories but that does not mean we should not summarize notable stories. Doc James (talk · contribs · email) 02:26, 14 October 2017 (UTC)
22. Support NOTNEWS as currently implemented is detrimental to Wikipedia's mission. It is fine as written, but people act like it should overrule GNG when it comes to covering events. The best use of NOTNEWS is to balance against article notability for routine coverage of local events and against the recentism of giving undue coverage to minor events in news cycles as well as regulating Wikipedia's tone. I largely agree with Hawkeye7, and would like to add that its invocation is often about proving a point rather than supporting free knowledge. Winner 42 Talk to me! 15:29, 14 October 2017 (UTC)
23. Kind of I think we mostly hit the right place, but there are too many people making arguments that newspapers are primary sources or NOTNEWS means we shouldn't cover much of anything recent. I've seen more and more of that recently. So mostly "we are in a good place" but also "I'm worried we are pushing towards too strong of a NOTNEWS world". Hobit (talk) 04:26, 21 October 2017 (UTC)

    Can you identify any source outside Wikipedia that does not regard news reports as primary sources? Any introductory book about history aimed at high school or undergraduate students explains that they are pretty much the definition of primary sources. 86.17.222.157 (talk) 16:38, 22 October 2017 (UTC)

    Secondary sources describe, discuss, interpret, comment upon, analyze, evaluate, summarize, and process primary sources. Secondary source materials can be articles in newspapers or popular magazines, book or movie reviews, or articles found in scholarly journals that discuss or evaluate someone else's original research. An interview is a great example of a primary source. An article that summarizes a number of interviews and court documents is a clear secondary source. Hobit (talk) 22:26, 22 October 2017 (UTC)

24. First choice In my opinion events that discussed widely in world media is worthy to include in Encyclopedia. --Shrike (talk) 08:12, 23 October 2017 (UTC)
25. Second choice provided there is coverage in multiple secondary sources such as newspaper analysis rather tnan basic primary reporting Atlantic306 (talk) 20:27, 24 October 2017 (UTC)
26. First choice as there are already remedies in place for dealing with these kinds of articles, and bringing up issues about POV-pushing likely comes in violation of WP:SUSCEPTIBLE. Also, I never thought Wikinews was a good concept after briefly looking at it, and never will. ToThAc (talk) 19:50, 9 November 2017 (UTC)
27. Should be less strictly enforced or rewritten to be even clearer since we have so many editors who misuse the policy. Makes no sense to try to act like Wikipedia shouldn't cover news. Wikipedia is not a traditional encyclopedia and never will be. I mean, good luck trying to keep articles like 2017 Las Vegas Strip shooting and Harvey Weinstein sexual abuse allegations off Wikipedia. Flyer22 Reborn (talk) 19:57, 12 November 2017 (UTC)
28. Weak support. I think we should allow for creation of more current events, but clean them up a few months after the event has lapsed and we can assess lasting notability better.Icewhiz (talk) 00:10, 14 November 2017 (UTC)
29. The current approach to "newsworthiness" is broken. We get into too many pointless arguments over at WP:ITN/C for example, over what should be included, and it ends up based on editor's personal preferences, with a cite to WP:NOT#NEWS, rather than a reasoned argument based on reliable sources. Whereas in fact readers should come first. If Donald Trump is being inaugurated on a particular day, and all the newspapers worldwide are covering that with full page splashes, then it should be in our ITN section. That shouldn't even be a debate. We're not a news ticker, but we're also not the judges of the world's values.  — Amakuru (talk) 17:26, 14 November 2017 (UTC)
30. If a current event is clearly notable, getting a "first draft" done while people are actually interested is important. OF COURSE, articles should pass WP:N. But in many cases, they clearly do and NOTNEWS is used to shut down articles that people don't like, not as a as an actual concern. We should WANT Wikipedia to be up to date and current.Casprings (talk) 21:15, 18 November 2017 (UTC)
31. Abolish. This is used solely to push POVs. The whole idea of NOTNEWS was ludicrous (if not malicious) to begin with, and it contradicts GNG. It is used to delete articles solely because they may be new, controversial (WP:SUSC), and/or most of its sources are news outlets. It was never clear, and I do not think that it was ever intended to be. I'm opposed to keeping NOTNEWS in any form whatsoever. Furthermore, we must retroactively restore any articles deleted under this 'policy'.  — Mr. Guye (talk) (contribs)  04:52, 7 December 2017 (UTC)
32. Strong support in many cases Wikipedia's ability to bring facts together from multiple sources and present them in a neurtral way makes it a valuable way to consume information about new events. ChristianKl (talk) 13:30, 8 December 2017 (UTC)

Threaded discussion on NOT#NEWS

On NOTNEWS, I think that the main issue that people have with it is the notability of recent events. I think that we all agree that Wikipedia should not be written in a news style. But, we don't agree whether recent events should ever have a chance of being notable (until a week or so after) or whether we should just increase the number of sources needed for notability. RileyBugz^会話_投稿記録 18:32, 25 September 2017 (UTC)

No, notability is not the main issue. The main issue is that current events are magnets for BLP violations: even if they are notable they are also normally UNDUE and all sorts of other BLP issues, plus a massive suck on the community's time in making sure that BLP is enforced on a highly visible page and figuring out what to do with the content. TonyBallioni (talk) 20:20, 25 September 2017 (UTC)

I wouldn't necessarily eliminate notability from this. Inappropriate assessment of notability based on volume of news sources can lead to a too-narrowly defined article on a news topic that does happen to be the subject of much recent news, but where the potential for BLP violations (among other issues) may and has arisen in the past. (eg Dismissal of James Comey to me is indicative of what's been happening here). --MASEM (t) 20:28, 25 September 2017 (UTC)

Oh, I agree notability is one factor here. It is not the primary danger in my mind, though. The encyclopedia is not harmed by keeping a non-notable event around for a few months before it gets sent to AfD again and merged or deleted. The encyclopedia and real people are harmed when we can't make up our mind on BLP issues and problematic statements under BLP policy keep getting inserted or we have articles created like the first Pissgate article (which was deleted. I'm also not sure if we should even have that redirect, but thats another matter). I think we need to acknowledge that there are several factors in play here, notability being one of them, but it is not the factor that has the potential to do the most damage. TonyBallioni (talk) 20:33, 25 September 2017 (UTC)

Agreed on all points. --MASEM (t) 20:40, 25 September 2017 (UTC)

I see two problems: first, we act as if we were in competition with other sources, so there is something of a "scoop" mentality about getting the story in quickly even if it is wrong. That isn't historically how encyclopedias functioned, and I would almost suggest that we should specifically forbid writing about things so soon after the event. But second, too many people simply do not understand why news stories are published. We have to spend way too much time prying out slow-news-day and click-bait fluff, even when the article in question is years old any there's abundant evidence that nobody ever cared after that. Mangoe (talk) 22:10, 2 October 2017 (UTC)

• EEng, I know you had a list of people who had asked to be notified if there was going to be a discussion about enforcing NOTNEWS. I'm notifying you since you probably know where the conversation is. TonyBallioni (talk) 18:46, 25 September 2017 (UTC)

The ping-me list is at User_talk:EEng#Shaping_a_proposal. I'm not sure I can commit to this discussion at this time. I will say I liked someone's suggestion that if there's going to be an embargo of some kind on breaking news, the right form for it might be that a breaking-news topic shouldn't get its own standalone article for X days or weeks i.e. breaking-news content should, at first, be new content in some appropriate existing article, and only after X days/weeks should it be considered for its own article. The beauty of this is that there will typically be many eyes on the existing article, who will help keep UNDUE, BLP, and similar problems under control.Any after the X waiting period, notability for a standalone article will be much clearer. EEng 23:33, 25 September 2017 (UTC)

• I've not listed the discussion in Template:CENT yet; I wonder how the discussion would normally proceed without listing it in CENT or notifying others about this discussion. BTW, before voting, let's look at Wikipedia:WikiProject Deletion sorting/Events/archive and Wikipedia:WikiProject Deletion sorting/Sports/archive. Shall we? Most listed articles are deleted for plainly violating either notability guidelines and/or the "Wikipedia is not a newspaper" policy. Ooh... the Trump orb article is deleted... um, re-created as a redirect, actually. So are other articles. --George Ho (talk) 20:27, 25 September 2017 (UTC)
• Question - Didn't we just go through this shit? Beyond My Ken (talk) 21:29, 25 September 2017 (UTC)

• Yes we did. Coretheapple (talk) 21:39, 25 September 2017 (UTC)

• No we didn't. It is a very different question, about exactly how should NOT#NEWS be taken, not a new principle for NOT#NEWS. As the closure of the discussion put it, there is a question of exactly what NOT#NEWS means nowadays. --MASEM (t) 22:00, 25 September 2017 (UTC)

• OK, let's see how different this one becomes. Coretheapple (talk) 22:06, 25 September 2017 (UTC)

• Sort of. This conversation about our encyclopaedic treatment of breaking events was simmering below and at the surface of the RfC and surrounding discussions. Masem identified the issue three weeks ago, during the proposal of this straw poll: Whether [the RfC] closes as failed or no consensus… the disconnect related to the core NOT#NEWS policy is still evident and should be addressed…. I would characterise Masem as passionate about NOTNEWS, and in implementing performing the RfC closure I felt certain this proposed poll would go forward; perhaps that expectation affected my framing of the close. Apologies to community members sick of this topic. It's... historically contentious. Snuge purveyor (talk) 08:30, 26 September 2017 (UTC)

• One commonality with the recently concluded discussion is that the wording is problematic. Option 2 is that NOTNEWS "should be more strongly enforced" or that "En.wiki should have significantly less coverage of current events." To do that would seem to require not enforcement of the existing rules but change in the policy. So that option would appear to incorporate two separate outcomes. One could argue that NOTNEWS is already strictly enforced. Coretheapple (talk) 12:55, 26 September 2017 (UTC)

• Which is the whole point of this straw poll. the RFC even before it was closed (though the close re-affirmed what I saw) gave no clear indicator how the majority of editors felt about NOT#NEWS, with both directions having been presented. This is meant to simply determine if and by how much of a change in policy is needed, but makes no attempt to say what that could be because its impossible to know what has a likely chance of gaining consensus. --MASEM (t) 13:29, 26 September 2017 (UTC)

• But that's precisely my point. Sure some folks are going to be explicit. But when people stop by and says "yeah I'm for option 2" without saying what they want to happen, how is that to be interpreted? Option 2 provides two dramatically different outcomes - enforcement of the existing rules or changing them. If people are silent on these alternate outcomes, how do you read their minds? Coretheapple (talk) 14:13, 26 September 2017 (UTC)

• You can't, but the whole point of a straw poll is to get a quick idea of an opinion, and determine how strong the various opinions to see what type of action might be appropriate to suggest. If one option "wins" by a landfall, then there's clearly a means to consider new policy or the like towards that. If instead it just "wins" by a few percentage, I would say a massive policy change is out of the question. I do point out in the intro that results could range from adjusting existing P&G to creating new policy to eliminating some policies. --MASEM (t) 14:18, 26 September 2017 (UTC)

@Power~enwiki: The problem with Wikinews is a catch-22. It requires editors to use to fill it with news stories, and then there needs to be awareness that it exists so that people coming to WMF projects for news coverage use that instead. If no one knows about it, it's hard to draw editors to use it. If editors don't use it, it gets no visibility and people don't know about it. It's not dead-dead, articles are still created for it, but its very clear that editors and readers presently believe en.wiki is the place to find news articles, and Wikinews is basically a ghost town. --MASEM (t) 13:34, 26 September 2017 (UTC)

Oftentimes I see an AfD on a recently created article on a recent event (say, a terrorist attack) with people saying things to the effect "keep, meets GNG" and "delete, NOTNEWS". Typically these end up as "keep", I am not sure if there is a general feeling on how such cases should be treated. Jo-Jo Eumerus (talk, contributions) 14:41, 27 September 2017 (UTC)

Jo-Jo Eumerus, Masem - is there a way to know how much time a reader spends at an article or do our stats provide only clicks? There's also no way to know why page views increase or what information our readers are hoping to find. I'm of the mind that a news story breaks, and readers come to WP for validation based on NPOV. If all we're doing is reporting allegations cited to the NYTimes, WaPo, etc. then we're turning our project into another bait/click news source. ^{Atsme📞📧} 12:43, 2 November 2017 (UTC)

@Atsme: One rough way to count how interesting people find an article is to compare the amount of hits other pages linked from said article get. That works only if the article is getting a lot of attention - if it's uninteresting people won't click on its links and then the other pages don't see many more clicks, if it is interesting the other pages will receive a lot more. Jo-Jo Eumerus (talk, contributions) 16:06, 2 November 2017 (UTC)

Excuse my lack of knowledge in this area but other than manually pulling up page stats for each article in What links here (via the tool in the sidebar menu), is there an auto-calculation somewhere? I looked at Page information, then Page view statistics - does Wikilink checker contribute anything? ^{Atsme📞📧} 19:21, 2 November 2017 (UTC)

2017 Las Vegas Strip shooting and List of terrorist incidents in October 2017(and its kindred) are examples of the problems we have with editors seeing something in the media and adding it immediately. Every rumour gets added as soon as it hits the web, no matter how dodgy the source. Doug Weller talk 15:45, 2 October 2017 (UTC)

Are RS and BLP insufficient to deal with this problem? If they are not being sufficiently enforced, the problem won't be solved by adding another policy that won't be enforced. Gamaliel (talk) 17:23, 2 October 2017 (UTC)

Technically between the existing NOT#NEWS, RS, and BLP, these should be kept in check (that's the whole point of WP:RECENTISM, but as sometimes breaking news articles get swayed on being "popularity contests" in the number of voices supporting something outweigh those arguing for established policy, to which part of that is something I'd attributed to a lax treatment of NOT#NEWS by long-time editors, and admins. There are a lot of other factors though that contribute to this too, it's not just a NOT#NEWS issue, but better adherence to NOT#NEWS would help alot. --MASEM (t) 17:44, 2 October 2017 (UTC)

It's also the speed at which these articles are edited. I haven't looked but I know that the right wing media had a different, innocent (but liberal) subject named as the shooter and his name was the main name on Google for a few hours. I hope it didn't get into any of our articles. These articles also attract a lot of new editors who don't have a clue and are quite happy to argue. Doug Weller talk 17:50, 2 October 2017 (UTC)

@MelanieN: for a while yesterday Facebook and Google were presenting a conspiracy theory naming someone uninvolved as the shooter. I haven't checked to see if this poor guy's name ever go into our article (but I will), but such instant responses to breaking stories, particularly when often done by new editors who don't know about reliable sources or care at times, can be damaging. Doug Weller talk 08:00, 3 October 2017 (UTC)

@Doug Weller: Please do check; I'd like to know. I will be very surprised if our systems failed that badly. In the time I have been involved with the article, we have been concerned with whether and how to report that false news incident as false news; it seems finally to have found a home under "Social media". My hunch is that if anyone had inserted that story at the time, it would have been removed almost instantly as poorly sourced. --MelanieN (talk) 14:29, 3 October 2017 (UTC)

@MelanieN: I used Wikiblame and went back through 1500 edits, but it looks as though it wasn't added. If it had been added, I wouldn't be surprised if a copy of that version showed up somewhere else. Doug Weller talk 14:34, 3 October 2017 (UTC)

Thanks for checking. I have actually been very impressed with what a good job we do on breaking news stories like this. To me it proves again the saying, "the trouble with Wikipedia is that it only works in practice. In theory, it can never work." --MelanieN (talk) 14:45, 3 October 2017 (UTC)

P.S. I looked all through the talk page archives and can't find that anyone ever even proposed adding that false report. There were a few other wild conspiracy theories proposed at the talk page, but they were quickly shut down and never got into the article. The only false thing that went into the article is that some people, before the article was protected, inserted "Muslim" or something similar to describe the shooter. Removed almost instantly. We have strong systems. --MelanieN (talk) 14:54, 3 October 2017 (UTC)

User:Doug Weller, the first item in the list you cite is the Marseille stabbing. In fact Fr police are at present very equivocal as to whether this incident is terrorist or not French interior minister Gérard Collomb said: “It might be a terrorist act, but at this point we can’t say so with certainty”. Of course no such uncertainty is mentioned in 'our' list, and the likelihood of it being even reported widely if the story has an anti-climatic end (if, for example it was simply a conventional murder), so any update probably won't be incorporated in our article or list unless it is 'dramatic'. I believe this identifies the real danger of 'news' articles, which are the 'peripheral stories' and list entries with too few watchers, rather than the big events like 'Las Vegas'. A particularly silly example is recorded here, where WP on two seperate lists recorded a terrorist plot that simply never existed. Failing to 'update' is the norm, rather than the exception in this topic area, with dozens of articles that I know of ending "police arrested X suspects", (but how many were ever convicted of anything?) . I don't know what we do about it however. Pincrete (talk) 13:06, 8 October 2017 (UTC)

Hell, that was User:Gianluigi02 that I recently blocked for 72 hours for similar edits. Doug Weller talk 13:31, 8 October 2017 (UTC)

Another editor put it into another list, where it stayed even longer (20-ish months) and many other editors cheerfully reinstated (and sometimes embellished) it on the first list, claiming it to be "well-sourced". The list article was so full of SYNTH and over-statement that even I did not notice it for a long time. It was a NOTNEWS argument that finally killed it. Pincrete (talk) 14:43, 8 October 2017 (UTC)

Some points to reply to in regards to @Gamaliel and @Fuzheado in their !votes about forum shopping and Wikinews. First, as forum shopping, this is not the question that was asked at WT:NOT about NOT#NEWS. That was a very specific proposal about how much commentary should be in news articles, which during the course of it, it became clear the bigger "issue" is how NOT#NEWS is to be treated, period. That was a point made in the closure of that previous discussion , so it is not forum shopping because this is asking a very different, and much larger question about our relationship to breaking news, in the first place. Second, the Wikinews issue, I fully agree that Wikinews is dead, the problem is, there was nothing in place that designed en.wiki as the defacto place that news would go with Wikinews being dead. There's nothing that says WMF needs a sister site that handles news. Maybe it might seem to be practice to have news on WP, but that's a change from NOT#NEWS that never appeared to have been processed through by consensus. The point here is thus to establish if that practice does have any type of consensus, and update policies and guidelines as needed. If the practice is fine, then that needs to be written into policies and guidelines; if not, then we need to fix how it is being practiced. --MASEM (t) 19:57, 2 October 2017 (UTC)

@Masem and Gamaliel: - Regarding this: "there was nothing in place that designed en.wiki as the defacto place that news would go with Wikinews being dead." Er, you don't need a formal pact, agreement or interface on where one starts and one begins. In fact, Wikipedia existed for years before Wikinews ever came to the scene, and there was never anything formal about Wikinews does X to the exclusion of Y on Wikipedia, nor should there be. Regarding what you said, "that's a change from NOT#NEWS that never appeared to have been processed through by consensus." The practice is the consensus! It has been this way for years and years, and only now are you surfacing this as some sort of illegitimate mode of operation that needs an overhaul when there is no real desire to do so. Frankly, it's puzzling and borderline patronizing when we as a community have done very well with creating articles as news breaks and serve the public interest. Forget the old notions of "this bin is news" and "this bin in history" and never the two shall be comingled. The great thing about Wikipedia is that it blends these two seamlessly in a way we've never done before, so why make that harsh and artificial distinction? Nobody puts Wikipedia in a corner! -- Fuzheado | Talk 20:52, 2 October 2017 (UTC)

Just because it's practice doesn't make it a community consensus, particularly if the change is slow and not immediately obvious. I agree that we probably have been running current event articles for several years that would seem to go against the rub of NOT#NEWS, but this wasn't an issue until events of the last couple of years, principally driven by the US election, which has created a unique political and ideological battleground in the world as a whole that never had been present prior to this, and eventually filters down into en.wiki. The "practice" of rapidly pushing current news, while seemingly okay before, has created an endless stream of behavioral problems, much less issues with how news intersects with key content policies, because of what current news typically ends up being. That's not sustainable, unless we either establish the practice as having consensus, or adjusting our policies and guideline to reflect which way the community would want to see this. There is no question that some news today can eventually become an encyclopedic topic tomorrow, and thus it makes no sense to wholly chase off news coverage on WP. But to what level we cover breaking news and migrate that into an encyclopedic topic is a question that really needs to be answered in this current political and ideological environment. --MASEM (t) 21:59, 2 October 2017 (UTC)

• I think the most useful thing would be a straw poll or survey trying to identify what -- if any - kinds of content should be excluded under NOTNEWS. I think a lot of people will say "nothing -- if there is an RS it comes into WP". I am curious if we can get consensus around anything. If we can, then NOTNEWS should be narrowed to that. If we cannot find anything then NOTNEWS should be removed from NOT. But the first step is to try to get people to identify what they think NOTNEWS does exclude. Nobody replied at my query at NOT; how do you feel about trying that here Masem? Jytdog (talk) 05:28, 3 October 2017 (UTC)

  @Jytdog: We can get specific consensus for certain limitations; this particular change simply hasn't been made to WP:NOTNEWS. --Izno (talk) 12:39, 3 October 2017 (UTC)

You have more confidence than I do that we will find anything left of this policy in what editors actually do. There is a very strong strain of "it is in a source so we include it" out there. Jytdog (talk) 12:42, 3 October 2017 (UTC)

I totally agree with that statement, and now wondering if the changes need to occur in Notability first. POV or possibly even agendas/advocacy gets in the way of independent critical thinking that is compliant with NPOV. Encyclopedic value (EV) is easily measured by WP:FP but how do we determine an article's EV for inclusion? The simple answer is the number of times RS write about it. Therein a big part of the problem lies. ^{Atsme📞📧} 12:50, 2 November 2017 (UTC)

Neither Wikipedia nor Wikinews are set up to work well with current events and breaking news stories. Here's why:

1. Immediacy. I used to contribute at WikiNews but found it immensely frustrating, because the whole thing is so very slow. You can write a couple of unreferenced sentences on Wikipedia, tag it as a stub, and publish it immediately. Straight away it's visible to readers, and you can continue working on it - making it longer, adding sources and images etc, as can other editors. This is the way other news outlets work - they publish a "breaking news" article that's usually just a sentence or two, then add content as more information becomes available. But not Wikinews. On Wikinews there's no concept of breaking news, of the importance of publishing first and editing later. Every single Wikinews article has to be reviewed by somebody else before it's published. With so few users on that project, it can be several days before your "breaking" news article is even looked at. News by definition has to be "new". It's crazy that we can publish something to Wikipedia with immediate effect but not to our newspaper sister project.
2. Original research is allowed and very much encouraged on Wikinews, but obviously not on Wikipedia (and rightly so). To work as a news source, original research is important. The eyewitness report, the first-hand account, the reporter on the ground, the direct interview - these often make for the best news articles but they have no place in an encyclopaedia. This is something Wikinews gets right and that Wikipedia would fail at if the decision was made to replace Wikinews with Wikipedia's current events section.
3. Editorials and opinion pieces don't stand a chance with the NPOV policies that exist on both sites. NPOV is vital for every encyclopaedia article and is rightly one of the central pillars of Wikipedia policy. We want Wikimedia sites to be neutral and welcoming to all, so we don't want our newspaper project to have a strong overall political leaning as many regular newspapers do. But opinion pieces and reporter blogs are now an important feature of just about every news source out there, and the key is to allow points of view to be represented in them provided they are balanced (i.e. one piece "for", another "against", resulting in overall balance) and clearly marked as an opinion piece and not a news article.
4. Edit conflicts. The Wikimedia platform is great for collaboration over a long time, but bearing in mind the importance of immediacy mentioned above, big breaking news stories really need to allow multiple editors to work on the article in real time, in the same way as a shared Google Drive document/spreadsheet. That's a massive technical hurdle to overcome, and currently some way off. (See mw:Parser_2011/Real-time_collaboration and mw:Extension:TogetherJS)

For me, the biggest barrier by far is that first one. WikiNews needs to change the way it works dramatically and fundamentally if it is to succeed. But if Wikinews does the job it's meant to do, we can then look at strengthening the NOT:NEWS policy here on Wikipedia. Meanwhile we have a mess on our hands and I don't think any of the proposals in this RfC will remedy that. WaggersTALK 14:13, 4 October 2017 (UTC)

• My 2¢ Based on my admittedly anecdotal experiences at AfD and elsewhere I'd say that NOTNEWS is so widely ignored that it is about a half step away from being WP:HISTORICAL. I don't like it. Point in fact I am appalled by it. But it is what it is. Maybe it's time to just admit that it's on life support and talk about pulling the plug. -Ad Orientem (talk) 21:59, 11 October 2017 (UTC)
  • That's part of why I opted for this straw poll to see if that was a viable option. The current stances suggest otherwise (edging to make NOT#NEWS enforcement stronger presently), meaning we should be looking to find ways to fix issues with how AFD handles new news articles without being bitey to newcomers, among other things. A lot of AFDs I see on news events comes down to editors thinking "lots of immediate coverage" == "notable topic", despite both NOT#NEWS and WP:N saying otherwise, and AFDs are unfortunately easy to swing by sheer numbers of !votes. --MASEM (t) 22:20, 11 October 2017 (UTC)
    • The !votes so far are as close to a lack of consensus as I have ever seen. The far more lopsided sentiments in the NOT discussion were termed "no consensus" long before the close, so I find your "edging" characterization interesting in light of that. Coretheapple (talk) 23:06, 11 October 2017 (UTC)
      • Might have missed some, but taking out duplicates and second choices it appears to be a dead heat, 38 in favor of strengthening, 38 keeping same or weakening, at the present time. Figureofnine (talk • contribs) 17:41, 14 October 2017 (UTC)

Idea

• Comment. Its pretty obvious that the issue is not with NOTNEWS, but with the total failure of the Wikinews project to attract a sustainable editor base. Rather than whatever you hope to achieve here in this RfC, you should consider the bigger picture. For example a simple change to the Wikimedia software to add a namespace called News: could deal with the problem and revitalise Wikinews at once, some news items worthy of long term inclusion in the enclyopedia would be simply moved to mainspace via a method similar to AfC, news items would exist on wikipedia as a kind of draft, but still be indexable and accessible. Simultaneously dealing with the NOTNEWS and Wikinews issues in one action. To avoid issues with removing Wikinews, all news articles would be editable via Wikinews (which would still exist as a portal) and on Wikipedia, where we would no longer have to fret over which news stories will be relevant later on. This whole system is more in line with Wikipedias 'lagging behind' verifiability policy, and avoids splitting editors into unsustainable over-localised communities. Α Guy into Books™ § (Message) -  21:30, 25 September 2017 (UTC)

Aguyintobooks, the article creation has become a total mess as is. Right now, we have 1500+ articles pending review via AfC. A bunch of articles, including some articles about current events, get deleted from Wikipedia because they fail to meet encyclopedic standards. Currently, we have WP:ACTRIAL running for six months. Merging Wikinews into Wikipedia would make matters worse. We would expect more articles created and then deleted for failing to meet the standards. Also, what about 20+ other Wikinews language sites? This year, Dutch Wikinews is reopened. --George Ho (talk) 00:59, 26 September 2017 (UTC)

No. Replicating the AfC model is not the way forward. The future of how we handle new content in in limbo pending ACTRIAL/the followup RfC, and the current policy fights over the draft space are popping up all over my watchlist, and I never seek out doing anything with the draft space. Making current events AfC/Drafts 2.0 is a battleground waiting to happen. TonyBallioni (talk) 01:10, 26 September 2017 (UTC)

I also thought of this as a possible solution, but yeah there are too many problems with similar processes currently for it to be feasible. Maybe if we ever get AfC and drafts and all that stuff figured out, this could be a good idea. ansh666 09:00, 26 September 2017 (UTC)

@Aguyintobooks: The problem here and at Wikinews is the same problem: there seem to be a lot of people who want to wave around policies to try to interfere with free-licensed work about news. If you do work on Wikinews, it is very likely to be thrown away - that's why no one does. Even if successful, it will be a locked snapshot, not a comprehensive review of a phenomenon. Now I don't know the motivation of any specific person, but I think on average we should look at the myriad legal embattlements and legislative setbacks of news aggregators to see that the ever-shrinking media industry might be exerting some push-back against its competitors. I mean, if the encyclopedias had done the same back in 2001, Britannica would be making as much money as Microsoft! But on Wikipedia there is a never-ending stream of editors from other topics who just wade in and start editing without regard that we're not supposed to be able to put current events in context. This raw ignorance is our foremost strength. Wnt (talk) 18:47, 27 September 2017 (UTC)

• The statement "the total failure of the Wikinews project to attract a sustainable editor base..." is entirely true. The reason for that is that the entrenched editor base is mostly lazy and opposed to helping new users integrate their contributions in a useful manner; rather they see it as their duty to eradicate all new user contribitions that don't meet the extremely strict standards that have taken years of experience to develop. It's the expectation that all brand new Wikipedia users are born fully formed like Athena from the head of Zeus, and that any new contribution which is not already FA-quality is to be deleted within seconds of its creation with little to no explanation of the problem, and absolutely no attempt to improve such substandard contributions. What kills new user retention is primarily a culture that treats them all as enemies until they have proven themselves not to be. --Jayron32 14:11, 26 September 2017 (UTC)

  Mea culpa. Misunderstood the OP's original point. My response makes no sense. Carry on. --Jayron32 15:09, 26 September 2017 (UTC)

Your point is perfectly valid though, having ~2250 pages of policy is one thing, expecting new users to understand it all is another.  --- Α Guy Into Books™ § (Message) -  21:27, 26 September 2017 (UTC)

• Truer words were never spoken. I have been here for 3 years, and I feel as though I have just begun to get a grip on the morass of policy in the handful of areas where I most commonly edit. To me, editing feels like a deadly video game were partisan gangs try to kill you as you wander through an uncharted swamp without a compass trying to avoid the arcane booby-traps that editors set to get you banned.E.M.Gregory (talk) 21:38, 26 September 2017 (UTC)

  Large systems always grow in procedure as the numbers grow. At some point communication breaks down and a policy is made to hold the signal. Jo-Jo Eumerus (talk, contributions) 21:58, 26 September 2017 (UTC)

• I think E.M.Gregory's point in his !vote about current events articles being an entry point for new editors is a good one. People have an interest in current events, readers like them, and they add value. A win-win all around. Coretheapple (talk) 22:30, 26 September 2017 (UTC)
  • We definitely do not want to be too restrictive on new editors, and we want to encourage them to participate, but at the same time, current event articles can be touchy, and already a large subset of them fall under the post-1923 US politics Arbcom DS, where it's not the best for a novice to be making unsure edits compared to other pages. There's definitely a balance needed. --MASEM (t) 23:13, 26 September 2017 (UTC)
    • You mean, post-1932, right? George Ho (talk) 23:14, 26 September 2017 (UTC)

Realistically all events were current at some point, and there are going to be more people interested in an event at the time it happens than some years afterwards, but a balance has to be struck somewhere, especially for events where the available information changes rapidly.  --- Α Guy Into Books™ § (Message) -  23:17, 26 September 2017 (UTC)

Everything was current at one point or another but the online media quickly shares stories saying essentially the same thing; you never had that in 1932. Editors need to understand that journalists report one thing, and we, who are not journalists (some like to believe they are, however), have a different criteria for our content. If we were more patient, most current events would reveal their importance in a few weeks and speculation would be replaced by verified facts. Perhaps we can move current events to a draft space for a week or two and then access if it established a historic or societal importance after that time has passed.TheGracefulSlick (talk) 00:32, 27 September 2017 (UTC)

"most current events would reveal their importance in a few weeks" A few weeks? I think you mean a few years. Secondary source analysis (see WP:ANALYSIS) has to take place well-removed from the event. We shouldn't be writing about any presidential administration until they're a dozen years out of office. I could argue we shouldn't have any entries about living people, at all. It's still too early to write about the Gulf War, let alone the Invasion of Iraq in 2003. But of course, Wikipedia exists as a playground for wannabe writers to shout out their narrative. Wikipedia's crass inclusive approach to keep the donations coming in results in shoddy entries written by fanboys and cranks. Had we emphasized article quality over article quantity we might have built our gamification around writing responsible entries rather than the vomiting of words into multiple overlapping pages. Chris Troutman (talk) 01:09, 27 September 2017 (UTC)

Chris troutman I actually agree with you more than you probably realize. In fact, I really need your perspective for some of the articles I nominate for deletion! I was trying to bring about some sort of middle ground: no consensus will exist, instructing us to wait years for notability. Many editors like putting their "I'm a journalist" caps on and writing an often inaccurate load of drivel we are forced to call an "encyclopedic article". Unless more editors like you participate at AfD, I doubt we can initiate a serious movement to rid Wikipedia of news.TheGracefulSlick (talk) 02:15, 27 September 2017 (UTC)

@TheGracefulSlick: I'm your huckleberry, but I've hurt my AfD record by tilting at these windmills to prevent Wikipedia from being a free-for-all. I recognize Wikipedia isn't a serious endeavor, despite my desire for it to be that. Chris Troutman (talk) 02:26, 27 September 2017 (UTC)

Whether or not our articles are "inaccurate loads of drivel" (I think not), at least we still have copy editors and can spell, which is more than can be said for most of the professional media outlets that people have to resort to for far less comprehensive, partisan, and hard-to-find reviews of news events if they can't find them on Wikipedia. Wnt (talk) 10:44, 29 September 2017 (UTC)

Realistically whether our news articles are relevant depends greatly on the quality of our editor base, there is the inherent problem that news is closer to original research and harder to verify than an encyclopedic topic, and the issues presented by the accepted facts changing is always an issue. and the obvious issue that wikinews is always behind everyone else (as it is based on other news, which for news is really a disadvantage. Not a disadvantage faced by wikipedia. The strongest core concept of wikinews is that is a neutral aggregate of content, A wikinews article should always be more complete than any other single piece of coverage. A den jentyl ettien avel dysklyver 11:32, 29 September 2017 (UTC)

• I want to emphasize the points made above by User:Carwil and User:Feminist. Feminist is correct to flag the negative impact on the project viscous attacks on new editors get socked with at AfDs on big news stories. And Carwil is surely correct that energy is better put into improving articles at the moment when they are drawing attention, to which I want to add that I, personally, go to WP as an efficient way to get up to speed on a breaking political or culture wars firestorm. I expect the article to exist. And it often leads me to go take a moment to expand one of our many old, sad, neglected articles on a neighborhood, institution, think tank, publication, or individual involved in the breaking news event.E.M.Gregory (talk) 18:24, 29 September 2017 (UTC)
  • Excellent points. postdlf (talk) 22:39, 5 October 2017 (UTC)

Some observations

I'm going to note a few common themes that I'm seeing in the !votes here as they come - I'm not suggesting they are immediately actionable, that they have consensus, or the like, but they open up some reason and points of discussion why we're at this impasse on NOT#NEWS and how to proceed on that. --MASEM (t) 15:02, 29 September 2017 (UTC)

1. Handling of current events articles at AFD is an issue - both from those there !voting "Keep per GNG" (asking larger questions about news reports, bursts of news, and notability per NEVENT/GNG) and those !voting "Delete per NOT#NEWS" (more reflecting of how strong NOT#NEWS should be enforced). There should be a middle ground recognizing that DEADLINE is also a factor in addition to NOT#NEWS. --MASEM (t) 15:02, 29 September 2017 (UTC)

I see no such common theme at present. Coretheapple (talk) 18:46, 29 September 2017 (UTC)

Concur with Coretheapple; no consensus has appeared. Moreover, the problem with WP:DEADLINE is the reality that creating articles when a significant event is breaking news is among the few proven techniques to overcome our endemic shortage of editors, because when an EVENT is notable enough to support an article, many editors show up and usually create pretty solid articles before the news cycle ends. There is all the time in the world to delete, but the existence of fingers willing to build the article evaporates rapidly.E.M.Gregory (talk) 19:40, 29 September 2017 (UTC)

I question whether 'breaking news' articles actually recruit new editors. Certainly they attract IP's and a few 'newbies' (some of both are quick learners and great to have around, and some are huge liabilities) to edit on that particular article, but is there any reason to believe that news articles actually recruit long term editors? This has not been my experience. Pincrete (talk) 11:01, 1 October 2017 (UTC)

Agreed, but just to elaborate a little, the comments here should speak for themselves and editors should not be providing an ongoing play-by-play that purports to summarize the positions of multiple editors at any given point in time. Even if so far there was an actual consensus or overwhelming view on a particular subject,, that would have to be viewed in conjunction with whatever else is said. Let's not fragment and tilt the discussion, please. Coretheapple (talk) 20:24, 29 September 2017 (UTC)

My only point here is that regardless of the straw poll, there is a valid concern of problems of how NOT#NEWS is handled (for or against) at AFD on recent news articles. I can't tell you how that has to be fixed, yet, but the AFD angle (whether we are talking retention of an article or deletion) is an issue of concern. --MASEM (t) 18:01, 2 October 2017 (UTC)

News articles on current events are primary sources, and primary sources have little weight in a notability (AFD) discussion. If the only reason to keep the article is 'its been in the news recently' then it lacks notability and so should be deleted. Only in death does duty end (talk) 12:06, 3 October 2017 (UTC)

I think that there is a certain consensus for a stricter application of NOTNEWS as it applies to BLP violations. RileyBugz^会話_投稿記録 19:07, 30 September 2017 (UTC)

Seems more logical to apply BLP to BLP violations. Figureofnine (talk • contribs) 16:04, 2 October 2017 (UTC)

There are frequently times where good RSes do publish things that we would normally consider BLP violations, like the rush to name suspects. What happens far too often is editors will see that name in good RSes, and believe it is appropriate to add right away to the articles, as they don't see it as a BLP violation (because RSes back the naming). But for us, that generally is the case until some time has passed to know how much importance the suspect's name is to the situation, as per BLP. BLP is not 100% consistent which is where situations like this come up. --MASEM (t) 18:01, 2 October 2017 (UTC)

Yes, it's terrible how the media refers to [name redacted] as the shooter in the Las Vegas massacre. Figureofnine (talk • contribs) 23:39, 2 October 2017 (UTC)

That's not where the problem arises. I distinctly remember during Sandy Hook Elementary School shooting that in the first few hours, the name of the brother of the actual shooter was named as the shooter in several RSes, only because his ID was on the shooter's body. Obviously it all got sorted out in the end, but if we had included his name at the time, that would have been a major BLP problem. That's an example of a situation with BLP is at odds with massive coverage by RS. Even with the LV shooting, I know several of the early articles this morning named a possible accomplice to the shootings, but that was quickly ruled out by police. Properly, our article does not mention this person at all despite that RSes still mentioning the name. Furthermore, and this is more a sign of the times, but there were tons of false stories that floated around on major RSes, some intentionally false. (I could also point out the situation with Tom Petty today as yet another example of this). BLP is supposed to prevent issues with that, and in the long-term it does, but in the short term there has to be more awareness of why we have NOT#NEWS towards this end to help protect BLP from misinformation. --MASEM (t) 23:57, 2 October 2017 (UTC)

I just don't see the need for yet another layer of rules, based upon the supposition that RSs may not "get it right" now but may "get it right" down the road. That would put articles in a straitjacket, and would be subject to all kinds of abuse and conflict. Our BLP rules are already strict and more than sufficient. What you describe as a "problem" is simply a fact of life, not just for current events articles but all articles, even articles on ancient subjects, as the RS sources shift and change in their perspective. All we do is reflect the RS sources. That does not create a BLP issue a all, but rather is a mirror to the reality of the sourcing. Figureofnine (talk • contribs) 00:32, 3 October 2017 (UTC)

It's not a "fact of life" that we needed (or for that matter still need) 240 posts so far in the Tom Petty article. It's only a fact of WP, apparently, that people cannot be trusted to get caught up in the what will prove to be a passing and unimportant episode of misinformation. Mangoe (talk) 02:01, 3 October 2017 (UTC)

Another datapoint showing that BLP is not sufficient to deal with NOT#NEWS violations: Harvey Weinstein sexual misconduct allegations - an article based only on that allegations were made and some of those aftereffects on Weinstein, but going into far too much detail for what is yet to be even a legal charge against him. --MASEM (t) 13:43, 15 October 2017 (UTC)

Yet another datapoint is how swiftly your AfD of the article was closed as a speedy keep, without a single supporting !vote. You seem to have a narrow view of NOTNEWS that is extreme and out of step with the community. Figureofnine (talk • contribs) 16:22, 15 October 2017 (UTC)

I feel the need for written clarification of BLP as it applies to current events. Many unproductive discussions and edit wars could be avoided if we had something that explicitly stated "we do not refer to something as a murder/homicide/assault/attack until there is a conviction." This may already be covered by the existing policy, but it should be written in a way that can't easily be misinterpreted or misrepresented. –dlthewave ☎ 22:53, 2 October 2017 (UTC)

• Unfortunately, none of this is new. for a non-recent example of an article where NOTNEWS was totally ignored... see University of Florida Taser incident (of "Don't tase me, bro" fame.) Worth reading the discussions that took place about why that article should be kept. 17:54, 2 October 2017 (UTC)

• There is a lot of inappropriate assumption that media are necessarily reliable as a class, when the reality is that in the extreme short-term, they really aren't that reliable. It is typical of breaking news stories that initial reports aren't reliable: they're usually somewhat right, but they are often revised more or less drastically in light of later reports. I see no reason why something calling itself an encyclopedia should be chasing this. Reliability of accounts is something that is achieved over the long term, when the matter has been sifted through. Quick response media really cannot be taken to be that reliable until others judge them so, and that takes retrospection and therefore time. Mangoe (talk) 20:40, 3 October 2017 (UTC)

• I'd suggest that a more important need, one that no one has addressed, is to update "news" articles after the initial hubub has died down and the pageviews and editor interest has ebbed. That is an issue not just for articles on recent events but for all kinds of articles. "Orphaned" and neglected articles, sometimes bearing maintenance tags for years, are a serious problem in the project. Coretheapple (talk) 14:05, 6 October 2017 (UTC)
  • It is a serious issue, which is why a possible solution is to create a space that is on en.wiki and comes up in search results so that current news is there, and excepted to follow all content policies, but serves as a means to incubate news content such that if it doesn't turn out notable once the initial coverage has died down, it can be deleted, merged, or otherwise placed in context of something else. (Obviously notable stories can be brought into mainspace without question). It's like a Draft: space, but it needs to be more integrated with mainspace, and should have more formal processes to remove content that hasn't yet been transitioned to mainspace so they don't linger. Whether this has to be an explicit "News:" space, or management of article tags, I don't know, but it would meet both sides of the matter. (And there's a lot of cavaets, this by no means a formal proposal for this). --MASEM (t) 14:24, 6 October 2017 (UTC)
    • No, that would be like trying to light a campfire with napalm. A simple problem requiring a simple solution: greater energy expended after an article has lost its high visibility status. Not just news articles but, for instance, articles on corporations that have undergone scandal. BP comes to mind. Coretheapple (talk) 16:38, 6 October 2017 (UTC)
      • No. Better to head off the crap to begin with - and it is crap always filled with the personal predilictions of the Wikipedia editors because there are no sources who have reflected and weighed - just the personal prejudices of Wikipedians - and it is absolutely no public service to be a news aggregator. Alanscottwalker (talk) 18:36, 6 October 2017 (UTC)
        • I'm not seeing crap, I'm seeing articles in need of updating. BP isn't crap. 2014 East Harlem gas explosion isn't crap, and neither is filled with personal predilictions. Coretheapple (talk) 21:50, 6 October 2017 (UTC)
      • Not really. Once an article has lost its high visibility status in the news, we should be reviewing it per NEVENT/GNG for notability and appropriateness. Some will clearly stay, some should be merged, and few should be deleted. That achieves the same thing of then being able to tag those that are key to gain more eyes to improve, resummarize, and work in later sources after the initial burst of news, rather than let them stagnate. New developments on existing articles are less a problem, save for far far too much proseline in many cases, since we're not questioning the basic notability of the original topic. --MASEM (t) 22:28, 6 October 2017 (UTC)
        • @Masem: Can you cite any examples of current event articles which were deleted after they were no longer current events? Coretheapple (talk) 13:30, 19 October 2017 (UTC)
          • Wikipedia:Articles for deletion/2009 Fox News – White House controversy Wikipedia:Articles for deletion/2014 Romania helicopter crash Wikipedia:Articles for deletion/2014 Norfolk helicopter crash Wikipedia:Articles for deletion/2011 India–Pakistan border incident Wikipedia:Articles for deletion/Kosovo–Serbia January 2017 train incident (merged but effectively same for the question at hand) - This is just scanning the first few pages of hits in the AFD archives. Obviously there's also some keeps and some retained by no consensus, but there are definitely deletions. --MASEM (t) 13:43, 19 October 2017 (UTC)
            • @Masem: I'm referring to articles on current events that were deleted when they were no longer current. All except the India-Pakistan one were deleted shortly after they were created, and the India-Pakistan one appears to have reappeared as 2011 India–Pakistan border skirmish. Coretheapple (talk) 14:58, 19 October 2017 (UTC)
              • Wikipedia:Articles for deletion/Power Shortage in Japan 2012, Wikipedia:Articles for deletion/2017 collapse of Route 4 bridge in Israel, Wikipedia:Articles for deletion/2014 SOCATA TBM crash (2nd nomination), Wikipedia:Articles for deletion/Nicolas Estemar stabbing spree. And that's just a portion of a list I'm scanning through.
              • I will say that it is reasonable to allow articles on current events to be created and given some time to demonstrate notability per both NEVENT and GNG (with obvious hoaxes or BLP violations speedily removed), but we should still have some checkpoint a few weeks after creation of such that these articles are either approved with presumed notability (if not sooner if it is obvious) or sent to AFD to be deleted. --MASEM (t) 15:20, 19 October 2017 (UTC)
                • I'd say overall we have a pretty good record at creating articles that last and deleting ones that don't seem very significant in retrospect. And when dubious articles are created that aren't deleted... so what? I wanted Richard Matt deleted. The community emphatically disagreed. The article remains, and I fail to see excessive harm from that, except to my ego. And no, I'm not going to nom it for deletion again, for the simple reason that in fact he has gotten so much notoriety since his demise he probably does warrant an article. Coretheapple (talk) 17:02, 19 October 2017 (UTC)
                  • The problem is that when you start reviewing some of the other AFDs on events, (and I don't have any in front of me, this is from recollection earlier today) is that there is a strong pattern of numerous !votes going "Keep, lots of international coverage" and the closer clearly following that majority despite opposing !votes that point out that bot NOT#NEWS, WP:N, and WP:NEVENT point out that a burst of coverage is not sufficient to keep a news event. In other words, its a compound problem of editors not understanding existing policy/guidelines and admins not properly evaluating !votes under NOT#NEWS concerns. And then further, when this articles are kept, and the AFD is a mere memory, no one spends the time to convert these from newspaper, on-the-spot reporting to something that is more appropriate for permanence. (The whole problem with reaction sections is one part of this). Compare Watergate scandal or Lewinsky scandal (pre-WP days) to United States diplomatic cables leak (written as the events went along). Even something like Boston Marathon bombing is still showing the training wheels it needed to build out when the event was happening, and that's an article with a lot of editing activity still. And these are the high profile news articles; it's the smaller ones that have less of an impact that are typically even worse and are frequently overlooked. There is definitely a place for allowing editors to start current events articles, but we need to have a better process to make sure that these are going to end up being quality articles at some point. There's no one solution to this, but based only on the poll, there probably needs to be something changed, though not drastically. --MASEM (t) 00:42, 20 October 2017 (UTC)
                    • "Based only on the poll." We're back to that again? It is indeed funny how the lopsided !vote in the NOTNEWS page you interpreted as "no consensus" whereas this even-steven one you claim to be a mandate for something . There is no consensus here to do anything, with half the !voters wanting less or the same enforcement of Notnews and half wanting stronger. As for all those articles that need improvement, sofixem. Coretheapple (talk) 12:55, 20 October 2017 (UTC)

Not News and Reliable Sources conflict. The strictest definition of "not news" will mean that even if there are reliable sources, inclusion should be banned because Wikipedia is not news.

I believe the solution that reliable sources is a higher priority than not news. This is because if there is something truly historic but it doesn't have reliable sources, it cannot be put into Wikipedia. However, something that has reliable sources, even if we think it is news, is more worthy.

The biggest problem is that there is no editorial board and professionally trained editor in chief to make decisions. That is the wikipedia way. AGrandeFan (talk) 20:42, 11 October 2017 (UTC)

Why is it important to have articles on breaking news?

This is, to me, the undiscussed question. From my perspective, I can see three reasons not to have such articles:

1. They create notability issues because of the implication that anything that has been published about at all is notable, which our principles have said isn't true. Getting rid of them is laborious.
2. They present accuracy issues because the real sources are unstable (and often enough unreliable) and because the tendency is for the article to freeze at the point where someone lost interest. One has to hope that someone comes back after things quiet down and potential sources have had a chance to take a longer view and sort out all the various reports (which, BTW, could on some level be taken as primary sources, when it comes to that), but often enough it doesn't happen. It's pretty common that, in the long run, The World decides the event was unimportant and doesn't get around to sorting it out beyond ignoring it.
3. They present readers with a choice: who should your read for breaking news: the news, or us? Shouldn't the answer be, "well, not us, for now"?

I see some sentiment of "well, it gets sorted out in the end." I don't think that's true, but even to the degree that it does, aren't we performing a disservice until it does? Mangoe (talk) 16:46, 12 October 2017 (UTC)

A few reasons I'd offer:

• We are instinctively drawn to "citizen journalism", which is enabled by the MediaWiki platform, the WMF, and the general polices we have. It also fits well within WP due to inter-linking and a cadre of templates and tools to help build these articles. The "citizen journalism" is more in effect in the last several years due to several factors (read: Trump) that has drawn more eyes and more potential breaking news topics.
• We have had several successful breaking news articles developed on WP without much fuss and with high quality from the start, and WMF has praised that approach in the past, validating it. However, these examples all tend to be examples of major disasters (earthquakes, international terrorist attacks, etc.) where most of the reporting is objective so editors aren't fighting or pushing specific content. However, applying this same model to other stories (eg anything dealing with the Russia interference in the US elections) tends to cause more problems. There is a place for certain types of breaking news stories, but not every breaking news story needs to be in WP the moment. Most breaking should wait until we know we're into the long-tail of the story, and thus can have a more holistic view of the event to write for WP to know if it is appropriately notable, and how to structure the article and views and opinions associated with it, as to avoid OR and POV with trying to cover from the instant start.
• Where citizen journalism was to be established by the WMF, Wikinews, has failed, but the drive to write and read breaking news articles persists. It has migrated to en.wiki based on the previous models where breaking news has worked well, but when all breaking news is reported on en.wiki, it seems to cause no end to problems. We could admit we are now WikiNews and adopt policies to reflect that, but from the current state of this straw poll, that's not a likely solution. --MASEM (t) 17:06, 12 October 2017 (UTC)

• Regarding #1: I think that the objection here is poorly framed, in that the implication that is not merely that anything published is notable, it is that anything which is published in sufficient depth in the proper sources is suitable for inclusion in Wikipedia in some manner. Requirements of sourcing are universal, and don't "go away" merely because sufficient time has not passed since the event. The fact that something happened yesterday or last year or 1,000 years ago does not change the existence or non-existence of sufficient source text. If the source text is sufficient, what more is needed?
• Regarding #2: This is an issue which is true for all sources, and for all text across Wikipedia. It isn't unique to new news. Accuracy at Wikipedia is only as good as interest, and we have thousands of articles on old subjects which are based on outdated, inaccurate, or outright false information right now. That is not restricted to new stories. It's not a good thing, mind you, but it's also not a problem unique to recent events, which means setting some artificial time limit on when a topic becomes "eligible" for Wikipedia wouldn't fix the problem.

--Jayron32 17:00, 13 October 2017 (UTC)

Then there's Stonehenge, old and forgotten, but continually in the news since the dawn of the Internet. Authorities now believe the perpetrators "ate food from Scotland". Wikipedia neither confirms nor denies these latest allegations. InedibleHulk (talk) 02:49, 23 October 2017 (UTC)

When we do it well, we do it really well. Sources of breaking news are not merely cited, they are in-line attributed "The town sheriff was reported on CNN as saying it was almost certainly the work of werewolves." Meanwhile we often find news outlets are quoting each other and rumour as fact.

All the best: Rich Farmbrough, 22:36, 16 October 2017 (UTC).

• It's hugely important to have articles on breaking news because WP is neutral, comprehensive, and not a source of clickbait. Much breaking news in the MSM is simply cut-and-paste press release come-ons with red banners and articles that say nothing. When I see a headline at a media giant's website or an aggregator site, I may click there first or not, but I will definitely go to wikipedia if the topic is anything more than gossip. Since material can always be deleted, there's no harm done when a policy-compliant article's created. μηδείς (talk) 20:35, 25 November 2017 (UTC)

Food for thought

It seems to me the point of NOTNEWS is to weed out overly detailed summaries of events. Some events can only be described by such, and the litmus test appears to be that if that's what it takes to elevate an event to Wikipedia-style coverage, it's not worthy of inclusion here. To be frank, the policy seems fine to me, but then, what do I know? I won't add it above because I feel like there's something missing here, something I don't quite have the time to wade through the discussion to see. I think NOTNEWS also transcends merely creating new articles for things, as it also dictates what we add to articles we already have. Such articles' subjects have already been vetted to be describable on a more notable, more general level where it's more about impact than merely, "This happened." What we must think of when we add something to Wikipedia, especially concerning the tense sociopolitical climate of the last few years, is whether anyone outside of our sphere would care. Would someone in Uganda care about Trump's latest gaffe? After awhile, are a certain person's gaffes even worthy of tracking, or are they simply the noise that person makes as they walk by? Especially with the rise of social media and, sigh, Twitter, meme-ifying things has reached critical mass to the point that we must ask what even makes a meme anymore. Things that trend don't always deserve to trend, and wouldn't trend again once the event in question was over. If the world has largely moved on, if the world doesn't care about the specifics, then we should move on too, and we shouldn't care either. And if we choose to cover newsworthy-but-questionably-Wikipedia-worthy things, we have to tie it into a greater whole. Understandably, anytime a President goofs, it reflects on his character, so one could make the argument that whatever seemingly boneheaded thing Trump just did deserves to be covered, even mocked, by Wikipedia. But we must also ask whether such a mistake, if it were even one to start with, reflects on his Presidential qualities. Would he be any better at his job if he were never prone to such a thing? That's difficult to answer, but now I'm rambling, so my point there is that smaller, less-notable things have to truly, and of course verifiably, be tied into a greater whole that adds to the depth of our coverage of a subject. Article length or the cumulative data of coverage by a particular WikiProject are not enough to assert such depth. Therefore, my understanding is that this policy is intended to help us trim the fat off topics, or fight harder to prove why we should care and how the fat is actually a valuable part of the cut of meat, so to speak. Zeke, the Mad Horrorist ^{(Speak quickly)} _{(Follow my trail)} 03:51, 13 October 2017 (UTC)

The litmus test is "are there independent and actually secondary sources that indicate this is notable and accurate?" The sourcing is key. The assumption "newspapers/news site are secondary" is false when it comes to breaking-news reportage, which is just regurgitation of speculation, hearsay, and unverified witness claims – it is primary sourcing.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  16:10, 6 November 2017 (UTC)

That's disagreeable on some accords, as news sources are usually written in a second-person perspective, even if the news is breaking. One if the problems with WP:NOTNEWS is that users often forget that articles about events covered mainly by news sources are usually required to be written encyclopedically anyways; there are too many remedies in place at this moment to fix most, if not all, of the problems presented with articles about current events. ToThAc (talk) 19:40, 9 November 2017 (UTC)

That comment just demonstrates the basic problem here, which is that the vast majority of Wikipedia editors seem not to understand the distinction between primary and secondary sources, which has no connection to whether a source is written in a second-person perspective. We should simply stick to the core principal that this is an encyclopedia based on secondary sources, which do not, by any definition in any introductory history text book, include breaking news reports. The problem would then solve itself. 86.17.222.157 (talk) 16:51, 24 November 2017 (UTC)

Narrowing down the poll

It seems that there might be a consensus to increase how BLP applies to recent events. Therefore, I propose a poll to see whether people would be ok with having BLP modified so that the suspects in incidents in which people were killed would not be put in to article until 3 or 4 days after the incident. If you would support this, but with some other time limit, please say so and please say what time limit. RileyBugz^会話_投稿記録 20:19, 5 October 2017 (UTC)

• Oppose. Moratoriums like this are arbitrary and impossible to enforce, and of little to no relation to the confidence we have in the validity of what reliable sources report. With some events, the facts are immediately clear and never in dispute, with others years may go by without official consensus on who did what. We should follow the sources in either case and discuss our concerns in relation to each topic. postdlf (talk) 20:31, 5 October 2017 (UTC)
• Huh? There is no consensus to do anything at this point except continue this pointless exercise. Coretheapple (talk) 21:29, 5 October 2017 (UTC)*
• Oppose. I agree that BLP should be modified but it would be best to tie it to an event such as an arrest or criminal conviction. I've seen countless discussions over whether or not we can identify a suspect who has been charged but not yet convicted. We should answer that question and apply it consistently everywhere instead of discussing it repeatedly on Talk pages. –dlthewave ☎ 22:12, 5 October 2017 (UTC)
• Huh? I second User:Coretheapple in seeing no consensus here.E.M.Gregory (talk) 23:18, 23 October 2017 (UTC)
• Yeah, there is no consensus here. Hobit (talk) 23:53, 25 October 2017 (UTC)
• Nope. Agreed with all of the above comments, including dlthewave's clarification.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  16:11, 6 November 2017 (UTC)
• Oppose Beyond My Ken (talk) 01:12, 9 November 2017 (UTC)

Summary of NOT#NEWS straw poll

With the current state of this poll at the time of this writing, there's clearly no mandate to alter policy or guidelines for the handling of recent event articles. NOT#NEWS does remain a valid policy, but it has to be metered appropriately - we shouldn't be using NOT#NEWS to bite newbies or those attempting to write on breaking news stories, but at the same time, it has strength that should be used to review such articles after time has past to frame the event and content better to be more encyclopedic, and in some cases, deleting those events that turned out to be non-events.

That said, combined with the previous RFC at WT:NOT that led to this, I think the next most immediate and appropriate step is to develop a guideline that is the equivalent of Writing about Fiction, but tailored towards writing news stories. Some of the facets of this guiieline would be:

• How to interpret the nature of sources (primary, secondary; enduring coverage versus a burst of coverage, etc.) in relationship to the GNG and NEVENT, as to determine if an event article should be created or how to handle that in deletion discussions.
• That articles on breaking events may be more proseline-ish and documenting details as the event starts, but are expected to transition to more holistic/overarching coverage of the event once the event has settled down. We do want to encourage editors to create articles on current events but also encourage those same editors to shape the article over time rather than just move on to the next current event.
• That editors should keep in mind WP:RECENTISM when determining what facts and views to include in a breaking-event article to avoid the short-term bias that can arise in the current news cycle, and that sometimes it is better to wait for dust to settle to try to figure out the opinions of the event per UNDUE/WEIGHT.

There's likely other factors that can be included in this too. None of these points would introduce new ideas or conflict with the existing P&G as written, only to provide more clarity and a type of MOS for news articles, so that newer editors that are drawn to writing about current events have some type of guide to work from. It at least addresses many points raised by those !voting options #2 and #1 above without ignoring the concerns many of the option #3 !voters raised.

There could be other steps - again, revival of Wikinews still seems to be an option on the table, but that's going to take a lot more discussion and thought. It would be best to see if providing more comprehensive guidance on writing about current events would help address concerns raised before moving onto other steps. --MASEM (t) 17:18, 15 November 2017 (UTC)

"...we shouldn't be using NOT#NEWS to bite newbies or those attempting to write on breaking news stories, but at the same time, it has strength that should be used to review such articles after time has past to frame the event and content better to be more encyclopedic, and in some cases, deleting those events that turned out to be non-events." Well said. postdlf (talk) 18:09, 15 November 2017 (UTC)

• Sorry but there is absolutely no consensus for any kind of guideline, and to be frank an effort by one of the activists in this area to write a guideline is going to be still more useless drama and time suck. Why not just drop it? Coretheapple (talk) 03:14, 22 November 2017 (UTC)

• Agree with Core. The community has come to no consensus on the application of this section of the policy, which is essential to the creation of a guideline. Figureofnine (talk • contribs) 15:34, 24 November 2017 (UTC)
  • As there is no change to the current policy of NOT#NEWS, we still at at odds. There is zero issue with creating a guideline in similar style to WP:WAF that is based on all existing policy and guidelines and without introducing anything otherwise enforcable to help new editors (a key point of this poll) to write better articles on news. The lack of such guidance (in a centralized manner) is a key issue from this poll and such a guideline (meant to mirror existing p&g) does no harm nor meant to impact this poll result. --MASEM (t) 16:17, 24 November 2017 (UTC)
    • Nobody said anything about the lack of a guideline. That's something you just dreamed up yourself to keep the pot boiling. Time drop the WP:STICK. Figureofnine (talk • contribs) 15:08, 25 November 2017 (UTC)

Here we go again

The article linked above is typical of the way Wikipedia is treated as a breaking news site rather than an encyclopedia. At 16:38 today a possible terrorist incident was reported to the police, and at 17:30 a Wikipedia article was created about it. At 17:43 the Metropolitan Police tweeted, "To date police have not located any trace of any suspects, evidence of shots fired or casualties" and at 18:08, "Our response on #OxfordStreet has now been stood down." Is this the sort of thing we should be encouraging in an encyclopedia? 86.17.222.157 (talk) 18:28, 24 November 2017 (UTC)

I see that the Wikipedia article was speedily deleted just after I posted here. For reference it was about this. 86.17.222.157 (talk) 18:42, 24 November 2017 (UTC)

If this discussion is going to continue, can an admin please move this discussion onto a sub-page, or archive some of the earlier failed proposals? power~enwiki (π, ν) 20:48, 25 November 2017 (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 about river disambiguation conventions

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.

Despite some minor squabbles, there's an unanimous consensus to Y support Dickylon's changes to Wikipedia:WikiProject Rivers.Finer issues could be sorted out through local discussions at project-talk-pages.Thankfully,Winged Blades^Godric 13:56, 23 December 2017 (UTC)

---

Should the changes in this diff be kept? I updated Wikipedia:WikiProject Rivers#Multiple rivers with the same name to reflect what I think represents a likely consensus, but the last time we had a small discussion there it closed with "no consensus" and advice to "be flexible". So we need a bigger discussion while remaining flexible. Dicklyon (talk) 01:53, 29 November 2017 (UTC)

Background

When I found that I had taken a picture of the Rio Puerco (Rio Grande tributary), its article was at Rio Puerco (Rio Grande), which I found confusing.

• Wikipedia talk:WikiProject Rivers/Archive 4#RfC on Rivers: updating the naming/disambiguation conventions – previous RFC, closed with "no consensus" and "be flexible"
• Talk:Rio Puerco (Rio Grande tributary)#Requested move 5 April 2017 – The only RM discussion I know of on this topic; it supports this change.

Discussion

• Support keeping the change that I made on 28 Nov. Over the last several days I've moved nearly 250 of the highest-ranked ambiguous river, creek, wash, etc. articles (mostly in the US West, and nearly 100 in Minnesota alone, see my move log) to include the word "tributary" to make the disambiguator meaningful to more readers than just the river insiders, which I believe accords with the inputs I got the last few times I brought this up (see Background above). Nobody has objected (but a couple have asked for a pointer to the previous discussion). So it's probably time to convert the proposed river title conventions to a real and improved convention more consistent with how disambiguation is usually done. I remain flexible and seek alternatives and refinements to my edits there. Dicklyon (talk) 01:53, 29 November 2017 (UTC)
• Support including "tributary" for less prominent watercourses that are primarily significant due to their relationship to a better-known watercourse. bd2412 T 04:50, 29 November 2017 (UTC)
• Obvious support. The idea that "St. Joseph River (Maumee River)" is a sensibly disambiguated title is nuts. Any disambiguation system that causes at least as much confusion as it would solve is a total failure. After this, we should change it to use comma disambiguation as per other placenames with the exception to use parenthetic clarification when there's a conflict, instead of making a silly "use parenthetic in the US and [where ever]" but use comma in the UK".  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  15:02, 29 November 2017 (UTC)
• Support in cases where disambiguation is required (in case that needs to be said). I don't see a need for anyone to create Saguenay River (St. Lawrence River tributary), for example, but this is as reasonable as any other special-case disambiguation method we use for other topics. Ivanvector (^Talk/_Edits) 15:13, 29 November 2017 (UTC)

  Since this is just one option in the subsection "Multiple rivers with the same name", I think you don't need to worry. But feel free to look and clarify if needed. Dicklyon (talk) 16:32, 29 November 2017 (UTC)

• Support per Ivan. --SarekOfVulcan (talk) 15:16, 29 November 2017 (UTC)
• Support. It just sounds better. Rationally, it seems a little strange that when a river dumps into another river we need an extra word to say that it does so, but I think the explanation is that River (River) is just too ambiguous. It isn't obvious what the connection between the two rivers is, unlike seas or bays which can only be related to rivers in one way. —David Eppstein (talk) 06:28, 30 November 2017 (UTC)
• Support. It's clearer for readers. Mathglot (talk) 10:23, 1 December 2017 (UTC)
• Support. The construction "X River (Y River)" reads as if "Y River" is a variant name of "X River", so the added term is necessary for clarification. On a related but distinct topic, I'll add that the "X River (Y River)" practice has been widely applied in the past in cases where it is not strictly necessary for disambiguation -- rather, it is thought by some that this format should be a solution to the precision issues that arise when a river flows through multiple U.S. states. Rock River (Mississippi River tributary) and Big Sandy River (Ohio River tributary) are examples of this (both were recently moved to incorporate the word "tributary"). I think "Rock River (Wisconsin—Illinois)" and "Big Sandy River (Kentucky—West Virginia)" would be more helpful for most readers, and there is no disambiguation problem that is solved by their current titles (i.e., there are no other streams named "Rock River" in Wisconsin or Illinois, nor other streams named "Big Sandy River" in Kentucky or West Virginia). There was a recent discussion of this at Talk:White River (Arkansas–Missouri). I'm generally opposed to the application of the convention "X River (Y River tributary)" in cases where rivers can be sufficiently disambiguated using the names of major jurisdictions instead. Thanks-- TimK MSI (talk) 13:19, 2 December 2017 (UTC)

  That seems reasonable to me. In working through states via articles such as List of rivers of Minnesota, I've noticed a lot of variance in the naming, articles, density of redlinks, etc. (Minnesota in particular has a lot of rivers, about 100 with tributary disambiguation, and had a ton of wrongly done stubs, with disambiguators copied into lead sentence and infobox titles, so took a lot of hours to fix). I think clarifying the conventions and working on some that diverge a lot from the norm would be a good idea. But I'm pretty bushed working on tributaries, and not done yet, so I'll leave that to others. Dicklyon (talk) 16:43, 2 December 2017 (UTC)

  List of rivers in Pennsylvania is proving to be quite a challenge. I'm several hours into it and flagging. So many Mill Creeks, so much unneeded disambig, etc. Dicklyon (talk) 03:47, 3 December 2017 (UTC)

  Done with PA. Moved over 300 more today. Just need to do New England now; and the rest of the world... Dicklyon (talk) 05:32, 3 December 2017 (UTC)

• Support on using the word tributary when a river is disambiguated by the downstream body. However the rest of the guideline is vague about guidance on choosing between disambiguators. It says political/geographical is commonly used and tributary can be used as well. I would like to have it state which is preferred (if we can reach a consensus on that) or at least in which circumstances is either preferred. I am leaning towards Rock River (Mississippi River tributary) over Rock River (Wisconsin-Illinois). Both seem equally good/logical as methods of disambiguating. But considering the number of common names used for small creeks, there is a precision issue to consider. For example, see Indian Creek. Methods used here include river, state, city, and county. There isn't even consistency within Missouri. As someone who has spend a fair amount of time disambiguating creeks, it isn't always easy. The dab page says there are three Indian Creeks in Pennsylvania, but GNIS lists 10 total (all of which could have articles someday), including two in the same county. There are three in one county in Arizona. Clearly there are cases when using political disambiguation doesn't work well. I think using (Y River tributary) is a bit cleaner overall and should be the default choice. MB 03:57, 3 December 2017 (UTC)

  I agree it's a bit of a complicated mess, and different groups (states, drainage basins, neighborhoods, or whatever) are doing it differently. Probably not something to resolve here though; that's the kind of thing a small group of river experts should be good at working out. Sounds like TimK MSI is leaning the other way, so you two should talk. Dicklyon (talk) 05:32, 3 December 2017 (UTC)

• Support I am unable to perceive strong cases for the other side. If there is opposition to this proposal elsewhere I am not quickly seeing it. I feel that giving clear guidance is preferable. So far as I can see, the previous guidance was saying that any of several options works. I appreciate the flexibility but it is helpful at some point to take a position and recommend a preferred way of doing things. The decision is somewhat arbitrary but what is proposed here seems logical and understandable to me, and of the proposed naming conventions, I prefer it. I say to firm this way of doing things until and unless someone more clearly articulates problems and has a better general rule. Blue Rasberry (talk) 16:39, 4 December 2017 (UTC)

Subtleties

I moved North River (Hudson River) to North River (New York–New Jersey), which might be in opposition to a previous move, though it's hard to figure out the malformatted discussion there. This is the only one I've noticed where the river in parentheses was an alternate name, not a tributary relationship. I suppose if we fix all the tributaries we could put it back, but I think it's confusing no matter how we do it. The article is about the alternate name for the lower Hudson River. Better ideas? Dicklyon (talk) 07:34, 3 December 2017 (UTC)

Status

I've now moved over 800 river disambig titles to include "tributary", in 49 states (Hawaii didn't have any like this). If I missed any, sorry. Hopefully this will be enough to attract the attention of at least all US wikipedians who have an interest in rivers. I just got one more query at my talk page and pointed him here. Dicklyon (talk) 20:03, 3 December 2017 (UTC)

Some rivers that aren't sufficiently disambiguated by tributary relationship include a place name as well. But when I did that for Beaver Creek (White River tributary, Missouri) to distinguish from the one in Alaska (which is listed but doesn't have an article), I got reverted. We could perhaps use a better scheme for this, or clearer guidance, as there are quite a few (dozens, not hundreds) like this. Dicklyon (talk) 20:23, 3 December 2017 (UTC)

I worked over the List of rivers of Quebec; maybe we'll get some less US-centric (or less English-centric) comments from there? They have about a million rivers, but most of them are redlinks, so very few moves were needed. Dicklyon (talk) 04:37, 4 December 2017 (UTC)

Nope, no more comments or pushback there, either. Time to close, move on, finish Canada, then the world ... Dicklyon (talk) 07:44, 9 December 2017 (UTC)

I believe I've finished with Canada now, too. And I've looked at Mexico and England and didn't find any such disambiguations. Does anyone know if some other countries use that? Dicklyon (talk) 04:43, 11 December 2017 (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 for changing the production section guidelines. 2

Please comment on the RFC here Thanks. --Deathawk (talk) 06:08, 6 November 2017 (UTC)

Remove "exception" to DEFAULTSORT guideline inserted on the basis of a 6-person, one-subject discussion

Someone's put the following into Wikipedia:Categorization of people:

Some people are known primarily by their first name only. When it is not possible to set the first name alone as the article title, as with many articles in Category:Brazilian footballers, you should sort with the first name first to make the article easier to find in the categories. For example, Leonardo Araújo is commonly known as Leonardo, and should be sorted as {{DEFAULTSORT:Leonardo Araujo}}.

It is proposed to replace this much clearer, narrower wording that does not have the WP:CONLEVEL policy problem of carving out a strange exemption for a single wikiproject:

Some people are known primarily by their first name (or a stage name) only. If an article's title is at that single name – alone, as in the case of Pelé, or disambiguated, as in the case of Pink (singer) – then do not use DEFAULTSORT at all; the article will automatically sort by the article title. If the article is at a full name (at least one given name and family name), sort normally in familyname, given name order. (Be aware that some cultures use family name first in natural language, so do not blindly assume that the last part of a subject's name is the family name); examples: {{DEFAULTSORT:Araujo, Leonardo}} Leonardo Araujo (often called simply Leonardo), and {{DEFAULTSORT:Utada, Hikaru}} for Utada Hikaru (often known as Utada).

The parenthetical about family name order could be put into a footnote.

[Clarified: 09:50, 12 November 2017 (UTC)]

Background and rationale

The current wording is obviously narrow-PoV instruction creep, and is completely pointless: If there's a genuine desire to have them appear in the categories under their first names for people familiar with them that way, this is done with categorized redirects, the same way we do this with any other subject, e.g. with a Leonardo (footballer b. 1969) redir to Leonardo Araujo. For any case where the full name is not actually the WP:COMMONNAME, then the page should be moved and disambiguated; we don't just "fake it" for category purposes by monkeying around with the DEFAULTSORT.

The justification for the current "rule" (in a footnote in the above-quoted material) is nothing but a single discussion at a sport wikiproject page, with a total of 6 participants, not all of them in agreement, dating to 2011.

This has led to disputes and "principle of least astonishment" bewilderment (here, most recently), plus the obvious category-sorting problem: People quite normally credited by a full name and at that name on WP, but also fairly often called by just their first name in a subset of (usually national/regional) news, are being sorted in firstname lastname order. Many of these subjects were not even alone in their sometimes-mononym, in the same context in the same place (e.g., multiple Brazilian footballers have popularly been called "Leonardo" in their heydays in the football/soccer press in Brazil).

Worse yet, Category:Brazilian footballers has become a complete trainwreck, with around 85% of the entries in it sorted by given name, due to people mistaking the original idea – an uncommon exception – for a standard to apply to any Brazilian footballer. I don't have the heart to check whether it's spreading to other footballer categories or other Brazilian sport categories (or even further) but I'd bet money on it.

Contrary to the current wording, this obviously does the exact opposite of make the articles easier to find in the category, since the entire world expects them in family-name-first order, and only people already very familiar with the subject, and probably from the same place where the subject is called by given name, would expect otherwise (if even then). Those few would also be less likely to be manually digging through a category for that subject, especially a massive one like Category:Brazilian footballers.

There's no evidence the current "rule" has consensus, just the support of less than half a dozen people with a shared micro-topical interest in popular football players in one country.
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  21:57, 10 November 2017 (UTC)

Comments on DEFAULTSORT revision

• Support: if someone is most commonly known by their forename only, then that should be the article title, with disambiguation such as "(Brazilian footballer born 1960)" as necessary; a redirect (or dab page entry or hatnote) should be made from their full name if given in the article. The DEFAULTSORT will be that single name.

If the article title is "Forename Surname", then the DEFAULTSORT should follow the normal rules for names of that nationality, usually "Surname, Forename". If the article states that they are also known by the single name, then there should be a dab page entry, hatnote or conceivably a redirect (if unique name) from that single name. End of story.

Not everyone who Wikignomishly edits an article on a Brazilian footballer will be a specialist in Brazilian football, and there is no convincing reason why this narrow exception should exist. PamD 22:34, 10 November 2017 (UTC)

• Comment: The text "then sort the article by the article title" should be "then do not use DEFAULTSORT at all". All articles, by default, sort according to the exact title, except where there's a DEFAULTSORT to make it something else. In other words, DEFAULTSORT is only ever required where it is desired the article be sorted by some key other than the exact title. This is why I've long thought the name "DEFAULTSORT" is an utter misnomer. It is only used when the default sorting (i.e. what you get when you do nothing) is exactly what is NOT required. -- Jack of Oz ^{[pleasantries]} 22:47, 10 November 2017 (UTC)

  Oh! Right. Duh. I'll fix that.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  03:41, 11 November 2017 (UTC)

• Comment: "sort normally by the conventions for the culture in question". Then the Brazilian ones are all incorrect. I'm Brazilian and we rarely talk to/compliment other people by using their surname, we only use forenames (one or two) - this is an American/European culture, not ours. Although I can't agree with @PamD's comments either, because if we use WP:COMMONNAME for all "Leonardo", all "Gabriel" that are or were Brazilian footballers and are or were known by their first names only, can you imagine the confusion of "(Brazilian footballer, born month year)"? MYS77 ^✉ 18:23, 11 November 2017 (UTC)

• Hmm, I wonder whether that's the case for scientists, lawyers, politicians, etc: would a list of Brazilian medical doctors be sorted into A-Z by forename, or by surname? That's what "Defaultsort" is about. .... Hmm, interesting: have found a couple of university pages where staff are listed in A-Z order of first names here and here. If this is really the norm for Brazilian lists of Brazilian people (rather than just lazy programming) then there needs to be an exception on the same basis as for Icelandic lists of Icelandic people. I suggest that WP:WikiProject Brazil needs to be consulted on this. PamD 19:18, 11 November 2017 (UTC)

Comment - Icelandic names are not Western-style names. They are patronymic and do not use inherited surnames. It is my understanding that Brazilian names in general are Portuguese-style, which is a modified form of Western style with a matronymic. Brazilian athletes typically use mononyms, which are a different special case. Is the real issue the mononyms used by Brazilian athletes, or the Portuguese-style nomenclature, which is modified Western, or something else? Robert McClenon (talk) 02:21, 12 November 2017 (UTC)

@Robert McClenon: You are correct, but Brazilian athletes use their surnames because they are appearing in an European/American-based competition, which has English as its main language and the sorting of surname, forename as its standard. A good example is Isaquias Queiroz: sorted by Queiroz, Isaquias in the Olympics/other competitions, he is known as just Isaquias in Brazil, per here, here, here and here. MYS77 ^✉ 14:11, 13 November 2017 (UTC)

• @PamD: That's what I've been trying to explain to @SMcCandlish and @GrahamHardy, sorting is not equal when it comes to Brazilian people (especially footballers)... Sorting Brazilian names by surname, forename is a rare exception. Even doctors here are listed by their forename. MYS77 ^✉ 21:44, 11 November 2017 (UTC)

• This list is a clear example of how sorting can be difficult when related to Brazilian people. The majority of these politicians are sorted by his forename, but there are some exceptions where they are sorted by surname. MYS77 ^✉ 21:46, 11 November 2017 (UTC)

@MYS77: The list of doctors you quote shows us nothing, as the people are listed there by job title not name. From the same website another list might have been useful but seems to be in random order within each of the two groups which I'd have expected to see sorted (A=Z by surname if British). The list of politicians is just mind-boggling. What would a printed telephone directory look like, I wonder? PamD 23:12, 11 November 2017 (UTC)

• PamD. This has nothing whatsoever to do with how people use spoken English (much less spoken Brazilian Portugese), only about what the family name is. WP (like 99% of the rest of publishers) sorts alphabetically by family name. The issue here is, thus, that Mao Zedong should be sorted as "Mao, Zedong", not "Zedong, Mao". I.e., people have to be aware which is the family name and not assume blindly that the last one shown in the name is it.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  09:44, 12 November 2017 (UTC)
  I've clarified the proposed wording to be much clearer.
   — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  09:50, 12 November 2017 (UTC)

What percentage support should be needed for a policy proposal on Wikipedia to pass?

Wondering if we already have consensus on this? I have seen greater than approximate 66% support frequently used (thus those who oppose change get twice the vote as those who support change). We give the closing admin some leeway in judgement based on arguments, but generally not that much. Others thoughts? There are requests for clarification around the consensus process. Doc James (talk · contribs · email) 05:48, 19 November 2017 (UTC)

Like most things, we don't vote on these so there is not a percent. — xaosflux ^Talk 06:03, 19 November 2017 (UTC)

But we sort of do. The question is how do we determine consensus, and "it is complicated" is not a very useful answer. Doc James (talk · contribs · email) 06:09, 19 November 2017 (UTC)

Generally I've seen it as a 2/3 majority, especially in big discussions where it's a lot harder to simply discount one side of the argument. I can't recall it ever being written down anywhere though, probably because we hate voting so much that every major decision is effectively made via that process. Jenks24 (talk) 06:26, 19 November 2017 (UTC)

@Doc James:--Can you link the discussion or call for clarification? Because, I feel that it would be a pointless bureaucratic exercise and will most-likely oppose any attempt at clarification.From my own experiences and observations, numerically, anything greater than 66-70% shall be enough but arguments need to be almost always weighed and it's complicated is the optimum call.Winged Blades ^Godric 13:28, 19 November 2017 (UTC)

• We intentionally don’t set a firm percentage. Broadly speaking, the more support a proposal gets, the more we can say it reflects consensus and should be adopted. However, we also pay a lot of attention to STRENGTH of arguments for and against. A few well argued opposing comments can sometimes out weigh a lot of supporting comments that essentially just say “I like it” - but contain no explanation as to WHY it is liked (and vise-versa). Determining consensus can be as much an art as it is a science. Never easy, unless the consensus is fairly overwhelming. Blueboar (talk) 16:12, 19 November 2017 (UTC)
  • Wikipedia is neither a bureaucracy nor a democracy; it would be better described as a "meritocracy", where "votes" with more merit are given more consideration than "votes" with less. Please read Wikipedia:Polling is not a substitute for discussion. עוד מישהו Od Mishehu 07:45, 20 November 2017 (UTC)
    • "Given more consideration" by the closer? If that's the reality, we should see some closes going against the numbers (assessing a consensus against the majority !vote). Can you point to two in the past year? ―Mandruss ☎ 08:01, 20 November 2017 (UTC)
  • Supports are always typically taken to mean that the participant thinks that the rationale provided by the proposer is correct. Opposes have more of a burden in every conversations since no one is writing an overarching statement with reasoning, as any good policy proposal will have. TonyBallioni (talk) 16:58, 20 November 2017 (UTC)
    • Agree. And opposes are typically given twice the vote as supporters so excellent rational should be expected. Doc James (talk · contribs · email) 17:49, 29 November 2017 (UTC)
      • You could have a rationale provided for both sides in an RFC; see Wikipedia:Requests for comment/Example formatting#Pro and con for one way to do that. WhatamIdoing (talk) 18:24, 30 November 2017 (UTC)
• I'm not aware that the rules being different here than for any other discussion. 2/3rds is an interesting marker, but by no means is it the line in the sand. Discretion is in the hands of the closer, and then if the community supports that close. Dennis Brown - 2¢ 16:41, 20 November 2017 (UTC)
• Typically 60-65% for guidelines,66-70% for policies. Also, I will put my standard bitching out there that screaming for policy based reasons and to ignore numbers on policy RfCs is circular reasoning and the last resort of the losing side of an RfC: it is literally impossible to have a policy-based reason to change policy. Policy RfCs are very different than regular discussions and are much more like a vote.
  Our information page on closing discussions also makes clear (in the lovely worded shortcut WP:not counting heads) that If the discussion shows that some people think one policy is controlling, and some another, the closer is expected to close by judging which view has the predominant number of responsible Wikipedians supporting it, not personally select which is the better policy.
  In a discussion where there can be no controlling policy, this turns the discussion much more into a poll. Obviously arguments such as I hate the proposer, so I'm opposing or Wikipedia sucks and this will help it go down in flames, I support, should be discounted, but otherwise good faith opinions should be given equal weight. TonyBallioni (talk) 16:54, 20 November 2017 (UTC)
  • If the boundaries of all policies were clearly non-overlapping, then sure, by definition a policy change would not be based on other policies. But in practice, policies have fuzzy boundaries, and often additional clarification is required. Thus a consensus agreement to determine the relative weight and tradeoffs of all applicable policies needs to be reached. isaacl (talk) 19:01, 20 November 2017 (UTC)
    • Agreed re: fuzzy and overlapping, but even when two policies are in tension, numerical consensus is how our closing guidelines say something should be evaluated. If there are two policy-based arguments opposing each other, having an RfC to determine which should be applied would not have a strong pre-existing basis, otherwise there wouldn't be confusion. On new policies or removals, there is virtually never any basis for a change in policy. I'm not arguing for a pure poll, but simply that at some point, numbers matter. TonyBallioni (talk) 19:07, 20 November 2017 (UTC)
      • In practice, nearly all English Wikipedia decisions are made via a straw poll with commenters trying to persuade others, so sure, numbers matter. As a community grows, it is increasingly unlikely that it will be strongly aligned in purpose, which is required for true consensus. Even with everyone behaving in good faith, people have different guiding principles that lead them to interpret policies differently. And because Wikipedia's guidance doesn't all move in lockstep, but incrementally as different groups of interested persons shift guidelines and policies one way or another, it is quite possible to have policy A which had been based on principle X originally, and a newer policy B based on principle Y that pulls in a different direction. Consider, for instance, how the need for citing everything has gained increasing importance over the years. Accordingly, Wikipedia guidance has been updated to reflect the change in the community's underlying views, and it is reasonable to make policy-based arguments on how to adjust older guidance to adapt. isaacl (talk) 05:09, 21 November 2017 (UTC)
  • What Tony said. For policies (and occasionally guidelines) you often cannot have arguments based on policies - because you are usually either seeking to add one, remove one, or alter one to say something different. Strength of argument does make a difference, a !vote with a credible and plausible rationale behind it carries far more weight than 'I like/don't like it'. Only in death does duty end (talk) 17:09, 20 November 2017 (UTC)
    • I agree that you "often" cannot have arguments based on policies, but I disagree with his assertion that it is impossible. For example, we can, and probably should, be changing several SNGs to explicitly repeat NOT's policy on not having any articles whatsoever (much less BLPs) for which no third-party reliable sources are not available. That's a policy-based argument, and therefore it is possible to make such arguments. WhatamIdoing (talk) 18:27, 30 November 2017 (UTC)
• It should be no firm percentage, given that the second you set a number, it becomes a firm number. If we said 66%, then if we had a discussion with 200 participants, and there were 132 supports, we would expect it to ALWAYS be closed in favor, and 131 supports would ALWAYS be closed against, because you've just told everyone that 66% is your number. The guidance on this should always be intentionally vague. --Jayron32 18:36, 20 November 2017 (UTC)
• Per some of the above, percentage support is hardly the only factor. The closing admin also needs to evaluate the degree to which participants are making informed arguments, weigh their relative experience as contributors to Wikipedia (or, where applicable, other Wikimedia projects), and weed out troll posts. The degree of participation also matters. A proposal for a major change that gets two votes in favor and one against is not in nearly as strong a position as a proposal that gets two-hundred votes in favor and one-hundred against. bd2412 T 20:44, 20 November 2017 (UTC)
• The German Wikipedia has structured votes on policies with strict numerical standards for suffrage and vote counts. We are a lot less organised, which makes us a lot more flexible (and somewhat more anarchic). Fixed percentages only make sense in much more structured environments than our usual policymaking dramahboards. —Kusma (t·c) 14:11, 21 November 2017 (UTC)

  It's also a very German way to handle it. Cultural relativity matters, even on Wikipedia, and we expect different language communities to have different cultural millieu, which is why we allow local governance. What works for the German-speaking community in the context of their culture doesn't necessarily work in the Anglophone world. --Jayron32 15:00, 28 November 2017 (UTC)

  Amen to that.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  14:14, 29 November 2017 (UTC)

• Can't agree with "it is literally impossible to have a policy-based reason to change policy", because WP:POLICYFORK. There have been many, many times when policy arguments have been, necessarily, used to adjust conflicts between policies and between guidelines, etc. (Infamous example: a wikiproject incrementally forked two naming conventions and an MoS subpage away from the main MoS page to push a viewpoint, it turned into several years of dispute, finally settled in a massive RfC that normalized it back to the main MoS position; details elided per WP:BEANS and the "don't pick at scabs" principle). Not all policies are created equal. E.g. WP:OFFICE policies trump community-created ones. Below the OFFICE level, WP:CCPOL ones trump a lot of other ones on many things, though this can run the other direction (e.g. the vague generalities in WP:V, WP:RM, and WP:NOR can't be used to evade the specifics of WP:MEDRS, within medical articles. Site-wide guidelines trump micro-topical ones per WP:CONLEVEL. Except that broad consensus can decided that in a particular case it does not, as it did with MEDRS. Etc., etc. Short version: "It's more complicated than that."

  At least at this stage in the en.wp organizational lifecycle, switching to a vote-based system might be fatal, and would at very least do severe damage, even if it might be recoverable. A tremendous number of editors would leave, right off the bat. I know I would. This principle problem with the idea is that there are way too many issue to resolve, with too few people to resolve them and too few people competent to resolve them. The consequence is that only those who care and know WTF they're talking about work on resolving them (aside from a few tendentious gadflies who get in the way). A voting system would require a much larger pool with much more interest in participation in such matters than we actually have. What would happen is that the tendentious loudmouths would be given near-free reign to impose their will by sheer refusal to ever STFU about whatever they refuse to let go.

  E.g. if you have five editors convinced that it's a great wrong that some policy or guideline gets in the way of their WP:OWNership of some topic, all they have to do is convince a few of their cohorts to go along, then they have a thick voting bloc to modify a policy to carve out a special pleading exception for their peccadillo; meanwhile hardly any one else is going to care or even know what they're talking about, so the motion will pass. In the present system, ten people can show up and make a stupid argument, and two editors can oppose it on solid policy and RS footing, and a sensible closer will not close in favor of the stupid thing, because it's self-evidently stupid and has no basis, while the two common-sense people who spoke up actually had the meaningful input. This doesn't always happens – too many inexperienced or nervous closers close in favor of the majority even when it's stupid, but this trend is thwarted frequently enough (much as the Senate often blocks lame-ass populist nonsense from the House of Representatives – or at least it used to) that en.wp is remarkably stable. That stability would be out the window in an instant if we switched to numeric majority, vote-based decisionmaking. Voting might actually have a made sense in 2005–2008 when WP was awash in editors, but it makes sense less and less the more the editorial pool condenses.
   — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  14:33, 29 November 2017 (UTC)

  • I don't think I'd argue ever for a simple majority or for a small poorly advertised discussion to change policy. I think you probably know that I'm more than willing to close local discussions against the numbers when they aren't in line with policy. At the same time those who scream NOTAVOTE every time they are on the "losing" end of the conversation seem to ignore that numbers do matter, especially in a policy RfC. If a policy RfC is widely advertised, has large participation, and over 70% support, there is virtually never any justifiable reason to have a result other than adopting the proposal. Re: policy RfCs: I was not discussing splits, but the creation of new policies and guidelines, where I stand by my statement that it is impossible to have a valid reason in policy to propose a new one. Heck, we even have a policy supplement against it. I think the point that Doc James and I are trying to make is that it is extremely arrogant in a discussion with over 100 participants for the loudest voices in a position that received less than 30% support to say "Our arguments were better, so you can't do this." Common sense dictates that numbers matter, and we shouldn't just stick our heads in the sand on that. TonyBallioni (talk) 14:45, 29 November 2017 (UTC)
    • I agree the closer should be given some leeway in votes between 60 and 70% when more than 100 people have weighted in (after bad faith and sock votes have been removed). That those who oppose something can demand 80% or 90% support is simple unreasonable. User:SMcCandlish I would argue that this currently gives "loudmouths... near-free reign to impose their will by sheer refusal" as it is fairly easy to build a block of 10 or 20% Doc James (talk · contribs · email) 18:02, 29 November 2017 (UTC)
      • We don't seem to have a case history of this, though. Can you show a proposal with 80% or even 70% support (after discounting clownage) that was not actually adopted? This looks like a solution in search a problem, and it would have a lot of fallout.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  00:54, 30 November 2017 (UTC)
        • Sure on meta right now.[2] This RfC was initially closed as not supported but Rentier reversed the close.[3] Doc James (talk · contribs · email) 18:36, 7 December 2017 (UTC)

• • • I still don't agree with "can't use policy to make policy". All of our policies inter-relate, so we always use policy to make more of it. You seem to be imagining a scenario where we have some policy proposal that has no relationship to existing policy. I was going to make up a silly example but I can't actually think of one, because every case I can come up with actually relates strongly to either one of the WP:CCPOL, a legal matter we already have a policy about, or behavioral policy. It's seeming increasingly unlikely to me that we're ever going to have any new out-of-the-blue policy that isn't deeply rooted in existing policy.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  00:59, 30 November 2017 (UTC)

We don't even need a majority, we just need a consensus as per wp:closing. But what does that mean? Well, I've been at Uniting Church in Australia meetings where consensus decision making was used and a handful of people won over the majority, and all agreed afterwards that it was a good decision. But that needs a skillful chairperson, or in our case, a good closing admin. And it needs mutual respect so that "loudmouths" (mentioned above) don't just shut other people up. That is why I'm so concerned that the current tendency to regard wp:NPA as "aspirational" to the point that even admins don't abide by it will eventually make consensus here meaningless. Andrewa (talk) 22:25, 29 November 2017 (UTC)

We need a sea-change at ArbCom, to start enforcing the civility-related policies again. This has already happened a little, incrementally. E.g. not that long ago a civility desysop case was brought, we clearly going to result in a desysop, and the admin resigned the bit under that cloud.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  00:54, 30 November 2017 (UTC)

Disagree that we need... to start enforcing the civility-related policies... Enforcement shouldn't be necessary, and isn't practical in any case unless we have a clear consensus that wp:NPA is more than "aspirational", and we don't. That consensus is what we need. More important, NPA is far more than a civility-related policy. It is a cornerstone without which meaningful consensus can't be achieved or assessed, whether in the UCA or Wikipedia or anywhere else. Civility can be in the eye of the beholder, while NPA has no such wiggle-room. Andrewa (talk) 08:16, 30 November 2017 (UTC)

View source text next to section titles on protected pages

Moved to WP:VPT § View source text next to section titles on protected pages

 – This would not require any policy changes. — xaosflux ^Talk 16:39, 19 December 2017 (UTC)

How Wikipedia fights for facts by redefining the truth

After coming across this amazing essay (Wikipedia:Why Wikipedia cannot claim the earth is not flat), one of the most intelligent attempts at addressing a fundamental question in Wikipedia, I am proud to say it also informed this feature, published by Israel's Haaretz newspaper in both English and Hebrew this past week.

The story attempts to show how editors try to defend factual content in an encyclopedia where the definition of what constitutes a fact is also set by the community and is intended for readers with little to no personal experience or understanding of Wikipedia. The main claim in the article is that this is achieved by striving for verification of facts and not absolute truth.

The story attempts to show and debate Wikipedia and its polices implicit position on the question of truth, and, unlike most reports of this style, does not attribute independent agency to Wikipedia, instead addressing how different parts of the community involved in this efforts view it.

Would love to hear what you think. Omer Benjakob (talk) 08:05, 16 December 2017 (UTC)

I´ve enjoyed your articles (assuming you´re that Omer Benjakob), it´s rare to see WP written about at this "deep", so to speak. If you haven´t seen it yet, you may find this discussion a little interesting Talk:Intelligent_design#My_$0.02_on_the_issue_of_bias Gråbergs Gråa Sång (talk) 10:55, 16 December 2017 (UTC)

The article is paywalled, is there any way to get around that? Also, I don't think this is an appropriate place for this discussion. Thanks, Darylgolden^(talk) Ping when replying 11:17, 16 December 2017 (UTC)

Hm, neither is paywalled to me, a location thing? Or one of those "X free articles per month"? BTW, would you say there is an appropriate on-WP place for this discussion? User talk:Jimbo Wales perhaps... Gråbergs Gråa Sång (talk) 11:31, 16 December 2017 (UTC)

Or maybe Wikipedia:Village pump (miscellaneous). Gråbergs Gråa Sång (talk) 12:51, 16 December 2017 (UTC)

Wikipedia:Village pump (miscellaneous) would probably be a better place, though I'm not sure if if it's appropriate even there. Darylgolden^(talk) Ping when replying 13:46, 16 December 2017 (UTC)

"Give me feedback on my off-WP work!" is hard to fit in somewhere, isn´t it? Still, there´s always WP:IAR ;-) (yeah, yeah, that doesn´t quite apply either...) Gråbergs Gråa Sång (talk) 14:03, 16 December 2017 (UTC)

Hey all, I am indeed the author of the article and am pleased that you find it "deep". I was indeed unsure if this is the right place and I think it is telling that "off-WP" work about WP does not necessarily have its own place within Wiki, which I think explains why some essays are indeed meta and abstract, if not to say down right philosophical. Thanks for the link User:Gråbergs Gråa Sång - if anyone else has anymore pages that they think could be of interest to me, or even just stories from inside WP, especially those indicating shifts in what you hold to be important polices or debates about doing so, then send them my way. I think it is important to cover WP - not just as content, but also as a project Omer Benjakob (talk) 09:18, 17 December 2017 (UTC)

Now that is something you should ask for at User talk:Jimbo Wales, I think all kinds of people are watching that. Gråbergs Gråa Sång (talk) 09:33, 17 December 2017 (UTC)

The flatness of the earth may be more controversial than you (and the essayist) think. It's true that almost no scientists have thought the earth was flat since about the fourth century BC, but are these the only reliable sources?

What about artillery people? The trajectory of a shell, we are told, describes a parabola. In Australia and I suspect most of the world, high school students of mathematics regularly solve problems using this assumption, and so I believe do the armies and navies of the world, and with deadly accuracy. But this of course assumes that the earth is flat. If it were not, then the trajectory would be an ellipse. (;-> (The essay does mention this argument, rather dismissively, and IMO inadequately.) Andrewa (talk) 10:24, 19 December 2017 (UTC)

Andrewa, the artillery shell trajectory above is a bad example for a couple of reasons. First, the trajectory remains a parabola relative to a flat plane regardless of where it intersects the ground (higher than the plane on a mountain side or lower than the plane because the range has extended beyond the noticeable curvature of the earth. Like high school students using a theoretical model, gunners use the model only to the point where the errors are minimal with respect to the other errors involved. Basic (short range) gunnery tables can use this model without taking in to account the curvature of the earth. This is in fact why gunnery solutions for longer range artillery engagements (say greater than 25 km) does in fact have to "calculate for the curvature of the earth". Remember the maxim "All models are wrong, but some are useful". And yes, I used to be an expert on such things too. 'Cheers, Loopy30 (talk) 18:06, 19 December 2017 (UTC).

Some excellent points there, and they're exactly the reason that I think it's such a good example. (25km is a bit short, 40 mile bombardments used the parabola model quite successfully in the days before electronic computers.) But your argument the trajectory remains a parabola relative to a flat plane... is interesting. In fact the trajectory is never a parabola, in that it's always better approximated by an ellipse, but only very slightly in the case of a short-range artillery shell flight. The good results obtained by the parabola model are valid evidence that the earth is flat, but we have long had better evidence, and better models based on this evidence. (Similarly "it's flat where I live" is a valid argument. A builder properly assumes that the plumbob gives parallel lines wherever in the house he uses it, and it's close enough, although those "parallel" lines intersect at the centre of the earth.) As many have observed, the dismissal of flat-earth arguments is often more akin to a religious faith in something wrongly called science than to an application of scientific reasoning. That's the point. Andrewa (talk) 20:18, 19 December 2017 (UTC)

I have to say, I'm more than a little disturbed by even the perception that the Günter Bechly article was deleted "as revenge by the scientific community on Bechly for using his status to promote his own religious beliefs". We don't delete biographies for revenge, or because we don't agree with the subject's views.
Or at least, we aren't supposed to. If that did happen (and sadly I don't find it entirely implausible), then it was a serious abuse of process. --Trovatore (talk) 11:21, 19 December 2017 (UTC)

Trovatore reading Wikipedia:Articles for deletion/Günter Bechly may provide enlightenment, or not... Roger (Dodger67) (talk) 11:36, 19 December 2017 (UTC)

Well, exactly.... --Trovatore (talk) 11:44, 19 December 2017 (UTC)

The AfD was not so much an abuse of process as an example of how our processes can go wrong. Most of the arguments on both sides were sufficiently flawed to be discarded by the closer, and they did an excellent job wading through them. But IMO the result was still both wrong and counterproductive. It's not the only pimple on Wikipedia's face, and they'll always be there. See User:Andrewa/silly ideas#Reliability for a blatant case of circular reporting for example. But I'm sure it will eventually be fixed, just as the NYRM2016 fiasco was in time overturned. And ironically, when the Günter Bechly article is eventually recreated, part of the justification will be the sources that now discuss Wikipedia's action in deleting the article. Andrewa (talk) 19:54, 19 December 2017 (UTC)

Someone had the same thought when this was discussed at the fringe noticeboard awhile ago. Stranger things have happened. Gråbergs Gråa Sång (talk) 22:33, 19 December 2017 (UTC)

Indeed. The six star rank article was also deleted (see discussion here), but in that case quite quickly recreated. (It's still such a lousy excuse for an article that it would be better deleted IMO... but some hobbyists own it.) Our processes are (again) not perfect! Can you provide a link to this fringe noticeboard? Sounds interesting. Andrewa (talk) 00:37, 20 December 2017 (UTC)

I could have been more clear: Wikipedia:Fringe_theories/Noticeboard/Archive_58#This_noticeboard_mentioned_in_media Gråbergs Gråa Sång (talk) 08:57, 20 December 2017 (UTC)

All good, and thanks for the link. Very interesting, as you say, and many good points made there. We are to some extent reinventing the wheel here. Andrewa (talk) 09:06, 20 December 2017 (UTC)

It´s hard to avoid such a perception whether true or not, from those who wish to perceive it. The perception that some !voters had been off-WP canvassed may have pissed some other !voters of. Someone can always try to recreate the article or start a deletion review if they think it´s worth it. However, "it would have been wiser, if only for the historical record, to keep Bechly’s entry" (Benjakob) is not WP either. There´s Deletionpedia, though.[4] Gråbergs Gråa Sång (talk) 18:51, 19 December 2017 (UTC)

And at least two other archives, one of them at Wikia would you believe it. See Unimpedia:other unarchives for a list, and if there are others please tell me. Or perhaps we should propose a List of online archives of deleted Wikipedia articles. (;-> Andrewa (talk) 02:04, 20 December 2017 (UTC)

They wouldn´t want to be called archives, but Everipedia [5] and Infogalactic [6]. Dear old Conservapedia doesn't have an article, but they know about him:[7]. Gråbergs Gråa Sång (talk) 09:18, 20 December 2017 (UTC)

Thanks.... as you suggest (I think), these aren't archives in the sense of the three unarchives I've found so far, they seem to be partial mirrors of Wikipedia. I hadn't found (or looked for) such before, but we can expect more of those I guess, especially as people discover how easily and cheaply AI can create and maintain a legal but POV mirror of Wikipedia... these don't look like that. The involvement of Larry Sanger in one of them is particularly interesting, his Citizendium seems dead in the water but that's no reason to assume that this one will be too. And I'm guessing there are and/or will be other satirical sites like my Unimpedia as well.

Very interesting. To me it underlines how important it is for Wikipedia to stick to the 5P (including wp:5P4 which even some sysops now seem to see as aspirational). They are more radical than some think, and more interrelated than might at first be obvious. And without them we become just another blog, and could go the way of Kodak with just as little warning... or perhaps even less.

And incredible as it may seem, we have now strayed into questions that are on-topic for this Village Pump subpage. Andrewa (talk) 16:51, 20 December 2017 (UTC)

Paid use of administrator tools RfC

An RfC has been started on paid use of administrator tools and disclosure at RfA at Wikipedia_talk:Administrators#RfC_about_paid_use_of_administrator_tools. All are invited to participate. TonyBallioni (talk) 23:41, 20 December 2017 (UTC)

Announce: RfC: Nonbinding advisory RfC concerning financial support for The Internet Archive

Wikipedia:Village pump (miscellaneous)/Archive 57#RfC: Nonbinding advisory RfC concerning financial support for The Internet Archive --Guy Macon (talk) 00:26, 22 December 2017 (UTC)

Proposal to adopt WP:WikiProject Video games/Article guidelines into MoS as "WP:Manual of Style/Video games"

FYI

 – Pointer to relevant discussion elsewhere.

Please see: WT:Manual of Style#Proposal: Adopt WP:WikiProject Video games/Article guidelines into MoS.
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  01:38, 22 December 2017 (UTC)

Minor edits

Is there a guideline or policy covering which edits should be flagged as minor?

Help:Minor edit covers it well but is not very authoritative, and doesn't link to anything that is (unless I've misssd it). Having been around since a little before that page existed, I think there used to be something, but I can't now find it.

And a guideline seems to me to be a good idea. See Special:Contributions/MaiWardi for some quite major edits marked as minor. Andrewa (talk) 09:44, 19 December 2017 (UTC)

@Andrewa: The help page you link to seems to quite well spell out what is and is not a minor edit. What do you think is missing? RudolfRed (talk) 19:41, 19 December 2017 (UTC)

I think that the criteria for flagging an edit as minor should be recognised somewhere in a guideline. Currently it seems to have no more status than an essay.

The main problem is that even if users blatantly abuse the minor edit flag to try to hide their unsourced and/or POV edits, there's not a lot to be done. (Trying to similarly hide vandalism is not a problem, as the accounts involved are generally vandalism-only accounts anyway, and as such can be (and are) simply indeffed.) Andrewa (talk) 21:26, 19 December 2017 (UTC)

I don't have time to dig them up now, but the AN/ANI archives do have a number of cases where editors have been sanctioned for repeatedly marking non-minor edits as minor. Its considered a form of disruptive editing. (Even if its not listed at WP:DISRUPT which it really should be under evading scrutiny) Only in death does duty end (talk) 08:57, 20 December 2017 (UTC)

Agree it is disruptive, but as you point out not explicitly so. If anyone can find archives of those sanctions I'd be interested. Andrewa (talk) 16:56, 20 December 2017 (UTC)

Definitely worth researching, and the place to codify it would be WP:EDITING policy.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  01:39, 22 December 2017 (UTC)

• Mis-labeling of major edits as minor used to be a major problem back when we had a preference setting "mark all edits as minor by default" (before 2011: phab:T26313). It seems much less common these days. But mentioning that it is not OK to mis-label edits as minor in WP:EDITING seems like a good idea. That Help:Minor edit and Help:Edit summary are "information pages" and not "guidelines" is weird, and maybe we should change that. Unlike Help:Move, which explains the technical details (and refers to Wikipedia:Moving a page), these pages actually explain both the technical aspects and the etiquette surrounding the use of the features. —Kusma (t·c) 18:00, 22 December 2017 (UTC)

Minor clarification: we still do have said preference, it's just hidden from the UI. It really should've been removed outright, in retrospect. FACE WITH TEARS OF JOY ^[u+1F602] 00:00, 27 December 2017 (UTC)

• The "This is a minor edit" checkbox should be removed from Mediawiki. That's the real RFC that needs to occur. The feature begs the question what counts as a major vs minor edit and there's no good answer to that because it's intrinsically subjective. Further, there's nothing to stop a person from marking major edits as minor or leaving minor edits unchecked. You can't use simple metrics either like the article diff size, of course, because it is very misleading regarding the impact to the article. As a frequent "minor" editor, I've also always felt having to mark my contributions as minor was slightly demeaning. Given only two choices, it'd be better if we were asked to mark edits as major to indicate "hey, please given my edit extra special proof-reading", not marking them as "minor" to have the effect of saying "hey, this is probably just a punctuation or spelling change you can skip". Bots edits already have their flags and, in my opinion, bot edits should never be marked as minor because bots make too many mistakes. The minor edit feature has been something that strikes me as a malfeature for a number of years now. Removing it entirely is low-hanging fruit for making editing slightly less intimidating for new users. We would gain simpler editing while losing almost nothing. Jason Quinn (talk) 15:55, 23 December 2017 (UTC)

I wouldn't be opposed to such a proposal. FACE WITH TEARS OF JOY ^[u+1F602] 00:01, 27 December 2017 (UTC)

Bots doing talk-page maintenance use this for the "nominornewtalk" ability and that is very useful and should be preserved if this system is going to change for normal editors. — xaosflux ^Talk 00:55, 27 December 2017 (UTC)

Good point. That could easily be preserved with minor adjustments. A clean break from the past, however, would handle this by creation of a "suppress_new_talk" kind of permission, which would be more clear semantically. Jason Quinn (talk) 10:17, 28 December 2017 (UTC)

Using categories portal of main articles for a section?

I am trying to fix Immigration to Sweden and I have noticed people are creating new sections about nationalities (Iraq) and ethnicities (arabs) in addition to the table that is already in the demographics section. I have started a discussion on the talk page, I doubt I will get an answer there. I don't think the article should have 21 and counting different sub sections about each nationality. I others put a section there to promote their main article. I see the point in this as it notifies interested readers about these articles, but it also makes the article itself more difficult to read. If it was one article you could have made it a Main article:arabs in Sweden, but now there are so many different nationalities. How should we solve this? Should we place Category:Ethnic groups in Sweden in its place? I have never seen anyone use categories like that. Should I create a list page and link to it? Most information in these subsection do not add information when you have the table.

--Immunmotbluescreen (talk) 00:15, 29 December 2017 (UTC)

I suppose my question really is lists vs categories Wikipedia talk:Categorization/Archive 1#Lists v. categories and there seem to be no clear answer here. --Immunmotbluescreen (talk) 09:07, 29 December 2017 (UTC)

Removal of COPYVIO content as an exemption to WP:3RRNO

Currently the list of WP:EW#Exemptions to the three-revert rule includes Removal of clear copyright violations or content that unquestionably violates the non-free content policy. This allows one editor to remove such content and by doing so prevent another editor who added it originally from addressing the issue (e.g. properly paraphrasing it) and restoring it. This problem could occur anywhere, but is particularly apparent in articles falling under 1RR. I propose adding an exemption regarding restoring content that was removed on such grounds or on similar grounds. Otherwise, unscrupulous editors are able to use this technicality for suppressing POV they disagree with and pushing their own, even though following the letter rather than the spirit of the rule designed to prevent edit warring goes against common sense. --Wiking (talk) 05:30, 15 December 2017 (UTC)

I don't quite understand. Editor A adds a copyvio, Editor B reverts. This revert is free and does not count against 3RR. Editor A adds a non-copyvio cited rewrite of said content. This is not a revert and does not count against 3RR. If Editor B reverts, it is not covered by the exception. Or am I missing something? —Kusma (t·c) 07:31, 15 December 2017 (UTC)

No that's correct. If editor A had reinserted the same material without re-writing, any reverts of that would not count towards 3rr. Once it has been re-written to not be a copyvio, any reverts of that do count towards 3rr. The problem is where the rewrite is close paraphrasing it may not be a 'clear' copyright violation, which is where it should be taken to the talkpage before being reinserted. Only in death does duty end (talk) 09:00, 15 December 2017 (UTC)

Only in death and Kusma are entirely correct. If the copyright violations are cured, reversion of the rewritten text would not be exempt from 3RR. The Big Bad Wolfowitz (aka Hullaballoo). Treated like dirt by many administrators since 2006. (talk) 14:16, 15 December 2017 (UTC)

I think that much is clear. But is the re-insertion of the cured, rewritten text exempt from 1RR? --Wiking (talk) 15:53, 15 December 2017 (UTC)

Look, these hypotheticals aren't helping much. You've obviously got a specific dispute in mind; show us some diffs and we'll all tell you what's to be done about it. --Jayron32 17:02, 15 December 2017 (UTC)

I see what you mean with regards to 1rr. Editor A inserts material. Editor B removes it as an obvious copyvio (not subject to 1rr or 3RR etc). Editor A then adds material that is not a copyvio - my opinion is this would not be a revert of editor B - this is normal editorial process and how it is supposed to work. While there is an argument that because editor A is reinserting the same material, albeit re-worded, it constitutes a revert, in practice if anyone made a claim this is edit-warring, they would be swiftly told no. And as it would be the first 'revert' by editor A, it would be allowed under 1rr anyway - as the original addition of material does not count towards the 1rr/3rr count. Editor B would then be technically allowed to remove the material again under 1rr, but unless they had a good reason would justifiably be accused of goalpost moving. Only in death does duty end (talk) 17:15, 15 December 2017 (UTC)

This is a very reasonable understanding, but unfortunately it is not shared by all editors. --Wiking (talk) 17:26, 15 December 2017 (UTC)

Which other editors are you having problems with. What is the locus of the dispute? Help us help you: instead of trying to change policy, let us know what the actual problem is and see if we can't help you with that! --Jayron32 18:26, 15 December 2017 (UTC)

See User talk:Wiking#1RR and 24 hour rule; however, the actual revision history of United States recognition of Jerusalem as Israeli capital, unfortunately, is no longer accessible after Diannaa removed much of it. --Wiking (talk) 18:33, 15 December 2017 (UTC)

Adding an exemption similar to this would resolve this ambiguity:

• Reinserting material that was previously reverted due to copyright violations, summarized in a way that avoids close paraphrasing.

--Wiking (talk) 18:11, 15 December 2017 (UTC)

The copyright issue had not been addressed when I arrived at the page. Source article: https://www.haaretz.com/israel-news/1.769498

Bill Clinton declared in February 1992, at the height of the Democratic primaries, that he supported recognizing Jerusalem as Israel’s capital, a step that would alter U.S. policy. Later, during the general election campaign, Clinton attacked President George H.W. Bush for having “repeatedly challenged Israel’s sovereignty over a united Jerusalem.” He promised that he and running mate Al Gore would “support Jerusalem as the capital of the State of Israel.” Indyk, who became a Mideast adviser to the new president, recalls that “we looked at this and said – well, there had just been direct negotiations between the two parties in Madrid; do we really want to do this thing? That was our line of thinking in the first few weeks, and then the Oslo process got underway and made it even more complicated.” By 1995, the administration found itself opposing the Jerusalem Embassy Act, which was passed by wide margins in both houses of Congress, but was left unsigned by Clinton. The bill stated that the American embassy should move to Jerusalem within five years.

Content I removed:

Bill Clinton declared in February 1992, during the Democratic primaries, that he supported recognizing Jerusalem as Israel's capital . Later, during the general election campaign, he attacked President George H. W. Bush for having "repeatedly challenged Israel's sovereignty over a united Jerusalem." He promised that he and running mate Al Gore would "support Jerusalem as the capital of the State of Israel." However, the Clinton administration backed away from this promise as peace talks in Madrid and then the Oslo process got underway. The administration found itself opposing the Jerusalem Embassy Act, which was passed by wide margins in both houses of Congress, but was left unsigned by Clinton. The bill stated that the American embassy should move to Jerusalem within five years.

Overlapping portions are shown in bold. — Diannaa 🍁 (talk) 20:43, 15 December 2017 (UTC)

Yeah... that text is still a bit too close to the original for comfort. A much more substantial rewrite is needed. (Has this been done?) Blueboar (talk) 20:57, 15 December 2017 (UTC)

See, there we go. If Wiking had just told us about the exact problem we could have answered his question directly. The second attempt is still a copyvio, so it should be removed too. If he wants to add text to a Wikipedia article, he needs to learn how to create his own text from scratch, and not just copy and paste it from elsewhere. Problem looks solved to me. --Jayron32 05:45, 16 December 2017 (UTC)

Jayron hits the nail on the head. The Big Bad Wolfowitz (aka Hullaballoo). Treated like dirt by many administrators since 2006. (talk) 17:45, 16 December 2017 (UTC)

Agreed too. Since it was a copyvio both times, no issue. However, I would not interpret a good-faith attempt to solve a copyright problem, when material had been removed for that reason alone, as a "revert". Seraphimblade ^{Talk to me} 18:45, 16 December 2017 (UTC)

This is not the section that had been reverted due to COPYVIO and subsequently re-written. --Wiking (talk) 19:55, 17 December 2017 (UTC)

Ok... so please point us to the section that was. Blueboar (talk) 20:02, 17 December 2017 (UTC)

Like I said, the revision history is no longer accessible. At 18:56, 14 December 2017‎ Seraphim System removed my edit with the comment "3RRNO COPYVIO direct copy and paste from jpost article of significant language; editor warned on user talk page →‎American reactions" and at 19:43 I restored it, using the wording from LEDE of Conference of Presidents of Major American Jewish Organizations instead of quoting the source directly. Both these edits are now lost since immediately after that Diannaa hid some unrelated changes as she described above; however, on my talk page I received a warning, and after I asked for clarification, got another one, and another, with the following point: "AFAIK there is no revert exception for fixing reverts made under the exceptions. (...) You should at this point understand that this article is under a 1RR exception, that means only one revert in a 24 hour period. (...) WP:3RRNO lists the only exceptions, if your reason is not covered by one of them, it is a revert." That's what's brought me here. --Wiking (talk) 20:20, 17 December 2017 (UTC)

Ok... then do what Diannaa did... type out the original text in a quote box... and then the text you wanted to add in another... so we can compare the two and see if they are different enough. Blueboar (talk) 20:34, 17 December 2017 (UTC)

It was not close paraphrasing, I removed two one-line WP:COPYPASTEs. All an editor needs to do to avoid this is to not copy and paste material directly from sources. Any modifications to the 24 hour rule would have to be proposed at ARCA. 1RR is not implicated because in ARBPIA an editor can not restore this within 24 hours anyway. I don't think ARCA is going to carve out exceptions for editors who could have prevented the problem themselves by simply not copying and pasting. Seraphim System ^(talk) 21:50, 17 December 2017 (UTC)

Unlike Diannaa, I don't have access to the original, but like Seraphim System said, it was a copy-paste (of a sentence fragment), which was replaced with another sentence fragment that's currently in the article: "the Conference of Presidents of Major American Jewish Organizations, which comprises 51 national Jewish organizations and was founded to develop a consensus voice among Jewish organizations in dealings with the executive branch". That was literally taken from the LEDE of the linked article and could not raise any COPYVIO objections. And it didn't - I'm afraid you are getting side tracked. As I already explained, Seraphim System claimed that restoring my edit after addressing the COPYVIO issue constituted a 1RR violation, since it's not covered by any exemptions. Now he is changing that claim (even though I quoted him above). --Wiking (talk) 03:10, 18 December 2017 (UTC)

The material I removed was copied from Haaretz, and was added by Wiking to the article United States recognition of Jerusalem as Israeli capital at 8:23, December 11, 2017 (Diff of United States recognition of Jerusalem as Israeli capital). The same content was added by Wiking to the article Positions on Jerusalem at 19:48, December 11, 2017‎ (Diff of Positions on Jerusalem). At 20:33, December 11, 2017‎ a user flagged the article United States recognition of Jerusalem as Israeli capital at having potential copyvio (Diff of United States recognition of Jerusalem as Israeli capital). On 15 December I was alerted by Seraphim System that there was copyvio present. User talk:Diannaa#REVDEL? I checked the article using Earwig's tool and found the Haaretz copyvio. Seraphim system also removed this material which is still visible in the page history and which is copyvio from The New York Times. And with this edit he removed copyvio from The JTA. So there's plenty of legitimate copyvio removal. What Seraphim System removed with this edit was the wording "which represents more than 50 Jewish organizations across the range of ideologies and seeks consensus on US-Israel affairs" which his edit summary says came from the Jerusalem Post (he does not give a specific url as the source and I can't find it online). If your replacement prose "which is comprised of 51 national Jewish organizations and was founded to develop a consensus voice among Jewish organizations in dealings with the executive branch" is still present in the article, as none of Seraphim System's (or anyone else's) subsequent edits removed it. — Diannaa 🍁 (talk) 05:00, 18 December 2017 (UTC)

Thanks for providing the prior version, and yes, my edit is still present, and per Seraphim System, it was a revert of his revert, which violated 1RR, and that's exactly what we are discussing here. --Wiking (talk) 05:11, 18 December 2017 (UTC)

To put it another way: He removed suspected copyvio, you re-worded and re-added the content. Seraphim System then warned you that adding the amended content was a violation of the editing restrictions on the page. So your question is, was this a valid warning? Adding: If it's a valid warning under the current wording of the policy, should the policy be amended to make it such that adding replacement prose for a removed copyvio is an exempted action? — Diannaa 🍁 (talk) 05:27, 18 December 2017 (UTC)

Exactly. --Wiking (talk) 05:29, 18 December 2017 (UTC)

If you look through the edit history there had been seven reverts in 3 days, this is after I politely notified you of the editing restrictions. Maybe I did want to remove it - even though I claimed 3RRNO, it was my only revert that day. I have to claim 3RRNO, in the event that there are further violations, to avoid sanctions myself. I was in the process of filing a complaint for both 1RR and the 24 hour rule - The only reason I didn't go to ARBCOM is because you had not received a DS warning - incidentally, this is not the first time you have evaded sanction at ARBCOM because an editor forgot to template you. Wikipedia:Arbitration/Requests/Enforcement/Archive188#Wiking - you are not a new editor, you are already familiar with these rules. Seraphim System ^(talk) 05:41, 18 December 2017 (UTC)

What I am wondering is are you asking this question here because you think you will be copying and pasting more content in the future? I will point out that Diannaa has already confirmed that copying and pasting is a COPYVIO, and a formal warning about COPYVIO was given to you by an admin. Seraphim System ^(talk) 06:05, 18 December 2017 (UTC)

I've asked you multiple times to stop reading my mind and telling me what I know, what I am familiar with, etc. Once again, let's stay on topic here and not discuss what I may or may not know. I am asking this question here because either the policy or your interpretation of the policy made no sense to me, and I felt that you were abusing it. It would be preferable if it was clarified so that you had no opportunity to abuse it against less experienced editors in the future, whoever they may be. If an inadvertent COPYVIO occurs and is reverted, it can and should be corrected as soon as possible rather than after some delay imposed by you under the threat of sanctions for 1RR violation. --Wiking (talk) 16:15, 18 December 2017 (UTC)

As touching as your concern for inexperienced editors is, you are not a new editor and you are expected to be able to understand what a 1RR restriction means. Your desire to reinsert your content without delay is precisely why we have editing restrictions on these articles. Additionally, it wasn't only one COPYVIO, it was at least three that I have found on this article alone. You have been editing since 2009. Based on my interaction with you and the repeated polite informal reminders I took the time to give you and continued argument and violations that followed those reminders, I feel comfortable bringing this to AE if the disruption continues, where they can clarify the meaning of 1RR and issue a formal warning if it is necessary, Seraphim System ^(talk) 00:57, 19 December 2017 (UTC)

Like I said, it was your abuse of the literal interpretation of the 1RR rule that brought me here in the first place. I do not see anyone else agreeing with your interpretation. You can take your case wherever you'd like, but it may result in self-inflicted sanctions. --Wiking (talk) 03:04, 19 December 2017 (UTC)

@Jayron32, Only in death, Hullaballoo Wolfowitz, Blueboar, and Seraphimblade: Since you were waiting the the specifics, was hoping to hear from you, especially since the issue has not been resolved. I received yet another warning, this time for changing "American reactions" to "Domestic reactions" - so, apparenly, my opponent believes that editing any part of the text is considered a revert since it changes it from the original form, and in this case, bringing up a completely unrelated change made in a different section four days earlier, and therefore claiming that it was my second revert and a 1RR violation. Similarly, when he removed an important and properly sourced detail from the LEDE and I, upon realizing that it was not mentioned in the article elsewhere, restored it in the background section, he considered this to be a revert as well. It seems that we need a narrower definition of what's considered a revert, with exemptions covering these cases. --Wiking (talk) 16:50, 20 December 2017 (UTC)

No longer care... I have come away with the impression that everyone involved with this is “wikilawyering”. Suggest both Wiking and Seraphim go and edit some other articles for a while. Blueboar (talk) 20:56, 20 December 2017 (UTC)

Blueboar (talk · contribs) As long as there are no more COPYVIOs I don't care either, but a proposal that an editor inserting repeated COPYVIOs into an article should be given special leniency under the ARBPIA editing restrictions is clearly disruptive. If it was serious, it would have to be proposed at WP:ARCA. I don't think you are suggesting that I should have left COPYVIOs in the article. Seraphim System ^(talk) 22:38, 20 December 2017 (UTC)

That was not the proposal. The proposal was that curing previously reverted COPYVIO should not be considered a revert, as it was not the intent of 3RR or 1RR. --Wiking (talk) 22:43, 20 December 2017 (UTC)

The best thing to do would be to discuss it with the editor and agree on a rewording together. I did not want to rewrite it because the previous night I was dragged into AE for correcting an obvious error, and reverting a 1RR violation. I was told to bring further 1RR violations directly to AE. I did not rewrite it because I thought rewriting a COPYVIO would be considered a revert, though I see from comments here that the rewrite would fall within 3RRNO as well. I will do this next time, but I think the best thing is to try to reach an agreement first in ARBPIA, where even one-word reverts can escalate into edit wars. That is why we have editing restrictions in this topic area. Seraphim System ^(talk) 23:09, 20 December 2017 (UTC)

I'm glad that you no longer consider a rewrite to be a violation of 1RR or 3RR. If something was removed solely due to COPYVIO, it can and should be re-written and does not require further discussion in ARBPIA or elsewhere. If you revert something for a different reason, next time state the proper reason behind your objections, besides COPYVIO, and we will follow the established protocol. --Wiking (talk) 23:25, 20 December 2017 (UTC)

P.S. I still think that a rewrite warrants its own exemption, since even an experienced editor such as you are can misinterpret the current 3RR rule. --Wiking (talk) 23:27, 20 December 2017 (UTC)

The last time I checked, which was a while ago, the so-called "3RR" policy was written so that any three non-consecutive edits counted for the person trying to add material, because it doesn't matter whether your attempt to add content involved the same or different material. So if, for example, you add "foo" to the lead, and I revert it, and add an image to the first section, and I revert it, and you fix a spelling error in the last section – then that's three "countable" edits against you, because your three unrelated additions have "undone" the previous editors' choice to omit foo from the lead, to not have an image in the first section, and to put a spelling error in the last section.

The justification, when I asked, was that No Good Editor would ever abuse this, but that various Bad Editors would wikilawyer over whether trying to add the same bad content, in different places or with different words, were actually "edit warring". I am uncomfortable with this. If you don't want to get bit by aggressive enforcement of the written rule, then you will want to avoid making three or more non-consecutive series of edits to any page in any day (three, not four, because if your third edit series ends in an edit conflict, then you will have accidentally ended up with four "reverts"). WhatamIdoing (talk) 18:37, 22 December 2017 (UTC)

That doesn't at all match the policy I see at WP:3RR. The key is that a revert is defined as "any edit (or administrative action) that reverses the actions of other editors, in whole or in part, whether involving the same or different material".

• The initial edit adding "foo" wouldn't be a revert unless someone just removed "foo" (or something similar) recently. Otherwise it's not reversing the action of another editor.
• Adding an image wouldn't necessarily be a revert either, although it gets more murky here since it in part depends on whether adding the image is considered reverting the removal of "foo". It would probably depend on the details of the specific situation.
• And fixing a spelling error almost certainly isn't a revert. Unless it's something crazy like warring over a {{sic}}, maybe.

It seems to me that whoever gave you that justification was radically off base. Anomie⚔ 23:37, 22 December 2017 (UTC)

"Radically off base" was my opinion, too, but the admin was absolutely convinced of his correctness, and the efforts of multiple people, including myself, to clarify the policy, especially the definition of whether "reverting" had anything to do with returning any part of the article to a previous state, were rejected. We also didn't get anywhere with the idea that completely unrelated edits on the same page should probably not be considered edit warring, although the policy explicitly says that they are (that's the point of the "different" language: if editors disagree in one section but work constructively in another, then their constructive edits can be declared to be part of an edit war). If you're interested in wiki-history, then Wikipedia talk:Edit warring/Archives/2013/November might be one of the most pointful discussions (there were at least half a dozen), but, lest anyone think that this is just about one person, you will also want to see, e.g., Wikipedia talk:Edit warring/Archives/2014/June#Edit wars and single edits by third persons, in which a different editor asserts that it is accepted practice for a single edit(!) to sometimes be construed as edit warring.

Note that reverting isn't timebound, so your qualifier of "recent" in the first point is not correct. If you go to a high-traffic article tomorrow, and pick out four unrelated weak edits from years ago, and revert them one at a time over the course of the day, making sure to let other editors save an edit in between each, then you will have broken 3RR, even if everyone agrees that you have improved the article. It does not matter that they were all made years ago, that they were unrelated changes, that the article is better now, or that making exactly the same four edits in rapid succession, so that nobody else has a chance to edit in between, is perfectly legal. That's a 3RR violation. WhatamIdoing (talk) 07:55, 27 December 2017 (UTC)

I agree with Anomie. Like I stated before, see the Definition of "Revert" and "Undo", "Does Change = Revert?" and Disastrous discussions; as seen by reading those discussions, the definition of a revert has been discussed a lot. Despite a few interpretations that a revert means any change to an article, the vast majority of editors, in my experience, do not interpret a revert in that way. If a revert actually meant that, it would mean that if I went to an article right now and started editing it, I'm making a bunch of reverts and would be over the WP:3RR limit in a matter of minutes. Flyer22 Reborn (talk) 01:35, 28 December 2017 (UTC)

I hope and believe that "the vast majority of editors" agree with us.

But "the vast majority of editors" does not seem to have been able to get the policy written so that it directly says anything like "a revert does not mean just any old change to an article", and therefore so that "the vast majority of editors" can force those "few" to stop enforcing their "any change [that I don't like] is a revert" interpretation of the policy.

(Even under this extreme interpretation, you don't violate 3RR that often. It's not edits; it's series of edits. For example, you made four edits at Dave Coulier a few minutes ago, but that's only counted as "one" for 3RR purposes, because nobody else made any edits in between yours). WhatamIdoing (talk) 18:51, 28 December 2017 (UTC)

Debating this is silly. It always is. Editors interpret our policies and guidelines differently, but they are usually in agreement on their interpretations and they usually have common sense. Our editors, including our administrators, know what a WP:3RR violation is when an edit warrior is reverting me and another editor and crosses the WP:3RR line while I and the other editor have not crossed it. The administrator is not going state that I and the other editor also violated 3RR because we edited an unrelated part of the article within those 24 hours. One administrator acting in a rogue manner by interpreting the policy in a way that editors usually do not interpret it will not change that. And that administrator can be brought to WP:AN or WP:ANI if he or she continues to apply the policy in such a way. Any argument at those venues that the policy supports the administrator's viewpoint would be dismissed if a pattern of applying the policy in this problematic way was made clear. Do it once, and the administrator can slide (with admonishment, of course). If the administrator continues to do it, the behavior will be stopped. Flyer22 Reborn (talk) 19:32, 28 December 2017 (UTC)

This recent explanation (at the bottom of the discussion) by NeilN shows how administrators should be interpreting WP:3RR. Flyer22 Reborn (talk) 16:09, 30 December 2017 (UTC)

Pre-RfC discussion at NCORP

If you like please comment on proposed language to raise NCORP standards. I intend to launch an RfC Jan 7th and am looking for any refinements beforehand. Please see Wikipedia_talk:Notability_(organizations_and_companies)#NCORP_standards,_continued. Thx Jytdog (talk) 18:03, 29 December 2017 (UTC)

Much needed change. Doc James (talk · contribs · email) 08:50, 31 December 2017 (UTC)

RfC on capitalization of traditional (non-trademarked) games and sports

FYI

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style/Capital letters#RfC: Capitalisation of traditional game/sports terminology. The question is "Should names of traditional games and sports, and of game-play items and other terminology associated with them, be capitalized?"  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  01:48, 2 January 2018 (UTC)

BLP proposal

Opinions are needed on a proposed change in how the Biographies of living persons policy addresses disputed content. Please leave comments at Wikipedia talk:Biographies of living persons § Disputed content. Thank you. —Sangdeboeuf (talk) 18:57, 2 January 2018 (UTC)

RfC on naming of Chinese railway line articles

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.

---

See also: § RfC: Russian railway line article titles

How should the titles of railway line articles for Mainland China and the high-speed railway in Hong Kong be named? Jc86035 (talk) 09:29, 11 November 2017 (UTC)

Background (naming of Chinese railway line articles)

Most article titles for Chinese railway lines follow the structure "Place 1–Place 2 Railway" or similar, though they have been inconsistently named and the naming guideline is probably a reflection of the state of articles rather than a fully consensus-based system. However, Dicklyon has recently renamed or made RMs for a number of railway lines to decapitalize them. (According to this PetScan query, out of about 270 railway lines and former railway companies, 174 are named with "Railway" and 86 are named with "railway". Dicklyon renamed all 86 of the latter this week.) Their naming should be based on reliable sources per MOS. A mix of non-capitalized and capitalized is used by sources for the more well-known high-speed railways, but more than 90% of sources use the capitalized form for the Guangzhou–Shenzhen–Hong Kong Express Rail Link (but a mix when the line is referred to as just the "Express Rail Link" or "express rail link"), and most news articles for the Beijing–Tianjin Intercity Railway use the capitalized form unless they refer to it without the phrase "intercity railway" e.g. "Beijing-Tianjin intercity route". There are very few English-language sources about the slow railways; 3 news sources use "Beijing–Kowloon Railway" and one source uses "Beijing–Kowloon railway", while others use "Beijing–Jiujiang–Kowloon [Rr]ailway". (Almost all passenger and freight lines in China are operated by China Railway and its subsidiaries, so it would probably be odd to capitalize them differently entirely based on the inconsistent capitalization of sources.) Further investigation is probably needed.

In addition, some articles are named in their abbreviated form, using only one Chinese character from each place name (e.g. Guangshen Railway instead of Guangzhou–Shenzhen Railway). Sources about high-speed lines usually use the long form. Most news articles about the Guangzhou–Shenzhen [Rr]ailway are actually about the subsidiary of China Railway which operates it, which is named with the abbreviated form. (The railway itself seems to never be in the news.) Most Google results for "Jingjiu railway" [Beijing–Kowloon] are Wikipedia articles; sources generally use the long forms. There is some old discussion in the archives of Wikipedia talk:Naming conventions (Chinese) which indicates that the long form should be used for clarity, although the highways also addressed by the naming convention have always been named using the short form (e.g. Guangshen Expressway).

Some articles are also named "Passenger Railway" instead of "High-Speed Railway". This is a result of the official Chinese names being literally translated; most English-language sources avoid "passenger railway" probably for clarity, although it's also possible that they used Wikipedia's article titles.

Note that my observation is probably incomplete and more web searches will be needed.

		A	B	C
Should the railway line articles be named with a capitalized "Railway"?	1	capitalized	not	case-by-case (i.e. based entirely on sources)
Should the railway line articles be named with the short or long form?	2	short	long	case-by-case
Should the railway line articles be named high-speed railway or passenger railway?	3	high-speed	passenger	case-by-case
Should the railway line articles be named intercity railway or passenger railway?	4	intercity	passenger	case-by-case
Should closed/historical/heritage/narrow-gauge railway line articles (e.g. Gebishi Railway, Jiayang Coal Railway) be named the same way as open railway lines operated by China Railway?	5	yes	no	case-by-case
Should the current and former railway company articles be renamed to match the line articles?	6	yes	no	case-by-case
How should railway lines with termini in Tibet and Xinjiang etc. be named?	7	Mandarin-derived name	local name	case-by-case

Survey (naming of Chinese railway line articles)

• 1B, 2B, 3A, 4A, 5C, 6B and 7C. (I am the RfC initiator.) Jc86035 (talk) 09:38, 11 November 2017 (UTC)

  See WP:JUSTAVOTE; why do you support those options?  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  13:31, 11 November 2017 (UTC)

  @SMcCandlish:

  • I am the initiator so my reasoning for 1B and 2B is largely outlined in the section above.
  • This needs to be double-checked, but 3A and 4A are sorted this way because the Chinese government seems to officially name high-speed lines "客运专线" (literally, "passenger dedicated line"). Some Chinese Wikipedia articles are named that way; others use "高速铁路" ("high-speed railway"). I don't know why. I have corrected "passenger line" to "passenger railway" since it is probably an editor's translation of the same phrase.
  • I !voted 5C since heritage railways may or may not be state-owned and thus may be named using a different system. Similarly, the name may be translated differently.
  • I !voted 6B since the company name does not need to be the same as and has little to do with the railway name; it would be a little like renaming c2c because the railway it operates on isn't called the c2c railway. The only operator for which this applies is Guangshen Railway (company), and the company is publicly listed internationally so it has an official English name which we don't need to change. The other operator [with an article] is Daqin Railway (company), which operates over multiple lines which are mostly not named the Daqin Railway. To be honest, this doesn't actually have much to do with the rest of the RfC, so maybe it could be removed.
  • I !voted 7B since the Chinese government apparently has an tendency to pretend that ethnic groups in the autonomous regions don't exist and only installs English-language signage based on the Mandarin Chinese transliteration rather than signage based on the Tibetan or Uyghur names. I've changed my preference to 7C.

  Jc86035 (talk) 15:30, 11 November 2017 (UTC)

• Remove WP:NC-CHINA#Transport as a bunch of no-consensus WP:CREEP – do not expand it further with this stuff. Not only does it directly conflict with site-wide guidelines like MOS:CAPS and WP:NCCAPS, it is not actually addressing anything unique to China and is thus off-topic – just one wikiproject PoV-pushing a bunch of trivial nit-picks without consensus. I checked – there was no discussion at WT:NC-CHINA about adding any of that material, and it's just someone's opinion, i.e. a mis-placed WP:PROJPAGE essay. It's also unnecessary (as I demonstrate below), because we already have title and sourcing policies, basic naming conventions, and style guides that result in usable article names simply by following them. I'm a huge fan of consistency within reason, but this RfC is just ridiculous. In case this nonsense is kept, I've answered the RfC questions below, with actual rationales, based on site-wide rules and advice.

Details, by number:

1B, 2C (2B by default), 3C (3A by default), 4C (4A by default), 5C (5A by default), 6C (6A by default), 7C (7A by default). Reasons: 1A is not actually an option (per MOS:CAPS, WP:NCCAPS, WP:NOR). 2C (2B by default) because these are usually descriptive names, in translation, so should be descriptive, but in the case that one is a proper name, use that. 3C per follow the sources; the choice doesn't even make sense, since "high-speed" and "passenger" are not synonyms and there are passenger lines that are not high-speed; if the railway is high-speed, use that by default as more descriptive. 4C (4A by default) per follow the souces; the choice the nom offers is another false equivalence, as there are passenger lines that are not intercity; for an intercity case, that word is more descriptive; but use whatever a proper name actually translates as. 5C (5A by default) per WP:CONSISTENCY policy, with allowance for a [translation or transliteration of a] proper name that doesn't fit the format. 6C (6A by default) per WP:CONSISTENCY and because not doing it (absent unusual proper name exceptions) invalidates the whole point of the RfC to settle on a consistent naming convention. It's utterly baffling that the nominator would pick 6B. 7C (7A by default) per COMMONNAME and follow the sources. Important note: "I saw it on a sign" does not equate to "proper name"; signs are primary sources self-published by the agency in question, and are written in an intentionally compressed fashion; they are not natural English. And the agency's own publication cannot be used to "style-war" for overcapitalization or other quirks, since WP doesn't follow external house style of random other organizations, and these names aren't in English anyway.

This kind of instruction creep is problematic, because if even a few topical-interest wikiprojects did something like this, MoS page by MoS page as WP:TRAINS has been trying to do, then a page like MOS:CHINA would be so long no one would read or follow anything in it. We should have no MoS rules other than those that address points of style and usage that editors have repeatedly had raucous conflicts about (or which address internal, usually technical, requirements) and which are not adquately addressed by existing WP:P&G pages. MoS/AT material is not a style guide for the public but an internal problem-solving tool. Every new rule added that isn't actually needed is just a reduction in editorial leeway and pisses people off.
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  13:31, 11 November 2017 (UTC)

@SMcCandlish: The last discussion about railways at Wikipedia talk:Naming conventions (Chinese) was more than six years ago. There probably aren't enough active editors to form a consensus, other than through the RM process (which probably isn't as widely trafficked as this page). I agree that some of these didn't really need to be in the RfC, but it made sense to ask them all at the same time to have a sort of more solid precedent than a RM from 2009 which ended in no consensus. It's a bit of a stretch to say that building consensus on these things is "instruction creep" and "ridiculous", since these are all (well, 1 to 5, anyway) points of inconsistency between article titles which no discussion has managed to sort out in the last decade.

I am also proposing this independent of the guideline and do not really care whether or not the guideline is changed to reflect it; I should have clarified this. I am fine with removing the guideline's section, since it only serves to reflect the status quo and has its own problems like introducing infobox title inconsistencies. Jc86035 (talk) 15:30, 11 November 2017 (UTC)

It's actually worse than that; it's a WP:POLICYFORK that contradicts the main guidelines on capitalization, among other problems.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  15:36, 11 November 2017 (UTC)

@SMcCandlish: Would it be acceptable to notify the Chinese Wikipedia of this RfC, or would that be canvassing? Jc86035 (talk) 04:28, 13 November 2017 (UTC)

I wouldn't. This doesn't have anything to do with what's done in Chinese, and zh.WP doesn't share our style guide.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  05:10, 13 November 2017 (UTC)

• Mixing style guidelines with naming conventions – 1B usually, since we have site-wide consensus represented in WP:NCCAPS and MOS:CAPS to reserve caps for proper names, typically as determined by consistent capitalization in sources, and these are pretty mixed in sources as nom notes. No new guideline or instruction is neeeded; see my RFC a few sections up where nobody disagrees with following these central guidelines. For the rest, these are more like project naming conventions; I agree there are some consistency improvements that would be useful. In terms of the current state, I started with downcasing "XXX High-Speed Railway", and then "XXX Intercity Railway" after studying sources about those. I would plan to look next at "XXX Passenger Railway" and plain "XXX Railway". In many parts of the world, the latter form is typically referring to a company, and is capped, while the railway infrastructure is called a "line". So I need to look at what's going on here. Any help you care to offer will be appreciated. Dicklyon (talk) 17:02, 11 November 2017 (UTC)

Comment It is a proper name in Chinese and just lost in translation in English and by grammar it should be capitalised (the Chinese government had a system to name it, does not mean it is not a proper name, such as the First Bridge of "Long River", the Frist Road of People, or People East/West/North/South Road. Or Shenzhen Airport. Beijing International Airport. Matthew_hk tc 03:24, 13 November 2017 (UTC)

@Matthew hk: I don't think this is necessarily the case, as English grammar norms are a little different from those of Chinese. For example, the zhwiki article for Shenzhen is called 深圳市 (Shenzhen City), but our article is titled simply Shenzhen because we don't consider "City" to be part of the proper name and it's not necessary for disambiguation. Jc86035 (talk) 04:28, 13 November 2017 (UTC)

Yep.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  05:10, 13 November 2017 (UTC)

What I saw is wikipedia screw with no sense that Australia use English language and capitalize Fremantle Line [8] in their webpage and the wiki lower cap them. Matthew_hk tc 06:06, 13 November 2017 (UTC)

Yes, we "screw with" some of their styling, since they're not even consistent (see [9]) and since we go by secondary sources. Dicklyon (talk) 06:35, 13 November 2017 (UTC)

And more citation on Chinese railway: Hsü, Immanuel C.Y. The Rise of Modern China. Oxford University Press., a history book written in English (by a guy with Chinese surname publish by a reputable university press) use Wade–Giles, uses Peking-Hankow Railway, Canton-Hankow Railway Matthew_hk tc 06:46, 13 November 2017 (UTC)

He also has "Fengtien-Peking and Tientsin-Pukow railways", which would seem unlikely if their proper names were Fengtien-Peking Railway and Tientsin-Pukow Railway. Things like "Southern Manchurian Railway track" that he has make more sense, as referring probably to the company South Manchuria Railway Company as opposed to the line. Anyway, he has a style, but it's not WP style. Dicklyon (talk) 03:16, 6 December 2017 (UTC)

Here I will comment that there is no such thing as a "South Manchuria railway" as a single line. The South Manchuria Railway operated a number of lines, of which none were called the "South Manchuria Line". For the record, they were called the Lianjing Line (Dalian–Xinjing/Changchun), the Anfeng Line (Andong/Dandong–Fengtian/Shenyang), and the Jincheng Line (Jinzhou–Chengzitong).2Q (talk) 03:35, 19 December 2017 (UTC)

Comment: If we in proper English capitalise "Hollywood Boulevard" or "Fifth Avenue" or "Crescent City" or "Brooklyn Bridge", then these cases of railways wherein 'Line' is part of the proper name need to be capitalised too. Though I'm thinking more specifically of Korea and Japan, but applicable elsewhere too, including China. Secondly, there are/were numerous railway lines in Hamgyeong Province, or in the Tohoku region ... saying "Hamgyeong line" (or "Tohoku line" etc) is not specifically referring to any of said lines, whereas "Hamgyeong Line" ("Tohoku Line" etc) is specifically referring to the one line that is commonly known by that name.

I know in China railway lines are called 鐵路 (railway) and not 線 (line), but I'd say the same thing applies. Proper names are capitalised, this is a basic and universal rule of English orthography. 2Q (talk) 02:04, 27 November 2017 (UTC)

• Avoid instruction creep. (Basically "C" in all cases above [where not in conflict with MOS:CAPS, etc.].) WP guidelines aren't for us to neatly order the lamentably inconsistent real world; they are created as a last resort to help editors focus on improving articles rather than waste time endlessly bickering about small things without resolution. Here, I don't see a long-standing ongoing conflict that needs some WP guideline to come down and make decisions for us. Especially in this RfC, where we are asked to !vote on a list of different rules for different small sub-subjects. This requires anyone commenting get detailed knowledge for each separate issue, which an RfC is the worst way to achieve. I'd close this RfC as a bad idea no matter what the outcome. (Maybe start a separate RfC for each issue where needed.) --A D Monroe III^(talk) 16:12, 30 November 2017 (UTC)

Korea exception?

Is Korea different from China? I started downcasing a few lines in Korea, but got reverted by 2Q. See discussion at User talk:Dicklyon#Undid page moves. The argument seems to be that since Korean and maybe other Asian languages have no analog of capitalization, and even though there's not consistent capping in English-language sources, we must nevertheless treat these line names as proper names. Anyone buy that? Dicklyon (talk) 03:31, 29 November 2017 (UTC)

Not on your life; the fact that CJK scripts have no case distinction means we absolutely should use lower-case here because our translations of them are just approximations and thus cannot be their proper names. We have the same rule when it comes to translating titles of published works: the translations go in sentence case. (However, the English-language title of an English-language edition of a book, or English-dubbed/subtitled English-language-market release of a film, or traditional English name of a famous artwork, goes in title case.)  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  13:31, 29 November 2017 (UTC)

I don't see how the Korean language has any influence here. Per COMMMONNAME, The naming we follow is based on English, not uses in other languages; we don't call Germany Deutschland. If English sources cap it, then we should, especially when the native official language has no caps. I'm sure the French Wikipedia doesn't look to English sources to determine if "Basketball" is a masculine or feminine noun, a concept English doesn't have. --A D Monroe III^(talk) 15:39, 30 November 2017 (UTC)

In User_talk:Dicklyon#South_Manchuria_Railway, User:2Q makes a case for capping "Line" for Japan and Korea lines. It makes more sense than I've seen elsewhere (more than for the NYC subway lines, for instance). Comments? Dicklyon (talk) 06:06, 17 December 2017 (UTC)

US or NYC exception?

There is also some pushback on capitalization normalization of "Line" in New York, in spite of sources using lowercase a lot. See ongoing RM discussion at Talk:IRT_Lexington_Avenue_Line#Requested_move_17_November_2017. The notification of the project has brought in some local opposition based on their longstanding practice of capping "Line". Dicklyon (talk) 16:30, 29 November 2017 (UTC)

Hong Kong exception?

I've downcased the majority of Chinese XXX Railway articles, and working away on them; a few seem to be consistently capped in sources, and a few have a little pushback for other reasons (2Q also comments on some of those). But it's when I mess with things that get into Hong Kong that I find more pushback, especially on downcasing Station (e.g. see Wikipedia_talk:WikiProject_Hong_Kong#Railway_and_Station_capitalization and User_talk:Dicklyon#Why_are_you_even_allowed_admin_tools?). And I continue to get random comments from the banned/sock Russia anon for my work there, sprinkled into some of these conversations. I'm going to hold off on Japan and Korea, go slow on Hong Kong, and see how things go as I try to finish up China. Comments? Dicklyon (talk) 06:06, 17 December 2017 (UTC)

On the Hong Kong MTR stations, I've opened a mulit-RM discussion: Talk:Hung_Hom_Station#Requested_move_17_December_2017. Dicklyon (talk) 16:55, 17 December 2017 (UTC)

Strong opposition and motion for reconsideration

As the creator or editor of the vast majority of China railway articles in English Wikipedia, I am appalled and deeply dismayed that this de-capitalization exercise was undertaken with little to no input from the editors who are familiar with the content of this subject area and laid down the conventions for article in naming, as a means to help readers identify the articles they are reading and editors to help expand the subject area.

First, the naming convention which I proposed and was adopted in 2011 after significant discussion with other China railway editors, has worked. See Archive 11 (reproduced below). Until Dickylyon started de-capitalizing high-speed railway names, virtually all articles about particular railways in China had "railway" capitalized in the same way that Great Western Railway, Trans-Siberian Railway and Union Pacific Railroad have railway/railroad capitalized in their names. The capitalization signifies that the article name is referring to a particular railway, and the names of particular railways are proper nouns. Per MOS:CAPS, proper nouns are capitalized.

This section is weirdly broken and not editable, having sections inside the collapsed part. How about a link to the relevant archive instead? And did these proposals ever get adopted or documented any place, or just discussed? Dicklyon (talk) 05:16, 20 December 2017 (UTC)

And trying to edit sections after this also doesn't work so well; the edit button usually leads to the wrong section number. Dicklyon (talk) 05:53, 20 December 2017 (UTC)

I think I've fixed the problem. Someone say if that's not true. - dcljr (talk) 05:48, 3 January 2018 (UTC)

The 2011 discussion and consenus

For article names of Chinese railways, replace transliterated shorthand names with hyphenated full names Under the current naming convention, Wikipedia English article names of Chinese railways (and expressways) follow the shorthand Chinese character names for these railways (and expressways) transliterated into English. For example, the Beijing-Shanghai Railway is named Jinghu Railway, after the shorthand of the Chinese name for this railway, 京沪铁路. Jing is the pinyin tranliteration for 京, the character used in Chinese as a shorthand for the city of Beijing. Hu is the pinyin transliteration for 沪, the character used in Chinese as a shorthand for the city of Shanghai. Beijing and Shanghai are the two terminal cities on the railway. For ease of reference, let’s call Jinghu Railway the “transliterated shorthand name” and the Beijing-Shanghai Railway, the “hyphenated full name”. The transliterated shorthand name, while seemingly faithful to the Chinese naming method, is not helpful or effective for most English Wikipedia readers and fails to satisfy most of the objectives under Wikipedia’s article naming convention, which are recognizability, naturalness, precision, conciseness and consistency. This naming convention should be replaced by hyphenated full names of Chinese railways, which has the two terminal location references (usually cities but also could be provinces) of each railway fully spelled out and connected by a hyphen. This hyphenated name should be followed by “Railway”, capitalized because the name of each Chinese railway is a proper noun. The transliterated shorthand name could be mentioned in the article and could have a redirect link, but should not be the primary article name – for the following reasons: Recognizability – an ideal title will confirm, to readers who are familiar with (though not necessarily expert in) the topic, that the article is indeed about that topic. The names of most railways in China, regardless of naming method, are not familiar or recognizable to most English Wikipedia readers. When this is the case, the more descriptive name will make the railway more identifiable. For example, most English readers are unfamiliar with, say, the railway between Chengdu and Chongqing, but between Chengyu Railway and the Chengdu-Chongqing Railway, they’re much more likely to identify the latter as the railway between the two cities. As of April 22, 2011, articles for only a handful of railways in China have been created and named with the transliterated shorthand name method. Most of these articles are for railways that many bilingual (Chinese and English) readers can recognize, such as the Jinghu, Jingguang, Jingjiu, Jingbao Railway, so the naming convention appears to be fine. Yet, once we expand the article coverage to railways that are less well-known, recognizability of names will diminish. Railways like the Funen, Kuybei, Qibei, Nenlin, are likely to be as obscure to the English reader as they are to the bilingual reader. As the number of articles proliferates, the article names will become progressively more difficult to recognize and tell apart. Try telling apart the following railways: Fuhuai, Fuxia and Funen. Part of the difficulty is that the transliteration method obscures differences in Chinese characters and Chinese tones that help to pick apart some of those names, such as 阜淮, 福厦, 富嫩 in the riddle above. Compared to the shorthand names, Fuxin-Huainan, Fuzhou-Xiamen, and Fuyu-Nenjiang, are more recognizable. With pinyin transliteration from Chinese to English, considerable detail and discerning information is lost. Consider more examples: Xiangyu, Xianggui, Xiangpu Railways all have different “Xiang” characters; Baolan and Baocheng Railways have different “Bao” characters; Jiaoji and Jitong Railways have different “Ji” characters; Jiaoji and Jiaoliu Railways have different “Jiao” characters Jitong and Tongpu Lines have different “Tong” characters; Lanxin and Lanyan Lines have different “Lan” characters; Qibei and Ningqi Lines have different “Qi” characters; Tongjiu, Tongpu, Jitong Railways have different “Tong” characters Xianggui and Guikun Lines have different “Gui” characters; Yiwan and Wangan Railways have different “Wan” characters; Yiwan, Yijia, and Xinyi Lines have different “Yi” characters; Yuli and Licha Railways have different “Li” characters; Many English readers may be unfamiliar with one-character abbreviations of Chinese cities and provinces that are commonly used in Chinese shorthand names for railways, Hu for Shanghai, Yu for Chongqing, Rong for Chengdu, Ning for Nanjing, Yong for Ningbo and Jiu for Kowloon. Compare Beijing-Kowloon Railway with Jingjiu Railway. Just when you thought Jing stood for Beijing, there is Jingsha Railway, between Jingmen and Shashi in Hubei Province. Part of the difficulty is that the Chinese method itself is vulnerable to confusion due to the repetition of the same characters used to describe different location. Consider Changda (长大), Xinchang (新长), and Daqin (大秦) railways. These three lines have two pairs of Chang and Da characters in common but those two characters refer to four different cities: Changchun, Changxing, Dalian and Datong. When these homographs characters are transliterated into the English, the confusion they cause is compounded by their homophone characters. Joining the Da (大) railways, e.g. Daqin (大秦) and Dazheng (大郑), are the Da (达) railways – Dacheng (达成) Dawan (达万) Railway. Joining Chang (长) railways are other Changs such as (昌), as in the Changjiu (昌九) Railway. Naturalness – refers to the names and terms that readers are most likely to look for in order to find the article (and to which editors will most naturally link from other articles). How are the names of Chinese railways referred to in English publications? A search in the English news articles for Beijing-Shanghai Railway yields hundreds of results. A search for Jinghu Railway yields few to no results. In everyday use, when an English writer wants to identify a Chinese railway in English prose to an English reading audience, he/she is much more likely to use the hyphenated full name approach than the transliterated shorthand name approach. Precision – titles are expected to use names and terms that are precise, but only as precise as is necessary to identify the topic of the article unambiguously. Not surprisingly, the hyphenated full name is more precise and less prone to confusion than the transliterated shorthand name. For example, does Xinyi Railway refer to the railway between Fuxin and Yi County (新义铁路) or the railway of Xinyi (新沂铁路), which goes to Changxing? What about the Ningwu Railway, is it one of the railways that originates from Ningwu or the Nanjing-Wuhu Railway, whose transliterated shorthand is also Ningwu? Conciseness – shorter titles are generally preferred to longer ones. This is the only consideration where the transliterated shorthand name appears to have the edge. But this objective is far outweighed by others consideration. The hyphenated full name is hardly long by Wikipedia article name standards. Furthermore, as a rule, in Wikipedia, we do not use abbreviations as article names. Why adopt Chinese abbreviations as the official English names? Consistency - titles which follow the same pattern as those of similar articles are generally preferred. As noted, news articles about railways overwhelmingly follow the hyphenated full name approach. Among China’s high-speed railways, the majority also following the hyphenated full-name approach, because this approach delivers more identifying information and is less prone to confusion. It’s time to make the English article names of Chinese railways consistent, clear and descriptive. The need for hyphenated full names for Chinese railways is more pressing than it is for Chinese highways. Whereas railway names are stable, highways in China frequently have their names changed as expressways are lengthened and numbering systems are adopted. As an encyclopedia, we want to present seemingly complex information to readers in a way that is clear and consistent and easy to understand and follow. Under the hyphenated full name approach, readers can tell right away, what the two terminal cities of any railway are, and if they can recognize one of the two cities, be able to orient the railway. They will be able to tell that the Nanjing-Xian (Ningxi), Nanjing-Wuhu (Ningwu) and Nanjing-Qidong (Ningqi) Railways do not originate from the same city as the Ningwu-Kelan (Ningke) and Ningwu-Jingle (Ningjing) Railways. For consistency and clarity, Wikipedia article names of Chinese railways should always feature the full names. In-article references can use transliterated shorthand names. The only exception may be the Longhai Line, which has become a two-character word in itself. The reason for this lengthy argument is because prior attempts to convert transliterated shorthand article names into hyphenated full names have been reversed with reference to the naming convention. ContinentalAve (talk) 15:14, 22 April 2011 (UTC) I will refuse to agree to anything regarding railways unless something is done to expressways as well. Since expressways follow about the same convention, with the only conceivable difference being the addition of the "G__" numbering system, it makes little sense to have 2 separate conventions. Also, I am pretty sure that you fell for the pitfall of not using " " (i.e. exact phrasing) when doing Google searches. HSR, since they have been built only recently, are mentioned using the Terminus 1-Terminus 2 format in most media sources. And with regards to "most English Wikipedia readers"... that's not the most important issue to be considered here, and probably should not be one. Precision far eclipses recognisability; you pointed this out. Full transliteration often creates disambiguation. --HXL's Roundtable and Record 00:15, 23 April 2011 (UTC) HXL:Appreciate your prompt response. Regarding the highway naming convention: Sure, we can certainly adopt the same full-name approach for highways. i.e. G12 Hunchun-Ulanhot Expressway instead of G12 Hunwu Expressway. Regarding the Google searches: the point here is that more English writers use the full-name approach than the transliterated shorthand approach because the former is more natural. This is true whether we are talking newly built HSRs or longstanding regular speed railways. A search for "Beijing-Shanghai Railway" (in quotes) yields 269,000 results on Google, whereas "Jinghu Railway" (in quotes) yields only 77,000. The "Baotou-Lanzhou Railway" has 16,100 results and "Baolan Railway" has only 1,010 results. Regarding most "English Wikipedia readers": I would not dismiss them so readily from our consideration of naming conventions. Wikipedia exists for their and our use. Two criteria in Wikipedia's naming convention -- recognizability and naturalness -- are based on the reader's experience. While it is true that many of the railway and expressways in China are currently unfamiliar to English readers (and therefore not recognizable to them), Wikipedia can help to change that through the creation of articles about them. This is why it is important for the names of these articles to be helpful, descriptive and memorable. Over time, many of the railways and expressways in China will become more recognizable. How we name them can have quite a lot to do with how quickly they gain acceptance. Precision versus Recognizability: If I read your last point sentence correctly -- Full transliteration often creates disambiguation. -- then you're in agreement with me that using the full-names of these railways and highways creates less ambiguity than the shorthand names, not just often, but almost always. Thank you for your attention. ContinentalAve (talk) 14:36, 23 April 2011 (UTC) To be clear, it is not that I am necessarily opposed to the proposal, but I am concerned about some of the wording of the rationale. Indeed, I will come out and say that full spelling is required in all cases where ambiguation with even one terminus is possible (i.e. Nanjing). --HXL's Roundtable and Record 14:52, 23 April 2011 (UTC) I am fairly neutral on the proposal; but, as one data point, there were 455 results when searching on "beijing-hankou railway" on Google Books; 26 and 35 results when searching on "jing-han railway" and "jinghan railway", respectively. (Among them, there must have been a few "pseudobooks", created by a parasitic publisher from Wikipedia pages; but the number was small enough as not to affect the overall results significantly. There were also a few hits with "chinghan", "beiping-hankow", etc., but again to few too affect the overall ratios). -- Vmenkov (talk) 15:50, 23 April 2011 (UTC) I broadly support this. I am far from proficient in Chinese but recognise many place names, including most cities. But the short names really make no sense to me, i.e. on encountering them I would need to look for the longer full name to understand what is being referred to. I suspect only those proficient in Chinese would recognise the short names, and such people are unlikely to be using the English Wikipedia as a reference for the Chinese railway system. It seems that broader usage agrees with this, based on the searches done. There will still be redirects for those that are searching by the short names, but the full names are more appropriate for the article titles.--JohnBlackburnewordsdeeds 16:26, 23 April 2011 (UTC) I appreciate the helpful input from everyone. HXL, I understand your reluctance to change a long-standing policy but your proposed solution of spelling out the full name only when there is ambiguity with the abbreviated name will prove to be difficult to implement. For one, many writers will not be aware of ambiguities because they haven’t considered the whole galaxy of railway and expressway names. This is why I have gone through the effort of creating a very long post with many examples to illustrate the problem. Only when you consider the Ningwu-based railways will the Nanjing-based railway names seem ambiguous. Second, as we all know, China is undergoing extensive infrastructural expansion and the number of highways and railways will proliferate and create new ambiguities. For example, Hubei and Hunan are building a railway between Jingmen and Yueyang called the Jingyue Railway. The Jingyue along with the Jingsha Railway will start to erode the distinctiveness of Jing for Beijing in English. It will be more and more difficult to tell whether the Jingyuan and Jingzhang Railways are really obscure railways linked to Beijing or somehow related to the Jingyihuo Railway in Xinjiang. If Jing can be made ambiguous, no one is safe. Third, Wikipedia is the place where old knowledge finds new life. Many historical railways in China, like the Jinghan, will have articles created for them. Their inclusion will compound the potential for ambiguity. The earlier we adopt a clear and consistent policy, the less uncertainty and difficulty there will be for article creators going forward. After all, you were the one who opposed bifurcating railways from highways! :P Set forth below, is my proposal of the revised naming convention for the transportation section: Transportation When naming articles of expressways, highways, railways, railway stations, or airports in China, use the common English name if it can be determined, e.g. Karakorum Highway. Otherwise, follow these naming rules for the article name: For roadways, highways, expressways and railways whose names in Chinese consist of two- or three-character abbreviations of the terminal cities (or other location names), do not adopt the pinyin version of the Chinese abbreviated name as the English article name. Instead, spell out the full English name of each abbreviated Chinese place name and connect them with hyphens in the article name: For the 宁芜铁路, use Nanjing-Wuhu Railway as the article name not, Ningwu Railway. The {[full English spelling of terminus 1][hyphen][full English spelling of terminus 2] [Expressway/Railway]} article naming format is intended to identify expressways/railways with precision and avoid ambiguity. E.g. In addition to the Ningwu Railway, there are Ningwu-Kelan and Ningwu-Jingle Railways. The pinyin version of the Chinese abbreviated name should be mentioned in the first sentence of the article as a secondary name of the expressway/railway, and should be made a redirect link to the article. Furthermore, the pinyin version of the Chinese abbreviated name can be freely used in the article itself and in other articles. The rule above applies only to article names. Where there is ambiguity in the pinyin version of the Chinese abbreviated name, create a disambiguation page for the ambiguous name. Nanfu Railway may refer to: Nanchuan-Fuling Railway, a railway in Chongqing under construction since 2008. Nanping-Fuzhou Railway, a railway in Fujian built in 1959. Please capitalize Expressway/Railway in the article name. Railways 京九铁路 - Beijing-Kowloon Railway not Jingjiu Railway 宝成铁路 - Baoji-Chengdu Railway not Baocheng Railway 皖赣铁路 – Anhui-Jiangxi Railway not Wan'gan Railway 精伊霍铁路 - Jinghe–Yining–Khorgas Railway not Jingyihuo Railway Where the pinyin spelling of a place name differs from the official English spelling of the place name (especially in the case of non-Chinese place names) use the official English spelling. 滨州铁路 - Harbin-Manzhouli Railway not Haerbin-Manzhouli Railway Use the same naming format for China's high-speed railways 武广高速铁路 - Wuhan–Guangzhou High-Speed Railway not Wuguang High-Speed Railway Exceptions to hyphenated full-spelling naming format: Where the Chinese name is descriptive, use a brief translation of the descriptive name: 北疆铁路 - Northern Xinjiang Railway not Beijiang Railway. Where the abbreviations in the Chinese name are no longer considered abbreviations. This usually occurs when the abbreviated name has survived changes in the underlying names. 陇海铁路 - Longhai Railway not Longxi-Haizhou Railway because Longxi is no longer used to describe eastern Gansu Province and Haizhou is now part of Lianyungang Roadways For [[10]], add the expressway number as a prefix to the hyphenated expressway name in the article. The prefix and the hyphenated expressway should be separated by a space. 京沪高速公路 - G2 Beijing-Shanghai Expressway 京承高速公路 - S102 Beijing-Chengde Expressway The pinyin version of the Chinese abbreviated name should be mentioned in the first sentence of the article as a secondary name of the expressway and should be made a redirect link to the article. For National Highways that are numbered simply follow the format {China National Highway [number]}: 国道102 - China National Highway 102 National Highways can be abbreviated with "G{no. of highway}", e.g. G105 as a redirect link for China National Highway 105. Railway Station Articles for railway stations in China should be named using the city's name (or in some cases the station's unique name— for example, 丰台火车站) followed by the English translation of the cardinal direction in the railway station name, if applicable (North, South etc.), and then [Railway Station]: 北京站 - Beijing Railway Station 北京西站 - Beijing West Railway Station 丰台火车站 - Fengtai Railway Station Abbreviated forms of the railway station name should be mentioned in the article's first sentence as secondary names and should have redirect links to the article name. Beijing West Beijing South Station Airports Airport articles should have the city's name followed by the [airport's name] if applicable, followed by [International Airport] or [Airport] as applicable: 北京首都国际机场 - Beijing Capital International Airport 上海浦东国际机场 - Shanghai Pudong International Airport 广州白云国际机场 - Guangzhou Baiyun International Airport ContinentalAve (talk) 19:01, 23 April 2011 (UTC) Revised ContinentalAve (talk) 08:05, 1 May 2011 (UTC) I am not opposed to this proposal. Sounds sensible and reasonable for the large readership who doesn't understand the abbreviation used in Chinese. The short names are usually used in mass media. As such, I assume these will be redirects to the full hypenated names. --Visik (Chinwag Podium) 02:31, 29 April 2011 (UTC) This proposal sounds eminently sensible and generally excellent. Hear hear! Jpatokal (talk) 10:01, 29 April 2011 (UTC) I agree with the proposal as well. It may be appropriate, however, to explicitly say in the policy that the "two-syllable" names of railways and highway (Jinghu Railway etc) should also be mentioned in the lede of relevant article. -- Vmenkov (talk) 15:11, 29 April 2011 (UTC) Thank you for everyone's suggestions. I have incorporated your input about the need to mention the Chinese abbreviated name in the first sentence of the article and to have redirect links created for the Chinese abbreviated name. ContinentalAve (talk) 08:05, 1 May 2011 (UTC) By the way, you probably will need to clarify the new policy a bit once certain ambiguities are found. For one, I am not entirely supportive of reducing "Terminus A–B County" to "Terminus A–B". Secondly, cases where the article title of a terminus (i.e. X City or Y County) is not at X or Y County, respectively, due to the existence of other settlements of the same name, need to be dealt with. With romanisation, the reader cannot always know which "X" or "Y County" is being referred to. To begin with, a solution is to use "X City" in the title if there are no other officially-designated cities of the same name. I don't know about the other 2 cases for now. –HXL's Roundtable and Record 04:51, 13 May 2011 (UTC) Endorse, though of course, some wording needs to be changed. My experience with disambiguating town, township, and subdistrict divisions is frustrating enough; no two counties or county-level cities in mainland China share the same name in Chinese but then when romanising, many counties and county-level cities are "repeated" across provinces when fully romanised. Applying this sentiment here, the precision point alone is enough grounds for me to support the policy change. And sorry for the delayed response; have been busy with what I alluded to above...check my contribs if you wish to know. –HXL's Roundtable and Record 04:44, 13 May 2011 (UTC) HXL49, thank you for the endorsement, thoughtful reply and questions. In general, the Terminal A-Terminal B naming method should follow the unabbreviated Chinese place names used to identify the terminals in the name of the railway itself, even if those place names are different from the actual place names currently used to name the places in which the terminal is located. What do I mean? Generally, there is no difference between the place name used to identify a terminal in the name of the railway and the place name in which the terminal is located. E.g. The Yingtan-Xiamen Railway refers to the railway between Yingtan and Xiamen. However, consider the 临策铁路 Linhe-Ceke Railway. The railway was planned when the eastern terminal city was called Linhe. Linhe has since been renamed Bayan Nur, but the underlying railway name still uses the abbreviation for Linhe 临河. Since we are naming articles of the railways, not the place names, we should adhere to the Chinese place name used in the railway name and maintain Linhe-Ceke Railway, not Bayan Nur-Ceke Railway. There are instances where the terminals of a railway are not actually located in the place identified in the terminal place name. For example, the Qiqihar-Bei'an Railway begins in the station of Angangxi, near Qiqihar but not in the city itself. Since the railway name uses Qiqihar as the terminal place name, the article name follows with Qiqihar-Bei'an Railway, not Angangxi-Bei'an Railway. In the first paragraph of the article, there should be a clarification of any differences between the location of the actual terminal and the place suggested by the terminal name referenced in the name of the railway. Consider an opposite example, 南福铁路 Nanping-Fuzhou Railway, was built in 1956 as a branch of the Yingtan-Xiamen Railway. This railway begins in the west at the 外洋 Waiyang Station on the Yingxia Line. Waiyang is located in 来舟 Laizhou, a township of Nanping. Initially, this was the only railway near Nanping and was called the Nanping-Fuzhou Railway. Later as other railways were built into Nanping itself, the line took on 外福铁路 Waiyang-Fuzhou Railway and 来福铁路 Laizhou-Fuzhou Railway as alternate names. In English Wikipedia, an article name has been created for each of the three names. Currently, Waiyang-Fuzhou and Laizhou-Fuzhou redirect to Nanping-Fuzhou because all three names are now considered to be historical names since most of the line has become part of the Hengfeng-Nanping Railway. Nanping-Fuzhou was the first name for the line and remains the most intelligible. The point here is that the article name should follow whichever Chinese place names are used in the Chinese railway name. Quite a few railway terminals are named after and located in counties. See Ningwu-Jingle Railway. If I understand you correctly, I don't think you are calling for this line to be named Ningwu County-Jingle County Railway, since there is no ambiguity with Ningwu or Jingle. I think the more tricky scenario you alluded to is when one of the terminal names when romanized into English is itself ambiguous. Consider the 新义铁路, which when translated under the general rule, becomes the Fuxin-Yi County Railway. But there are several "Yi Counties" in China, and this could lead to some confusion. I do not see a definite solution, but see several options: (a) Fuxin-Yi County Railway. Leave it as is. There may be several Yi Counties in China, but only one Fuxin-Yi County Railway. When the reader clicks through, the first sentence of the article should explain which Yi County the railway connects to. (b) Fuxin-Yi County (Liaoning) Railway. This approach completely disambiguates Yi County. (c) Fuxin-Yi County Railway (Liaoning). This approach explains that the entire railway is located in Liaoning, which should dispel any ambiguity about which Yi County is being referred to, but might give the misleading impression that there is another Fuxin-Yi County Railway in another province. I'm indifferent. What do you and others think? ContinentalAve (talk) 08:33, 15 May 2011 (UTC) Agree with comment. The titles should use En dashes instead of regular ones. Therefore titles like Beijing-Kowloon Railway should actually be Beijing–Kowloon Railway.  –Nav  talk to me or sign my guestbook 13:45, 30 June 2011 (UTC) Who approved this new change? It was not like this before. Python eggs (talk) 01:49, 3 July 2011 (UTC) That's the key idea behind "change". You can see through the history that a proposal was put into place back in April and nobody posted any oppositions for the entire two months that the discussion was open. See this section.  –Nav  talk to me or sign my guestbook 01:52, 3 July 2011 (UTC) Dear Python eggs, on April 24, 2011, shortly after making this proposal, I posted a message on your talk page informing you of this discussion and inviting you to participate. I wanted to give everyone sufficient opportunity to discuss and make inputs and build a consensus before making the agreed to changes two months hence. ContinentalAve (talk) 05:38, 3 July 2011 (UTC) Okay, I do not oppose (not support either) most names, but names like “Lanzhou–Xinjing Railway” really suck, even the Railways itself use “新建铁路兰州至乌鲁木齐第二双线” when it had to write in the long form. [Comment by User:Python eggs] Dear Python eggs, can you explain your objection to the name Lanzhou-Xinjiang Railway more clearly? It is difficult for others to tell why you don't like this name. ContinentalAve (talk) 14:57, 4 July 2011 (UTC) I would like to ask why User:Python eggs reverted some (or most) of my renamings of the articles, which were performed in order to fit with this new convention. Special:Contributions/Python_eggs and Special:Contributions/Heights. I would like to leave a message in light of this new discussion here before moving them back again because it seems some issue has arisen. Heights(Want to talk?) 20:26, 3 July 2011 (UTC) Also sorry I must point up another issue. From the official chinese names of the high-speed railway lines, most of them are in the format of XY客运专线. Now I am not sure of the exact translation of this but it seems to be "Passenger Dedicated Line" or "Passenger Railway." The problem is even the larger lines which comprises of several smaller lines are also called 客运专线, for example Beijing-Harbin客运专线 encompasses Beijing-Shenyang客运专线, Harbin-Dalian客运专线, Panjin-Yingkou客运专线 (客运专线 used because I don't know what the name is). I made the effort of moving all of the larger lines to a "XY Passenger Dedicated Line" format such as Beijing–Harbin Passenger Dedicated Line and the smaller lines that are part of it, such as the Harbin–Dalian Passenger Railway, in the XY Passenger Railway format. I know this is inconsistent because in Chinese, they are both 客运专线, however one encompasses several smaller 客运专线. User:Python eggs reverted some of these back to XY High-Speed Railway such as Harbin–Dalian High-Speed Railway which I feel is incorrect because the Chinese name is 客运专线, which does roughly translate as "passenger dedicated line." Nowhere in those 4 characters do you see any reference to high-speed, albeit it is high speed. In contrast, the Beijing–Shanghai High-Speed Railway makes sense because in Chinese, the name is 京沪高速铁路, with 高速铁路 specifically meaning "High-Speed Railway Line." This is understandable and makes sense. I understand that Wikipedia is also about recognition and High-Speed would be more recognizable, but can we also come up with a consensus on how to name larger 客运专线s, smaller 客运专线, and 高速铁路, before I start moving articles again. Thank you, Heights(Want to talk?) 20:34, 3 July 2011 (UTC) Harbin–Dalian High-Speed Railway and others Can you please explain your rationale for moving Harbin–Dalian Passenger Railway to Harbin–Dalian High-Speed Railway. I moved all of the articles to a X–Y Passenger Railway format in order to maintain consistency. In Chinese, these lines are referred to as 客运专线, which roughly translates as "passenger dedicated line" or "passenger railway" but nowhere do I see the words "High-Speed." In contrast, the Beijing to Shanghai High Speed Railway is correct because in Chinese it is actually named 高速铁路, the words 高速 clearly indicating High-Speed. Also, explain your rationale for reverting all of my moves for Qinshen Passenger Railway and such. Please take a read at Wikipedia:NC-CHINA#Transportation as the new naming convention is to name the articles with the termini stations, aka Qinhuangdao and Shenyang, not Qinshen. Please explain your rationale and/or conform to naming conventions set by WP:NC-CHINA. Thank you Heights(Want to talk?) 20:21, 3 July 2011 (UTC) No. In Chinese, it is controversy. If you search for "哈大高铁" on Google, tons of results will be returned, and many of them from official sites like xinhuanet or gov.cn. Chinese government is switching from "客运专线" to "高速铁路". Python eggs (talk) 03:01, 4 July 2011 (UTC) I think Python eggs is trying to say that in Chinese official usage, "客运专线" is giving way to "高速铁路". But see [11] using 客运专线 from yesterday's Heilongjiang Economic Daily. It's difficult to create a consensus between "客运专线" and "高速铁路" when these lines are so new and often still not yet in operation. I can't see why one is more correct than the other. Maybe in a few years' time, one description will prevail over the other. ContinentalAve (talk) 14:57, 4 July 2011 (UTC) Ok, so I am taking this as all of the 客运专线 should be High-Speed Railway? I was just slightly confused because before I moved all of them to Passenger Railway, the Qinshen or Qinhuangdao-Shenyang article was Qinshen Passenger Railway but everything else was High-Speed Railway. I also find government sources and government sanctioned news sources using 客运专线 and also it is weird that Chinese Wikipedia still has everything as 客运专线 Heights(Want to talk?) 00:59, 5 July 2011 (UTC) I suggest "XXX High-Speed Railway" for all 300+ km/h lines. Recently, all 300+ km/h lines are commonly known as "高速铁路" in China, like 郑西高铁, 武广高铁, 沪杭高铁, 广深港高铁, and etc. The exceptions are Beijing–Tianjin Intercity Railway and Shanghai–Nanjing Intercity High-Speed Railway which is formally referred as "沪宁城际高速铁路". For lines less than 300 km/h, use "XXX Passenger Railway", or simply "XXX Railway" if their no paralleled old railway. (i.e. Hening Railway, Hewu Railway, Wenfu Railway, etc.) [Python eggs] Python eggs, I think it is premature to enact such a blanket policy on the naming of high-speed railways in China until more consistent usage patterns emerge. Heights was certainly within reason to use passenger railway to describe 客运专线. The 300km/h threshold you propose creates an unclear distinction between high-speed railway and passenger railway (and passenger dedicated line)　based on speed of operation, which is not necessarily true. The Wuhan-Guangzhou High-Speed Railway is still being mentioned in some Chinese press articles as the 武广客运专线. Let's wait and see how naming conventions in Chinese evolve　before adopting a formal policy. ContinentalAve (talk) 14:39, 7 July 2011 (UTC)

Second, many if not most railways in China are not written about very much in English-language sources, so sources are often limited and trends may not be readily apparent. The authoritative sources such as the rail operator itself China Railways [12], China Railway Construction Corporation Limited, a leading builder of railways in China [13], as well as sources that study or follow Chinese railways closely such as the World Bank [14] and Asia Development Bank [15] tend to capitalize the word “railway”. They do so because this subject area requires greater precision.

Unlike virtually any other part of the world, rail transport in China is unprecedented expansion, with the number of railways, types of railways, railway stations, etc. proliferating rapidly. See High-speed rail in China The new railway assets are often located in the same places as older assets, giving rise to the need for greater precision in the naming of the new assets as well as the older ones.

For example, as of December 2017, there are two railways between Beijing and Shanghai: the Beijing-Shanghai Railway and the Beijing-Shanghai High-Speed Railway. A second Beijing-Shanghai high-speed railway will be built in the next five years. Consider this statement:

I’m traveling on the Beijing-Shanghai railway.

Can you tell that “Beijing-Shanghai railway” is a proper noun and therefore refers to conventional-speed railway between Beijing and Shanghai? Or is this term is referring to any of the railways between Beijing and Shanghai?

The problem is more acute with the names of railway stations. With the boom in railway construction, Chinese cities are adding railway stations. Apart from a handful of exceptions such as Shanghai Hongqiao, most Chinese railway stations are named after the city in which they are located, plus a cardinal direction, to distinguish the first railway station in the city from newer ones. Consider this statement:

The train arrived at the Beijing railway station.

Did the train arrive at the Beijing Railway Station? Or another railway station in Beijing such as Beijing South Railway Station (for now, the city’s principal high-speed rail hub), the Beijing West Railway Station (for now, the busiest railway station in the city), the Beijing North Railway Station (for day trips to the Great Wall), the Beijing East Railway Station (current undergoing expansion to accommodate the expected opening of the Beijing-Shenyang High-Speed Railway)? Or any of the other railway stations in Beijing, such as the Fengtai railway station (which gives rise to another question, the old Fengtai Station or the new one currently under construction)?

This train is running on the Beijing-Zhangjiakou railway heading to the Beijing railway station.

Beijing Railway Station Beijing South Railway Station Beijing North Railway Station Beijing West Railway Station

But on which Beijing-Zhangjiakou railway is the train running and to which Beijing railway station it is headed?

[Note: Image gallery above refactored to prevent an overwide page for some users, by dcljr (talk) 07:07, 8 January 2018 (UTC).]

Why create the confusion when capitalizing these proper nouns would make the message so much more clear? At the least, I would like to see the de-capitalization campaign implemented in English-language dominated areas.

I urge you to reconsider this deeply misguided decision to de-capitalize names of rail lines and rail stations in China. It will only create problems for editors and readers, stunt the growth of coverage in this subject area and ultimately be reversed due to user and editor complaints, as the ambiguity problems become more pronounced.

ContinentalAve (talk) 21:01, 17 December 2017 (UTC)

Broken section above

I can't edit the section above, since it contains sections in the collapsed part, so may this new subsection will work.

I don't agree that the lowercase railway, station, or line necessarily adds ambiguity. There's a big difference between "the Beijing–Shanghai railway" and "a Beijing–Shanghai railway". One is specific, the other is not. There's no difficulty in distinguishing the specific referents of "the Beijing–Shanghai railway" and "the Beijing–Shanghai high-speed railway" that would be any different with capital letters. Dicklyon (talk) 05:22, 20 December 2017 (UTC)

I think I've fixed the problem that prevented editing the section above. FYI. - dcljr (talk) 05:49, 3 January 2018 (UTC)

Also strongly oppose

The two users most strongly wanting to decapitalise are Dicklyon and SMcCandlish... I find no evidence of either of them having any knowledge of either the subjects or the languages in question. Yes, knowledge of the language isn't really relevant to en.wiki generally, but I think in this case, it's important, because, quoting SMcCandlish from above: "the fact that CJK scripts have no case distinction means we absolutely should use lower-case here because our translations of them are just approximations and thus cannot be their proper names." is patently false. The concept of a proper name is basically universal across languages; by that logic, we should also be transcribing 東城秀樹 as "tojohideki" instead of "Hideki Tojo", 毛澤東 as "maozedong" instead of "Mao Zedong", and 김일성 as "kimilsŏng" instead of as "Kim Il-sŏng" or "Kim Il-sung". A proper name is a proper name, and it per the rules of English, they are to be capitalised. A quick Google search tells me that this concept is taught in Grade 2 or Grade 3.

Regarding the capitalisation of "station", "line", and "railway" in the CJK context specifically, though, I'd make the following observations.

1. Station - I'm not at all adamant that the 'station' part be considered part of the proper name, w/r/t the contexts of Korea, Japan, PRC, and Taiwan; as far as HK is concerned, English is an official language there, so we should do whatever is most widely used in HK - to which I cannot speak to, because I don't know aught about HK's railways. As far as the others are concerned, though, I can agree that 'station' is not always an integral part of the proper name, even though it is often used like that in those languages. In some cases, however, it would be necessary to capitalise it, to disambiguate. For example, Pyongyang Station refers to one specific station in Pyongyang; there are numerous other stations in Pyongyang, including West Pyongyang Station, Taedonggang, Man'gyongdae, Rangrim, etc. To say only "Pyongyang station" is, as ContinentalAve pointed out above with a Chinese example, ambiguous, so it needs to be capitalised for clarity. And if that's done, then it should follow that it be done in other non-ambiguous cases, simply for the sake of consistency.

2. Line - this isn't applicable to the PRC, but is applicable to Japan, Korea, and the parts of mainland China under Japanese administration prior to 1945, where railway lines used 線 as part of their name. In these cases, it must absolutely be capitalised, because it is without question a proper name. In Japan, names of railway lines are for the most part taken from either one location on the line, from the region the line is in, from one character from each terminus of the line, or some other descriptor, such as

• Aizu Line, from the Aizu region of Fukushima Prefecture;
• ja:小松島線 Komatsushima Line, from Komatsushima, one of the termini of the line;
• Keiyō Line, which is formed from the second character of each terminus, Tokyo (東京) and Chiba (千葉) (京葉 together is read as "Keiyō"), to form a new proper name as a specific designator for the line;
• Sankō Line, whose name means "Three Rivers Line", but there is no station on the line with that name, but rather is descriptive of the area; this sort of name is also used for the Chuo Main Line aka Chuo Line (=Central Line), etc.

To take "Aizu Line" as an example, it is without question the proper name of one specific line, because there are numerous other railway lines in the Aizu region, such as the Tadami Line, the Banetsu West Line, the former Nitchū Line ja:日中線, etc., which makes saying "Aizu line" ambiguous - *which* Aizu line is being referred to? So - it's necessary to capitalise the 'line' in this case, too, and so by extension, even if we accept the (ridiculous) notion that these are not necessarily proper names, for consistency's sake all "XYZ Line" names should be capitalised.

Railway practice in Korea is derived from Japanese practice, as it was the Japanese who brought the railway to the Korean peninsula; to this day, the naming of lines follows the Japanese models described above, primarily using the first and third varieties, though the other two turn up, as well. Taking the Hambuk Line as an example, its name is taken from the region it is in - Hamgyeong Buk-do (buk = north, North Hamgyeong Province); like the Aizu Line example above, writing "Hambuk line", however, would be ambiguous, as there are numerous other lines in the province. Another example would be the Gyeongbu Line (style number 3 above), whose name is formed from one character from each terminus - Gyeongseong (today called Seoul) and Busan; these names are, like Keiyō Line above, new formations used specifically for the naming of the railway line in question.

This third way (with 線) was also commonly used in China prior to 1945 in areas under Japanese rule, such as for the South Manchuria Railway's lines like the Anfeng Line, or the Manchukuo National Railway's Chaokai Line, etc. These are, without question, proper names.

The PRC differs from the above in using not 線 but 鐵路 to name its railway lines, which complicates the question a bit, 鐵路 means 'railway' in Chinese; 線 means 'line' (in the general sense), 'thread', 'wire', 'route' etc. And, in China, there are both long and short forms of names for railway lines, e.g. the Beijing–Harbin railway which is also called the Jingha Railway along the third model shown above. In the latter case, for the same reasons as above, these are proper names (there are several railway lines between Beijing and Harbin, for example). Although I will maintain that "Beijing–Harbin Railway" - when referring to one certain, specific line - is just as much a proper name as "Jingha Railway" is, I'd suggest that as a compromise we can consider the long form as just a descriptor, with 'railway' left uncapitalised, but that the short form is a proper name without question and so should be capitalised. Long-form names like this are in my experience rarely-to-never seen in Japanese or Korean.

I'll admit I'm not too adamant about what we do for the PRC, as I don't really have more than a superficial interest in the post-1945 situation there, I'm just including it for completeness; however, for Japan, Korea, and the railway companies of China under Japanese rule - the South Manchuria Railway, the Manchukuo National Railway, the Central China Railway, the North China Transportation Company, and several smaller, privately-owned railway companies in Manchukuo, such as the East Manchuria Railway (note that in these cases the 'railway' must be capitalised, as it is part of the name of the company, just like Canadian Pacific Railway etc) - I will be extremely adamant on the capitalisation of 'line' in reference to specific lines.2Q (talk) 16:18, 19 December 2017 (UTC)

Write all such articles in German. That way we don't have to worry about any of this (since in German, all nouns are capitalized). –Deacon Vorbis (carbon • videos) 16:28, 19 December 2017 (UTC)

How is this in any way a useful comment? 2Q (talk) 16:33, 19 December 2017 (UTC)

Because sometimes, when faced with utter lunacy (like the amount of effort that's been spent arguing over such a minute detail in an area of such niche interest), a little humor is exactly what's needed to put things in perspective. –Deacon Vorbis (carbon • videos) 16:40, 19 December 2017 (UTC)

Fair enough. :) I agree, though, it is kinda a ridiculous thing to be arguing about. 2Q (talk) 18:35, 19 December 2017 (UTC)

@2Q:, I appreciate that you're an expert on these old Japanese, Korean, and Chinese railways. Great stuff. And I understand that it's possible that I made mistakes and downcased some things that are legitimately proper names. But it's not really clear, from your explanations; when you say "it is without question the proper name of one specific line", it's not clear why you say "proper" in there. Many specific line names in many countries use lowercase "descriptive" names, or proper names with "line" or "railway" appended. When a specific Chinese character implies a proper name, I'd need help understanding that before I say OK. And when a "... Railway" title is about a company, as opposed to a rail line, then certainly I agree it's a proper name, and if I downcased any articles about companies I apologize (we had a dispute a year ago on the Harz Narrow Gauge Railways, an article that was originally written to be about the rail lines, but was rewritten to be about the company to justify the caps). Anyway, as I said, I've done my pass; now, if I got some wrong, point those out for discussion, or just move them back. Then maybe we can learn something and come out ahead. Dicklyon (talk) 05:00, 20 December 2017 (UTC)

I suppose the clearest way I can explain it is that in Japan and Korea there is (or, "was", in the case of parts of China under Japanese rule) a practice of naming railway lines, the same way that there is a (I imagine universal) practice of naming streets in a city. So, much like we've got a Granville Street and a Trafalgar Street and a King George Boulevard here where I live, in Japan and Korea etc they name railway lines in the same way, with the naming schemes I described earlier, so you've got a Tadami Line and a Gyeongbu Line and a Musan Line and what have you. There isn't a universal analogy to this in the West, aside from occasional cases, such as the SkyTrain system in Greater Vancouver, which has the Canada Line, the Expo Line, the Millennium Line, and the Evergreen Line. But these are proper names (in the same sense as street names etc.).

I'll admit don't know enough about the situation in the PRC post-1949 to say with 100% conviction it's the same there, but the impression I have is that they do have the same practice in use there as in Japan and both Koreas, and formerly in Manchukuo and the other Japanese-controlled parts of China. 2Q (talk) 15:39, 20 December 2017 (UTC)

The "practice of naming streets in a city" is much older than the practice of treating the "avenue" or "boulevard" or "street" as part of the proper name. Over time the interpretation of what's a proper name evolves, and this is where sources come in. In most places I've looked, I see of lot of lowercase line and railway and such (but always capped street, avenue, and such). I admit that for Japan the capitalized Line seems more prevalent. But I'm not at all sure that I can accept and extend that to the older lines without English-language evidence or a better explanation of what kind of name should be considered a "proper name" when it appears in Japanese or Korean or Chinese. Dicklyon (talk) 16:30, 20 December 2017 (UTC)

"The "practice of naming streets in a city" is much older than the practice of treating the "avenue" or "boulevard" or "street" as part of the proper name" - how is this relevant, though? It is the case now, and has been since at least the beginning of the 20th century. Capitalised Line is pretty much universal for Japan and is the basically standard form used in Romaji/English writing of line names... I'm really not sure how else to explain it more clearly than I already have short of suggesting you learn Japanese or Korean; I don't mean to be rude (and I don't think I honestly believe this, either, but you know how feelings can go), but it almost feels like you're being obtuse for the sake of being obtuse... okay that said I think if you're asking me how I'd define what constitutes a proper name... I'd say: if it is written with 線 and follows one of the four schemes I described above, it's a proper name... as when talking about a line in general, Japanese and Korean will most usually use "路線" ('route'), and will most usually be writing out the names of the termini in full.

For the record then I don't care what yous all decide on for lines in the PRC (although the situation with names like "Shendan Railway" *is* the same as with "Line")... I don't really care enough to put further effort into that. But for Japan, Korea, and the Japanese-controlled railways in the occupied parts of China and in Manchukuo (namely the South Manchuria Railway, the Manchukuo National Railway, the East Manchuria Railway, the North China Transportation Company, the Central China Railway, and a number of small privately owned railways in Manchukuo) I'll dig in as long as it takes. If it's written with 線 and follows one of the four schemes I described above, it's a proper name and should be capitalised as "XYZ Line"; in these places, if it's writing about 鉄道/鐵道 ("railway"), it's either speaking in general, or about the name of a railway company - which context will make clear, and if necessary can be dealt with on a case by case basis. 2Q (talk) 17:51, 20 December 2017 (UTC)

Comment and extension to metro stations

​​​ Sorry for being late, and I just wanted to give my two cents here as a somewhat active contributor to Chinese rail transport (railway, mostly metro) articles in the past. With respect to the 2011 "consensus" that ContinentalAve referenced regarding the naming, I don't really see any debate about the lowercase or uppercase naming for the "railway" or "railway station" part, which is the current issue at hand. It seems to have been glossed over and either didn't warrant debate or no one brought it up. I would say I weakly support the move to de-capitalize the words "railway," "railway station," and "station" in all cases (railways and metro systems) for PRC articles because there really isn't consistent inclusion or exclusion of the words for "Station" or "Railway" as part of the proper name, even in Chinese. ContinentalAve brings up some good points regarding the fact that there is a greater emphasis on the words "railway station" and "railway line" as part of the proper noun in China, but is this really a big deal when we're dealing with an English audience? For example, the phrase: The train has arrived at Beijing railway station, I don't see any ambiguity in terms of does this refer to the one Beijing Railway Station or a railway station in Beijing? I think it is clear that it refers to the railway station named Beijing, and there is only one, as the other ones are named Beijing South, etc. Another point, this problem doesn't even exist in spoken language, only written language. With respect to I'm travelling on the Beijing-Shanghai railway, I again fail to see how using capitalization, as in I'm travelling on the Beijing Shanghai Railway would provide additional clarity to the average layperson who may not be aware there is a normal conventional railway and a high-speed railway. So again in terms of describing it in English it doesn't provide any more clarity by simply capitalizing it.

I also wanted to bring up an extension of this debate regarding metro stations in PRC in general. I see above that there is a debate for Hong Kong MTR stations that is leaning towards supporting the de-capitalization of the word "Station," and I just wanted clarity on the same thing for all metro systems in China. Currently right now I think the convention is to capitalize the word Station. I think again one can argue that the word "Station" is important to the proper name in a Chinese context, but really there is some inconsistency in application. For example, if I walk into a Shanghai Metro station, usually the sign overhead at the entrance will say something like Shuicheng Road Station, which includes the word station as part of the proper name. But on the platform, we just see the words Shuicheng Road on all signs (in English), and even stop announcements just refer to it as Shuicheng Road (omitting the word station). In terms of this discussion, I would like to see it extended to look at and deal with all rail and metro system-related articles in PRC to ensure consistency. In all cases, I'm leaning towards de-capitalization, just to be consistent with Wikipedia guidelines as a last resort. Again, I agree in some respects that there is likely a greater emphasis on including "Railway" or "Railway Station" as part of the proper noun in China, but the application is inconsistent at best. I don't really see how a simply capitalization issue would "stunt the growth of coverage in this area" and don't really agree that there is an ambiguity problem that would be solved simply be capitalizing.

On a last note, a very specific one, it seems above that there was agreement that in cases where the station name contains the word "Railway Station", as in the metro station named "Hongqiao Railway Station", we would leave Railway Station capitalized. In this case, I'd like to propose we move back Hongqiao railway station (metro) to Hongqiao Railway Station (metro), and possibly to Hongqiao Railway Station station, as the (metro) part seems to be confusing and doesn't really clearly disambiguate what the article is about from the title alone (metropolitan area? what is metro?). It seems this was de-capitalized as part of the massive auto-de-capitalization list that was performed. Heights^{(Want to talk?)} 05:03, 28 December 2017 (UTC)

Thanks for pointing out the odd case of the metro station named for the railway station. I think Hongqiao Railway Station station is logically sensible, yet jarringly wrong looking at the same time. Perhaps Hongqiao Railway Station (Shanghai Metro station) would be more clear and less jarring? Dicklyon (talk) 07:10, 28 December 2017 (UTC)

@Dicklyon: But then it wouldn't be consistent with other articles in the system, which would likely all be renamed to "Name station" or "Name station (system/city?)" by decapitalizing "Station". The zhwiki article is titled "虹桥火车站站" (lit. Hongqiao railway station station). The article South Square of Chongqingbei Railway Station station has already been renamed, and being titled "South Square of Chongqingbei Railway Station (Chongqing Rail Transit station)" might imply the station's name to be "South Square of Chongqingbei". Jc86035 (talk) 09:06, 28 December 2017 (UTC)

@Jc86035: Agree, I would prefer the double use of station given that the second one is decapitalized, which right now (at least for Shanghai Metro articles) it isn't. It is also, as Jc86035 pointed out, used in Chinese, where "站站" can be used to refer to a station that's at another station. The second proposal where it would be named Hongqiao Railway Station (Shanghai Metro station) does kind of mess up the consistency, and also for other stations requiring disambiguation, we currently use the format xx Station (Shanghai Metro), i.e. Xiaonanmen Station (Shanghai Metro), so if we switch to the second format, we would need to rename these articles to xx (Shanghai Metro station) as well. Heights^{(Want to talk?)} 15:01, 28 December 2017 (UTC)

True. I moved it back to Hongqiao Railway Station (metro) to match the others (I think). No objection here if someone has a better idea. Dicklyon (talk) 17:03, 28 December 2017 (UTC)

Okay, that works for now. I think I'd like to eventually see a broader framework or set of guidelines established for naming of all metro-related articles in Mainland China as well, so we can remove any confusion and inconsistency in naming. I guess this is a similar discussion to the one for conventional railways and we can kind of tackle two issues at once if we come to some closure. There are similar questions like:

• Should station be capitalized or not? (I'm leaning toward no capitalization). Currently almost all Chinese metro articles have it capitalized.
• Should line be capitalized or not when it is not a numeric line? (e.g. Pujiang Line, Shanghai Metro, Batong Line, Beijing Subway). Currently pretty much all capitalized.
• How should cases where there are multiple stations with the same name across different systems be handled? For example, should it be Gaoqiao Station (Ningbo) and Gaoqiao Station (Shanghai)? or should it be Gaoqiao Station (Ningbo Metro) and Gaoqiao Station (Shanghai Metro)?

And more specific questions like:

• Should we always use official English names provided by the transit agency, even when they are seemingly inconsistent? e.g. some systems, like Beijing and Nanjing, like to keep the character 路, meaning road, left in Pinyin as lu, such as Zhichunlu Station and Yunjinlu Station. Others, like Suzhou, like to keep it as lu, but with a space in between, such as Lindun Lu Station. Shanghai likes to translate the character to road, resulting in Boxing Road Station. Very inconsistent. The direction right now seems to use the official English name used within the system, which I tend to prefer, even though it is inconsistent across systems. It is generally consistent within a system, but even Shanghai still has an exception in Waihuanlu Station.
• How should the cases of metro stations at railway stations be handled? Should we use xxx Railway Station station? xxx Railway Station (metro)? xxx Railway Station (Shanghai Metro)? or something else? Heights^{(Want to talk?)} 19:17, 28 December 2017 (UTC)

​​ I would prefer not capitalizing "station"; no preference for "[Ll]ine" (probably defer to sources); disambiguate with system (ASDFGH moved a lot of these from system to city but not sure if there was any consensus, and systems' stations are not necessarily within city limits); use the name the company uses (since they've provided official English names); use "…Railway Station station". Jc86035 (talk) 09:15, 29 December 2017 (UTC)

As in most other countries, we should lowercase "station" and "line" when moving toward consistency (even if the "official" listing caps them). I'd avoid anything like "Railway Station station" if possible. Dicklyon (talk) 18:16, 29 December 2017 (UTC)

@Dicklyon: Would you name South Square of Chongqingbei Railway Station station and Tianjinzhan Station (天津站站; lit. Tianjin railway station station) differently from the rest? For consistency, "…Station station" is probably the best option, although merging the articles for the mainline and metro/subway stations would also work (this is already the case for some articles such as Wuhan railway station, though it might not be entirely accurate if there is no official interchange like for National Rail/London Underground interchanges). Jc86035 (talk) 06:42, 30 December 2017 (UTC)

I don't have a strong opinion on these; just don't want to see excess caps. I don't think a complete consistency is that important. Dicklyon (talk) 22:08, 30 December 2017 (UTC)

And that, right there, is the best statement in this entire thread.... complete consistency ISN’T that important. Blueboar (talk) 01:15, 31 December 2017 (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.

Early removal of a merge tag

Are there situations where a {{mergeto}} tag may be removed before the close of the merge proposal?

To me, it's intuitively obvious that the tag and the proposal should come and go together, and stating that at WP:MERGE should be unnecessary WP:CREEP. But intuitive obviousness is often a matter of opinion.

This is currently a matter of contention at Erica Garner, who recently died.

A merge proposal has been open for 3+1⁄2 days and the Opposes have a strong lead. I am abstaining from the !voting as my only strong feelings there are about process. While WP:MERGECLOSE appears to suggest a default duration of 30 days, a A move to close was made at +17 hours based on that lead. Also in dispute is how early the proposal should be closed—I don't think anyone advocates the full 30 days—but I would like to limit this to whether the tag may be removed before the close. If not, I would like to ask whether something to that effect should be added at WP:MERGE.

Those who want to remove the tag say that it is derogatory and/or disrespectful to the recently deceased article subject to advertise to readers that her notability is in dispute. ―Mandruss ☎ 10:02, 3 January 2018 (UTC)

The merge proposal is losing 83-17%, having only increased from 72-28% the first time people requested an early closure. It has a large turnout and the discussion is a clear case of WP:SNOW, on what is an article receiving substantial traffic at present. As another editor commented at Talk:Erica Garner: "In this case, the tag is suggesting that this person's life did not matter; that they were a person of no account; merely their father's daughter. This implication seems likely to give offense to the relations and acquaintances of the subject and so it should not be maintained any longer than is necessary. Common decency, as specified by the policy, now requires that the tag be removed."

I would go further and suggest that it is likely to cause obvious, pointless offence to a large proportion of our readership of this article, being that it concerns a prominent figure in the civil rights movement. There is no possible chance of this proposal succeeding at this stage, but this allows for a couple of editors, in the face of overwhelming consensus, to force every reader of this article to see those couple of editors' view about the subject before they get to read our actual article about her. The only argument for doing this is "because we can". Having it up for another week, or two, or three, has zero chance of altering the result - but it means that they force every reader to see what they thought of the subject for that extra bit longer. This disregard for consensus and for at least the spirit of the BLP policy shows the uglier side of Wikipedia.. The Drover's Wife (talk) 10:20, 3 January 2018 (UTC)

This discussion is why I think we should have far fewer maintenance tags (aimed at involved editors) in article space (aimed at readers). Readers with no intention to edit should not be bothered by these kinds of messages that say nothing about the content quality of the article they are reading (in contrast to insufficient sourcing type of messages for example that give a warning about article quality). Arnoutf (talk) 13:04, 5 January 2018 (UTC)

It is simply false to say that The only argument for doing this is "because we can". In point of fact, that is one argument that has not been forwarded. Therefore you're either being intentionally misleading or suffering from WP:IDHT. Likewise disregard for consensus - there is no consensus by any definition I've ever seen. Now I'll leave this to objective outside observers; I didn't come here to continue the debate with you. ―Mandruss ☎ 10:35, 3 January 2018 (UTC)

You've argued that because it is a possible interpretation of policy to force it to remain there for 30 days in spite of the WP:SNOW opposition and ethical concerns, it should - that's the only argument you've given. That sounds like a lot like "because we can" to me. I think this is the first time in all my time on Wikipedia that I've ever heard someone try to argue that more than 80% opposition to a proposed merge with 25 people responding isn't consensus for Wikipedia purposes, so that's, uh, a fairly unique take. The Drover's Wife (talk) 10:57, 3 January 2018 (UTC)

(Personal attack removed) I have cleared stated twice[16][17] that I am not opposed to a close on 8 January, 70% short of 30 days. I also stated in the opener here that this thread is not about when to close anyway. It's clear enough that you are not here to debate in good faith. ―Mandruss ☎ 11:09, 3 January 2018 (UTC)

I have redacted that gross personal attack. Do not re-add it. ♠PMC♠ (talk) 11:23, 3 January 2018 (UTC)

It was a sincere question, but not essential to my comment and I'll defer to your admin status. ―Mandruss ☎ 11:26, 3 January 2018 (UTC)

It's sincerity has nothing to do with offensiveness - questioning someone's mental ability is offensive and a personal attack. Galobtter (pingó mió) 11:45, 3 January 2018 (UTC)

• No - For circumstances in which a removal of the tag prior to close is proposed (or seems appropriate), a close of the discussion itself is preferable. If the discussion is not sufficiently developed as to facilitate a close, it is not sufficiently developed to allow removal of the tag. - Ryk72 ^'c.s.n.s.' 11:44, 3 January 2018 (UTC)

The whole issue here was that Mandruss alone was trying to prolong the close, and thus keeping the tag on the article, which gave rise to the above dispute about removing the tag first. The simple alternative to any grand meta-discussion here is that when you have WP:SNOW opposition to an attempt to merge the article of a highly-trafficked article about someone who has recently died, the decent thing to do is to close the damn merge bid (for all the reasons listed) - in which case one never has to argue about getting the tag off the article.

I suspect it is probably a necessary evil to have such a tag in situations where there is a realistic notability dispute, and I agree with Ryk72 on that point. But it's a bit moot: this kind of dispute is only ever going to arise in this way again if someone - as Mandruss did here - tries to prolong a close to keep the tag at the top of the article in a WP:SNOW situation. The Drover's Wife (talk) 11:47, 3 January 2018 (UTC)

The proposal has been uninvolved-closed[18] and the tag has been properly removed. While I disagree with a close after 3+1⁄2 days regardless of the numbers, I am not appealing it and as I've said this thread is not about when to close. The close statement includes: "... the meta-discussion related to this at WP:VPP#Early removal of a merge tag can be continued". Since I opened this for opinions on the policy question about early removal of merge tags, rather than being dispute resolution for that specific situation, I would like to see this discussion continue to something resembling a community consensus. This is not likely to be the last time a situation like this raises its ugly head.
I continue to disregard attempts by The Drover's Wife to personalize this issue. ―Mandruss ☎ 11:51, 3 January 2018 (UTC)

The answer to the meta-situation is pretty obvious, as Ryk72 said above: if there is actually no consensus, it should stay, and if there is a consensus, it should be closed. Attempts to prolong the discussion in a WP:SNOW situation merely in order to keep the tag on should be stomped on. Easy. It can't be separated from what happened here because there's no issue (from any side) unless someone does what you did here. The Drover's Wife (talk) 12:03, 3 January 2018 (UTC)

there's no issue (from any side) unless someone does what you did here. The tag was re-added by at least three other editors[19][20][21] and a fourth editor voiced support for my position on the talk page.[22] That's about the tag removal; on the issue of when to close, I had support from two editors[23][24] including one who does a lot of uninvolved closes. Thus, your attempt to make this appear as if I'm alone in this, with the correct assumption that nobody will take the time to look deeper, is yet another display of bad faith distortion of the situation. In stark contrast, I haven't tried to make it appear that you're alone in your position. If you have any credibility left here, people aren't paying attention.
Further, Ryk72 supported my view, not yours. They clearly said that the tag should not be removed before the close.
Please, can we end this counterproductive personal bickering and get more outside opinions on the policy question? ―Mandruss ☎ 12:50, 3 January 2018 (UTC)

• If everyone in the Erica Garner merge discussion had accepted that the discussion was an example of a Snow-close then we all could have saved a large amount of time and effort arguing. I'm still unclear as to why Mandruss refused to accept that the approximately 85/15 balance of opinion, from a large number of editors, was not an example of Snow-close? MurielMary (talk) 10:50, 4 January 2018 (UTC)

• If everyone in the Erica Garner merge discussion had accepted that the discussion was an example of a Snow-close then we all could have saved a large amount of time and effort arguing. Absolutely, tons of time could be saved if nobody ever disagreed on anything. Your point is? The concept that a discussion should remain open for some minimum amount of time regardless of the numbers is not one I invented. That minimum is something about which experienced and reasonable editors can and do disagree. That's what happened here, and it will continue to happen because Wikipedia does not like to put exact numbers in guidelines.
  Anyway, for something like the fourth time here (I've lost count), this thread is not about when to close but about whether the merge tag may be removed before the close. Thanks largely to off-topic comments that people understandably don't care to slog through, we've had exactly one outside opinion. ―Mandruss ☎ 16:53, 4 January 2018 (UTC)

  Re. "The concept that a discussion should remain open for some minimum amount of time regardless of the numbers is not one I invented" – in fact it was, invented by you in this particular case I mean, see discussion below and retraction above. The actual guidance, "If there is a consensus against the merger, or if there is no consensus or no discussion and you don't believe that it is appropriate to merge the pages, then please remove the merge proposal tags and, if necessary, close any discussion", has no provision of a minimum amount of time: the minimum amount of time to keep the discussion open only applies when there's a reasonable chance the merge proposal might succeed, which was evidently not the case in the cited example. --Francis Schonken (talk) 13:21, 5 January 2018 (UTC)

• The "merge" tag on the article should not have been removed until the merge discussion was formally closed, with the closer responsible for removing the tag. I would treat it like an AFD tag - the tag should not be removed until the AFD is closed. --Masem (t) 16:57, 4 January 2018 (UTC)
• Since the reason for the tag is to solicit participants to the discussion so a consensus can be established, it would defeat the purpose of the tag to remove it while the discussion is still ongoing. The instructions for the {{merge to}} template describe when the tag can be removed; if any additional wordsmithing is desired, it can be done there. isaacl (talk) 17:21, 4 January 2018 (UTC)

• @Isaacl: Not that I intend to change anything after only 36 hours and three comments (even unanimous ones)—but would the template doc have as much weight as WP:MERGE? ―Mandruss ☎ 05:34, 5 January 2018 (UTC)
  • I thought about it, but honestly I don't think anyone disputes the general principle that the tag should remain until the discussion is closed (the objections above are arguing that, in that specific case, the discussion should have been closed), and so it feels like unnecessary effort to expand Wikipedia's guidance on merging further. isaacl (talk) 05:53, 5 January 2018 (UTC)

• Yes, per the current WP:MERGECLOSE guidance plenty scenarios are thinkable (and have been applied in practice) where a {{mergeto}} tag can be (and was) removed before the close of a merge proposal. Clues in the guidance, e.g. "... and, if necessary, close any discussion" (emphasis added): the "if necessary" indicates it is *not always* necessary to formally close a merge discussion. Example: Talk:Bach-Werke-Verzeichnis#Merge? indicates a merge tag has been in the article and was removed without formal close. --Francis Schonken (talk) 06:32, 5 January 2018 (UTC)

  @Francis Schonken: As you know, consensus is not about raw numbers; if it were, we would vote instead of !vote. In the absence of an uninvolved such as yourself, how is it decided whether a close is needed? If there is some percentage threshold above which SNOW is self-evident, where is that number documented so that we're all on the same page with respect to it? Are we to assume that it's totally impossible for 80%+ of participants to be wrong in their interpretation of vague, complex, nuanced, and self-contradictory policy? Is the "minimum-time-open-regardless-of-numbers" concept something I just invented in your view?
  To be clear, I have no objection to skipping the close when there is substantial agreement that it is not necessary. That substantial agreement did not exist in this case, so the close correctly was not skipped and the tag should not have been removed before the close because 2 or 3 editors felt the tag was disrespectful to the deceased and her family. Guidance should say something like "The tag should remain on the article until the proposal is closed or there is substantial agreement that no close is necessary." ―Mandruss ☎ 07:03, 5 January 2018 (UTC)

  This removal of the merge tag (edit summary: "removing merge tag as no consensus reached") was completely conforming to the MERGECLOSE guidance ("There is no required 30-day discussion period. ... if there is no consensus ... and you don't believe that it is appropriate to merge the pages, then please remove the merge proposal tags ..."). The additional "... and, if necessary, close any discussion" is in this case an appreciation left to the one removing the tag. If they don't think the discussion needs a formal close, then they don't. And that's where it should have left mainspace for at least (!!!!) 24H to allow talk page discussion to see if a consensus on re-introducing the tag could be reached.

  The edit that re-introduced the merge-tag a few minutes later was starting an edit war: no consensus to re-introduce the merge tag had been established on the talk page in the mean while. So it is very simple: you can't edit war over the presence of a merge proposal tag in mainspace. And it would be necessary to rewrite the MERGECLOSE guidance to allow such edit-warring. Which is of course not going to happen.

  "Lack of consensus" + "one editor not believing that it is appropriate to merge the pages" is enough to remove the tag, per the current guidance, and that should have been sufficient to prevent an edit war repeatedly (and without diligent talk page discussion) re-introducing the merge tag in this case.

  The rest of your proposal works remarkably less well to prevent edit-warring. --Francis Schonken (talk) 07:41, 5 January 2018 (UTC)

  If your analysis is correct, it's yet another example of a policy so convoluted as to be missed by three uninvolved experienced editors in this thread, and incomprehensible to the average editor, thus ensuring perpetual conflict, edit warring, and time-consuming trips to dispute resolution venues for something that should be able to be handled locally. It's an argument that was not made by any editor at the article, by the way, so none of them were aware of it and understood it either. I specifically asked for p&g support for their actions and got none. Among a dozen or so editors involved in this, including the other three outside commenters in this thread, it appears you're the first who understands this. Do you see any problem with this situation? I sure as hell do, but after over 4 years and 39K edits I can't say it surprises me much. ―Mandruss ☎ 08:07, 5 January 2018 (UTC)

  Nah, the guidance is as simple as can be: don't edit-war over the presence of a merge tag in mainspace. If there's disagreement, it takes no more than one person to remove the merge suggestion tag, and that's where things stay in mainspace until if and when a talk page consensus says something different, or sufficient time has elapsed to start a new merge proposal. Nah, the proposal to have a discussion closure every time someone suggests a merge is unnecessary red tape, and has many more levels of complexity than the current all in all very simple rules.

  Yeah sure, experienced editors may fail to grasp the simpler rules while being much, much more experienced in the complexer cases (takes many sorts of people to write an encyclopedia). No reason to make rules more complex in areas where they can be kept simple. --Francis Schonken (talk) 08:31, 5 January 2018 (UTC)

  Call it simple all you want; the bottom line is that it's too complex, too opaque, too inaccessible, or too [fill in adjective here] for 11 out of these 12 editors. The objective has to be a set of p&g that enables average editors to do the right things, most of the time, without consulting the wise men on routine processes, and with a minimum of conflict. I don't see how you can say this approaches that objective. Do you consider me and the others to be anomalies?
  If I really put my mind to it, I think I might be able to understand and absorb your analysis and apply it correctly in the future. The problem is that I had to spend a couple of hours on this page to even get to this point, and there are another _0,000 editors at my level or lower. It would take years to educate half of them on this question alone; in the meantime, we have repeats of this conflict and many others like it, and we continue to bleed good faith editors who are just too damned frustrated to continue, surrendering the project to bad faith editors who don't care much about policy anyway. I remain bewildered that anybody can look at this and say it's the best we can do. ―Mandruss ☎ 09:18, 5 January 2018 (UTC)

• Re. "...WP:MERGECLOSE appears to suggest a default duration of 30 days..." – it doesn't. It explicitly says "There is no required 30-day discussion period". It does not "suggest" the opposite of what it explicitly says. There's no need to make this more complicated than it actually is. --Francis Schonken (talk) 10:23, 5 January 2018 (UTC)

  The word "default" implies "not required". The two statements are therefore not inconsistent. But no matter: In this case I stated I was not opposed to 9 days, and would have accepted even less if not for the New Year's holidays. Your correction does not affect my last few comments above. ―Mandruss ☎ 11:28, 5 January 2018 (UTC)

  WP:MERGECLOSE has two "special" rules each involving a 30-day period and a complete lack of objections to the proposed merger; after which it is made *explicit* that no conclusions for a default period can be drawn from these special cases (and certainly not in the case most participants object). So please read: "There is no required 30-day discussion period". Nor 30 days, nor any other period is suggested as a default in the case there is an immediate response mostly consisting of opposes. Not anywhere in the WP:MERGECLOSE guidance. The actual guidance might be easier to parse if not starting from ideas that really aren't there. --Francis Schonken (talk) 12:16, 5 January 2018 (UTC)

  Per my 09:18 UTC comment, this is no longer about my understanding, if it ever was. You're missing the much larger point. If editors should be able to understand the guidance, that doesn't change the fact that they do not—unless we eleven are all anomalies who somehow happened to converge on this case—and the latter is what matters out there in the real Wikipedia world. Something needs to change, and that can't happen if editors like yourself keep insisting that there's nothing wrong.
  But, sigh, this is probably too meta for this page, and I'm not inclined to embark on a one-man crusade elsewhere, so I'm prepared to drop it. If she dies, she dies. Thanks for the convo. ―Mandruss ☎ 12:38, 5 January 2018 (UTC)

  Disagree, this is still about your misgivings regarding the guidance. In the OP you posted "... WP:MERGECLOSE appears to suggest a default duration of 30 days ...", which it doesn't – and which steered this discussion somewhat off-topic from the outset. You didn't retract that statement from the OP, so that we could reboot this discussion somewhat less entangled in prejudiced directions. --Francis Schonken (talk) 12:58, 5 January 2018 (UTC)

  Retracted. Effect on the larger issue: none. See ya. ―Mandruss ☎ 13:02, 5 January 2018 (UTC)

• No, especially not for such a bogus reason as a subjective sense that a template announcing a discussion is personally "disrespectful" to the subject. That's utterly ridiculous. Just close the merge discussion (with consensus to merge, with consensus to not merge, or without consensus, which amounts to no merge per the status quo principle). Removin the tag early is half the job, guaranteed to be controversial, and just leads to pointless F'ing drama. Don't do it. If you have consensus to remove the tag, you have consensus to close the discussion. If you're already involved in the discussion, then don't be a WP:JERK and invite dispute about the validity of the close; let someone else deal with it, or again there will be pointless F'ing drama. We have an entire noticeboard for requesting closure, at WP:AN/RFC, and if you indicate that it's a WP:SNOW, then someone will usually close it pretty quickly. Remember, WP:NODEADLINE.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  09:42, 9 January 2018 (UTC)

Barnstars and wikiproject control

FYI

 – Pointer to relevant discussion elsewhere

Please see Wikipedia talk:WikiProject Wikipedia Awards#Barnstar bureaucracy

While I posted this notice initially at WP:VPMISC, the fact that this raises questions about WP:CONLEVEL, WP:OWN, and WP:EDITING policies makes me think it should be "advertised" here as well. I'm reminded (albeit the stakes being much lower) of the sharp distinction between Wikipedia talk:Identifying reliable sources (medicine) and Wikipedia talk:WikiProject Medicine. While the wikiproject started that guideline, it doesn't own it, and decisions about it are made by everyone in the community who cares to participate, without having to sign up as a "member" of a club.

I have for years had concerns about the level of bureaucratic control exerted by the awards wikiproject across several awards-related pages that are not under "Wikipedia:WikiProject Wikipedia Awards/...", and their invention (and enforcement by revert) of pointless voting processes about them, also known as barriers to entry. Now they're redirecting the awards talk pages to their own wikiproject talk page, and I think this bears some community consensus consideration.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  11:29, 9 January 2018 (UTC)

Disambiguation of adjectives: a missing guideline

Please join Wikipedia talk:Disambiguation#Disambiguation of adjectives. Staszek Lem (talk) 00:26, 11 January 2018 (UTC)

In brief: Bayesian econometrics is in Bayesian (disambiguation), but Long bow is not in Long (disambiguation). My guts tell me why this is so, but is this conforming disambiguation guideline? Staszek Lem (talk) 00:29, 11 January 2018 (UTC)

Article-space template messages should require starting a talk page discussion

Too often I see editors add something like {{globalize}} or {{confusing}} to the top of an article without explaining why and without trying to fix the issues. As a result, the messages are left at the top of the article for months (or years). I believe that for an editor to place a template message at the top of a page, they should have to also create a talk page discussion explaining what needs to be fixed.

I was surprised to see that this policy has not yet been implemented. Further, I can't seem to find any guidelines surrounding the use of these template messages at all. I welcome your thoughts. AdA&D 19:19, 5 January 2018 (UTC)

@Anne drew Andrew and Drew: WP:DRIVEBY says that non-obvious tagging should be explained on the talk page. Is that what you're looking for? RudolfRed (talk) 19:31, 5 January 2018 (UTC)

WP:DRIVEBY is something I certainly agree with, however it is an essay, not a guideline. I would propose a template guideline which states that all newly added cleanup templates must be explained in the talk page. Better yet, promote Wikipedia:Template messages/Cleanup to guideline, and strengthen its language against "drive-by tagging". AdA&D 19:46, 5 January 2018 (UTC)

• Remember that anyone can start a talk page discussion... even “you”. If someone leaves an unclear “cleanup” tag, and you can’t figure out what needs to be fixed... you can go to the talk page and ASK. Don’t wait for the other guy to do the right thing... do it yourself. Blueboar (talk) 20:11, 5 January 2018 (UTC)

  I'm aware of that. I just think that the onus should be on the tagger to explain their reasoning. AdA&D 21:41, 5 January 2018 (UTC)

• I would oppose making this a policy, per WP:CREEP. If I can't figure out why a tag has been placed and the editor placing it hasn't made any effort to explain, I just remove it. I've been doing it for eight years, it doesn't seem to have been a problem yet. Ivanvector (^Talk/_Edits) 20:15, 5 January 2018 (UTC)
  • I agree with your diagnosis, but it is certainly a problem, as there are editors who think that placement of tags is a right, not just another edit that anyone can revert.  There was an RfC on WT:V whose closure basicly concluded that WP:BRD applies to tag placements, [25].  Unscintillating (talk) 04:04, 7 January 2018 (UTC)
• {{globalize}}, {{technical}}, {{coi}}, {{unbalanced}}, {{systemic bias}}, {{unfocused}} and some others have instructions in their documentation stating that the talk page should be used to describe the issues at hand. The way we present this request varies significantly from template to template; maybe it'd make sense to add an encouragement to open a talk page discussion on more templates, or at least to standardize the language a little bit more across more templates. This doesn't require changing policy and it may help increase the amount of actionable information. Warren -talk- 01:01, 6 January 2018 (UTC)
• Here is another case, in which I reverted with the edit comment "unclear templates" without getting either BRD or any clarification.  In looking at just the COI tag, it has two talk page requirements that were disregarded.  Unscintillating (talk) 04:35, 7 January 2018 (UTC)

Eh, I happened to add {{Globalize/Eng}} at Ordinal number (linguistics) recently (without even seeing this thread). I didn't start a discussion on the talk page, because it seemed really obvious to me: it's a linguistics article about something that's not language specific, yet the article only covers English. I could have started a talk page thread, but I don't know what that would accomplish. And I just don't have the expertise to improve it, myself. So yeah, often times discussions are helpful, but sometimes there's just not much point. –Deacon Vorbis (carbon • videos) 05:11, 7 January 2018 (UTC)

 

I don't see much point in trying to make talkpage explanations "mandatory". It really wouldn't change much. The current situation is that you can just go ahead and remove any tag lacking an apparent purpose, that wouldn't change. Currently the next step is that you can optionally leave a question or notification to that person that you removed the tag... that would change to an optional warning. Currently if someone engages in persistently and egregiously bad tagging, we can topic ban or otherwise sanction them for disruptive editing. That would change to... a stronger basis to topic ban or otherwise sanction them. And I see zero chance we're going to apply swift and firm enforcement on something like this. The proposal here just isn't going to change much. If an article is badly or mysteriously tagged, just remove it. If that editor wants to reassert their tag then they are going to have to show up and explain it (or risk sanction for unexplained editwarring to restore it).

However we could certainly try to make some of the template instructions more emphatic. Instructions on the template-docs aren't as effective as text on the live template. We really don't want to bloat the size of template messages, but templates which particularly suffer from this problem might try to squeeze in something short like "Unexplained tags may be removed", or references to talkpage explanations may use worlds like "need" or "should", or use "must be explained on talk" in conjunction with removal if not explained. Just don't expect or imply that failing to leave a talkpage message might be enforceably-prohibited. Alsee (talk) 09:04, 8 January 2018 (UTC)

• While people certainly should do this, I don’t believe it should be mandatory. Personally, when I see this and don’t see the problem, I just remove the tag. Beeblebrox (talk) 00:38, 9 January 2018 (UTC)

• Yup. In a lot of cases the tags are old, the article has been fixed, but no one took the last step and removed the tag. --NeilN ^{talk to me} 00:48, 9 January 2018 (UTC)
  • Or the problems are obvious, and don't need a talk page discussion. Headbomb {t · c · p · b} 00:52, 9 January 2018 (UTC)

• Nah. This would just be an excuse to remove 99% of dispute and cleanup templates.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  09:29, 9 January 2018 (UTC)
• Oppose- most of the time it's obvious what the tagged problem is from looking at the article. There's nothing to be gained by placing yet another obstacle in the way of content maintainers. Reyk _YO! 09:50, 9 January 2018 (UTC)
• Unnecessary – but if you see a tag and can't figure out what's it's trying to tell, just take it out. Dicklyon (talk) 04:08, 12 January 2018 (UTC)

RfC at Wikipedia talk:Manual of Style#RfC: Linking to wikidata

An RfC has been initiated at Wikipedia talk:Manual of Style#RfC: Linking to wikidata. Please comment there, not here. --Francis Schonken (talk) 06:51, 16 January 2018 (UTC)