This page uses content from Wikipedia and is licensed under CC BY-SA.

Wikipedia:Village pump (all)

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)

Village pump sections

To discuss existing and proposed policies

To discuss technical issues. For wiki software bug reports, use Phabricator

Dialog-information on.svg
To discuss new proposals that are not policy-related. See also: perennial proposals.

Idea lab
To discuss ideas before proposing them to the community and attempt to find solutions to issues

To post messages that do not fit into any other category

View all village pump sections at once

Other help and discussion locations
I want... Where to go using Wikipedia Help desk find my way around Wikipedia Department directory
...specific facts (e.g. Who was the first pope?) Reference desk
...constructive criticism from others for a specific article Peer review resolving a specific article edit dispute or making a user conduct dispute complaint  Requests for comment comment on a specific article Article's talk page view other Wikimedia projects Wikimedia Meta-Wiki learn about citing Wikipedia in a bibliography Citing Wikipedia report sites that copy Wikipedia content Mirrors and forks ask questions or make comments Questions


Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).


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

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, 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 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 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, 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 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 (talkcontribs) 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 deckertalk 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 (talkcontribs) 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. Neutralitytalk 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: 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//Δ'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. ClubOranjeT 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)TCM 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. (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. (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). Reywas92Talk 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? (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 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: 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 (talkcontribs) 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. (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)
  • 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 " 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 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 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 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 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 (talkcontribs) 17:41, 14 October 2017 (UTC)


  • 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 (talkcontribs) 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 (talkcontribs) 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 (talkcontribs) 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 (talkcontribs) 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 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)
        • 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 based on the previous models where breaking news has worked well, but when all breaking news is reported on, 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, October 23, 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. (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 (talkcontribs) 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 (talkcontribs) 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? (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. (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)

Should Wikipedians be allowed to use community granted tools in exchange for money?

Recently we had an OTRS "volunteer" lose their access to the tool here. User:KDS4444 is a well known long term paid editor.

This raises the question:

  • Should OTRS volunteers be allowed to request money from people sending in question to OTRS?
  • Should editors at AfC be able to request money for passing / accepting an article at AfC?
  • Should admins be allowed to bill for undeleting an article / use of admin tools?
  • Etc

Or should we have policies clearly disallowing this. Doc James (talk · contribs · email) 16:18, 1 November 2017 (UTC)

  • Seems like WP:INVOLVED and WP:COI capture most of the spirit of this, and would be the places to amend if clarification is needed. — xaosflux Talk 16:40, 1 November 2017 (UTC)
    • That we have had OTRS agents using the system to make money proves that when it comes to paid editing "spirit" is often not enough. We need it to be black and white. Doc James (talk · contribs · email) 17:46, 1 November 2017 (UTC)
  • Obviously not, that's corruption. If our existing policies do not effectively forbid it then we should have news ones that do - perhaps amendments to WP:INVOLVED and WP:COI, as xaosflux says. Boing! said Zebedee (talk) 16:58, 1 November 2017 (UTC)
  • I think that an explicit prohibition of such would be a good idea. In government and business that is considered to be bribery or a kickback scheme. And since Wikipedia conflates tools with related powers/positions, we should note that it's not just mis-use of tools, it's mis-use of powers/position. North8000 (talk) 17:10, 1 November 2017 (UTC)
  • The admin aspect was already discussed and rejected as a standalone item. Jo-Jo Eumerus (talk, contributions) 17:11, 1 November 2017 (UTC)
    • One difference is that the proposal there was "No administrator may accept payment to edit articles or to perform any administrative function on Wikipedia" (my emphasis). This suggestion is only about prohibiting paid use of tools. Boing! said Zebedee (talk) 17:17, 1 November 2017 (UTC)
    • And after reading a bit through it, the discussion is essentially about whether admins should be prohibited from paid editing. Boing! said Zebedee (talk) 17:32, 1 November 2017 (UTC)
  • Making rules that are impossible to enforce is...problematic. Honest people lose, liars win. As someone who has never gotten a dime for editing Wikipedia, I can only suggest (mostly facetiously) that all editors be required to give WMF regular copies of all bank statements. Or quarantine all editors on a desert island with internet access. What a nightmare this all is. If I had to guess, I’d say that at least 10% of political edits at Wikipedia are financed by somebody. Anythingyouwant (talk) 17:51, 1 November 2017 (UTC)
    • Locking your door does not prevent 100% of break-in, that does not make it useless. Wikipedia improves when good faith editors overall have a greater ability to contribute that bad faith ones. Rules help achieve a positive balance. Google Knol failed as it filled full of advertising. Doc James (talk · contribs · email) 18:06, 1 November 2017 (UTC)
  • Obviously the answer is 'No!' It's odd that the questions even have to be raised, but the goal therein is to make it absolutely clear, because paid editors - some of whom are notorious for their Wikilawyering - will use any 'omission' in the policies to practice their art. Kudpung กุดผึ้ง (talk) 18:01, 1 November 2017 (UTC)
  • Okay so with respect to wording, what do people thing about adding at WP:COI:
"No one may use admin tools or accepting articles at WP:AfC in exchange for a financial reward. Additionally the WP:OTRS system may no be used for recruiting clients or payment."
Doc James (talk · contribs · email) 17:55, 1 November 2017 (UTC)
  • In order to shine a light on this, if we read current policies as prohibiting administrators, editors or OTRS volunteers, from taking actions while at risk of being thought to be paid for those actions, then no funded academic, employee, Wikimedian in residence, should ever take any action using their editing/sysop/access rights which could in any way benefit their employer or funder, even the scenario often used in the past by certain employees that though they are employed, they were editing in their volunteer time... It might actually be better to highlight case studies where administrators that were in a paid contract or had a grant, did legitimately use the tools as they were the best person at that time to do so, while correctly handling their declaration of interest in a transparent way. There may be cases where conflicts of loyalty have nothing to do with money, and those may also make for useful case studies. -- (talk) 17:55, 1 November 2017 (UTC)
    • If you were a WiR at say the NIH and you protected all NIH related article without explicit consensus to do so, that would still be a problem. Doc James (talk · contribs · email) 18:08, 1 November 2017 (UTC)
    • (edit conflict) Some good points there, which were raised in that other discussion (I've just finished reading it). While we should certainly want to prohibit 'corrupt' use of tools, it's hard to word policy so it does not adversely affect honest use as in examples like those. Boing! said Zebedee (talk) 18:11, 1 November 2017 (UTC)
  • I fully support this. Nick (talk) 18:08, 1 November 2017 (UTC)
  • Anything other than "regular" editing (as can be done by an auto-confirmed user; a name-space restriction has too many edge cases to be reasonable) in exchange for payment should be strictly prohibited. The corner cases (what if a professor who is an admin does admin work on university time) can be figured out by lawyers, the spirit should be clear. power~enwiki (π, ν) 18:10, 1 November 2017 (UTC)
  • I also support making policy clear against potential corruption. I don't have a problem with Doc James formulation; it's of course always possible to improve it in the future for precision, i.e. WMF legal suggestions welcome... —PaleoNeonate – 19:36, 1 November 2017 (UTC)
  • My view: No editor should be allowed to use permissions given through community input or tools that allow editors to work in an "official" capacity (OTRS, etc.) to edit for pay. As long as a draft meets all normal AfC requirements, I'm ok with editors being paid for their work. Admins can be paid for their work as long as they don't use their admin toolbox in the process. Of course, all paid contributions should be declared. Gestrid (talk) 08:24, 2 November 2017 (UTC)
  • OTRS is outside of our domain, and it seems the question has already been answered. However, I'm not aware of any instance of an admin using tools for pay - I'd be hard pressed to think of a situation where that would occur. Do we need to prohibit a practice that doesn't happen? As to AfC, that is a common job request, so it does represent something that happens. My knowledge of AfC is limited, though - do you need special tools in order to approve an article from AfC? I didn't think that was the case, but maybe I'm mistaken. - Bilby (talk) 08:49, 2 November 2017 (UTC)
Bilby, Of course you're not aware of any instance of an admin using tools for pay. I'm not. Nobody is. They are not exactly going to yell it from the rooftops if they are. It's a very plausible concern and I can think of several situations where it might occur. Kudpung กุดผึ้ง (talk) 11:23, 2 November 2017 (UTC)
Hard pressed to think of a situation where an admin using tools for pay would occur? How about undeleting an article that had been deleted, unblocking a blocked paid editor, protecting an article at a favoured revision? It took me about 30 seconds to think of those three. Boing! said Zebedee (talk) 11:37, 2 November 2017 (UTC)
No, I'm hard pressed to think of a situation where an admin is accepting money to undelete an article. The advantages are clear, but I haven't seen an admin use the tools for pay, and I'm hard pressed to picture that situation arising. - Bilby (talk) 11:41, 2 November 2017 (UTC)
Several years ago, a Russian Wikipedia admin was desysopped for using admin tools to promote paid editing.--Ymblanter (talk) 17:24, 2 November 2017 (UTC)
One instance, several years ago, on a different language Wikipedia. Ok. But has this ever happened here? I agree with the principal - no admin should use the tools in return for pay - and if the community wants that to be clearly stated I'm a bit concerned re WP:BUREAU, but it doesn't bother me overly much. I do worry about "the sky is falling" policy changes, though, and pushing through changes without evidence of there being a need for them. - Bilby (talk)
Did you ever hear, (until now), that somebody was actively using OTRS to recruit clients and solicit payments?Winged Blades of GodricOn leave 10:21, 4 November 2017 (UTC)
I can testify for my own part, that this case was particularly egregious and lost me a bit of sleep thinking about it. I realize it may not look that way from our end, but from the perspective of our readers, OTRS is in few ways a higher position of trust than being an admin on wiki. From the perspective of readers, they're getting an email from Wikipedia, and not a message from some anonymous user on Wikipedia. I think per discussion below, I'm personally leaning toward favoring something along the lines of No one may misuse a position of community trust... and perhaps specify that this can include user rights, various coordinator positions, and off wiki access like OTRS and ACC. GMGtalk 10:29, 4 November 2017 (UTC)
The problem with OTRS was a serious one, but that should be handled through OTRS. As I said, I'm not opposed to this on principal. My concern is that I'm seeing a lot of rhetoric and exaggerated claims about paid editing which are leading us to take more extreme steps, but not a lot of data to back up the specific claims. Given that I can't imagine any current admin accepting money to use the admin tools, the change in policy is moot, and I'll support a well worded proposal. It doesn't prevent anyone from doing anything that they were going to do. But I do want to be cautious of inventing problems that don't exist. - Bilby (talk) 11:10, 4 November 2017 (UTC)
Well, at least to my mind, the admin bit isn't really special here. It's just one of many rights or positions, of which there are many requiring both more and less community trust, and more or less oversight. And this isn't an expectation of admins; it's an expectation of everyone, and admins are an everyone. The key common factor there is the trust, not the number of buttons. For example, autopatrolled users are trusted by the community to make acceptable quality articles that don't require community review.
Also pretty much just to my own mind, there are really two distinct types of policy formation. There's policy that attempts to create new process to deal with outstanding problems, and there's policy that simply documents widespread community practice that's already in place, but hasn't been explicitly written down anywhere. I believe this is the latter. It's already a de facto policy. When we have, and if we do find someone abusing positions of trust, we will remove them from that position. That's a fact. But we currently don't appear to have explicit, unequivocal wording that says You knew this was going to happen when you made the decision to abuse your position or access. GMGtalk 11:26, 4 November 2017 (UTC)
I understand where you are coming from - I am fully in agreement that admins should not use tools for pay, with the various normal exceptions for WiR and whatever. My caution comes from seeing what can only be described as a war between paid editors and anti-paid editors, and in that war we're giving up progressively more. Thus I need to ask, every time a new policy change is put forward, the basic three questions - is it needed, will it work, what will it cost? This one costs nothing, in that it is such a specific case that it won't have a wider impact. But it isn't needed, because we have no evidence of this ever happening on en.Wiki. Will it work? I can't see how anything can "stop" something that doesn't occur, but I think we'll find that this is going to be very hard to prove to the level where we can desysop someone if it ever does arise, and that from a practical sense we'll end up using a different justification.
In regard to other tools, though, the approach doesn't seem to be the best solution. With AFC, I think we need a clear statement that says "you cannot approve any draft in return for financial remuneration" - it isn't about the use of tools, but the act of approving a draft. Focusing on the tools is the wrong part of the equation - someone just needs to take the longer process of approving it without any special permissions to meet the policy. Similarly, if we remain worried about auto-patrolled users, we need to say that all paid articles must be created through AfC is we want a real fix. It isn't the auto-patrolled status that is the core problem, but paid articles being created in mainspace and not being independently verified - although there will be more of a cost if we make that change. - Bilby (talk) 11:49, 4 November 2017 (UTC)
Not to beat the horse into a pulp, but to focus narrowly on existing community practice and reasonable expectation of future practice:
  • When we have found users abusing AfC for paid editing, we have removed their access;
  • When we have found users abusing OTRS for solicitation, we have removed their access;
  • If we did find someone abusing autopatrolled to avoid scrutiny of paid articles, we would remove it;
  • If we did find an FA coordinator, a member of the ArbCom electoral commission, etc. abusing their position, we would remove them from it;
  • If we did find a sysop doing this (as other projects have), they'd have their mop snatched so fast it would cause whiplash;
So that raises the question to me, of why we haven't taken the time to write this down, when we seem to all agree to some extent that it is the way things work, and the way they can be expected to work for the foreseeable future. GMGtalk 12:05, 4 November 2017 (UTC)
I don't understand enough about OTRS - my assumption is that it was a meta issue, not a en.WP issue, but if I'm wrong it is something to address here.
In the case of ArbCom, FA coordinators and admins, you are correct - we'd act if we found them. In general I don't really care if we wish to formalize those issues, except to note that we're formalizing something that we've never done, never had to do, and which would happen irrespective of any decision here. I'm wary of the principal of creating unnecessary changes. (I'd also note that, if policy reflects practice, in these cases we're reflecting what we believe would be practice, not what actually is, simply because it has never arisen).
With autopatrolled, yes, we would (and have) removed it. Let's put that in Wikipedia:Autopatrolled as the relevant place to discuss this and make the change. This one is far more important to me, and reflects something that we do, should do, and should formally note.
AfC is the other big issue to me - I would like to see that hole filled, as there are a lot of jobs hiring people to pass articles at AfC. But it isn't the tools that are the issue, so much as the approval. I'd like to see a more important change stating that articles cannot be approved from AfC in return for pay, as that would address the actual problem. Focusing on the tools rather than the approval is an error.
Just to be clear, my disagreement isn't with the spirit of the proposal, but with the two basic issues - I don't like creating policy changes that are not needed, and I don't care for skirting around the real issues (permissions) when we should be addressing the actual problems (approving articles for pay; creating paid articles in mainspace). - Bilby (talk) 13:03, 4 November 2017 (UTC)
Well... it seems the main difference in approaches is that you would like to wait until each individual right or position is abused, and then add a specific policy on that specific topic. (Also, BTW, OTRS is stand alone project and AFAIK the only one running media wiki that doesn't accept SULs.) To my mind, it just seems simpler to put a blanket statement on a central place, like PAID. GMGtalk 13:11, 4 November 2017 (UTC)
Not quite. I have two main differences. a) I'd like to address the real problem at AfC of approving articles for pay, rather than tackling the secondary (and mostly irrelevant) issue of use of permissions. b) I don't think we would need to change in policy even in the unlikely chance that the problems with FAC coordinators, admins or ArbCom members arose, because we would solve it without a change in policy. In that situation, I don't like creating policy changes to address remote issues that have never arisen and wouldn't need a policy change if they ever did arise.
I'm sure we'll end up with a blanket statement at paid. And WP won't end as a result. But I wish this energy went into changes that would have an impact or would address the real problems. - Bilby (talk) 13:22, 4 November 2017 (UTC)
That's part of my concern though, that if we have a blanket statement, we have one arguably time wasting discussion. If we do it piece meal, we end up with separate recurring discussions for each individual piece. GMGtalk 13:49, 4 November 2017 (UTC)
I'm sorry, I think I've been explaining things badly. If we have this discussion and agree to make this change to WP:PAID - which it is likely we will if we can get the wording right - it won't make any difference to how we respond to the main cases you raise: admins, FaC coordinators and ArbCom members. It may not do any harm, but it won't change the response, make it more or less likely that the problem will arise, or make things any easier if the situation ever appears.
In regard to this change and AfC, based on what I was told below, all the paid editor needs to do is not use any advanced permissions to pass something through. They can either argue that use of the helper script is not an advanced user right, or they simply don't use the script and do it the long way. That's because the AfC problem is not about permissions, but about actions. So if we make this change, we will still need to have another discussion to address the real problem.
In the situation of auto-patrolled users, the change I'd most like to see isn't a ruling that paid editors can't create pages in mainspace if auto-patrolled, but a rule that says that paid editors cannot create pages in mainspace. That second one seems more valuable to me, and will also involve a separate discussion.
Anyway, this is not of much value, because we're having the discussion however I may feel about it. :) Which is fine. But I've been arguing against paid editors for many years now, and what I'd most like to see is discussion around actions which will address the core issues without harming the project. This discussion has the advantage of not harming WP, but it retains the disadvantage of not addressing the problems that matter. - Bilby (talk) 14:19, 4 November 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Well, part of my concern is once the issue of the paid OTRS agent was raised, it took several days for access to be removed. Even after the evidence was damning, it didn't seem like anyone wanted to unilaterally pull the trigger. Yes, it's technically a separate jurisdiction, but for English agents, it's pretty much the same cops on the beat. (I don't know of specific instances where autopatrolled has been removed for paid editing, but I'd be interested to.) This is the kind of thing that is to be expected where sysops, ideally cautious by nature, are in fairly uncharted territory as far as the letter of the law.

As to AfC, that and the issue of non-user right positions (coordinators, etc), are the reasons for my focus on emphasizing "positions of trust" and not just user rights. From a lower level implementation standpoint, if there is a project wide policy in place to that effect, project or right specific policies can probably for the most part be boldly added, and simply point to the main. Something along the lines of:

No user may use positions of community trust in order to solicit or accept payment for activities which have a direct and foreseeable impact on Wikipedia. This includes advanced user rights for which individual vetting and permission granting is required, positions of authority elected or appointed by the community, and system access on or off wiki not normally available to all users.

I think something like that would fairly well cover everything, including OTRS and AfC. GMGtalk 15:57, 4 November 2017 (UTC)

GreenMeansGo: to your question, the same OTRS agent Doc James mentioned above voluntarily relinquished their autopatrolled flag after I suggested it to them when the issue was first raised. We have no policy as to when to revoke user permissions in cases like this, and as a recent ArbCom case pointed out, the removal of user permissions is one of the most controversial things an admin can do.
Re: your proposed wording, I think I like it. I might also add something such as ...impact on Wikipedia; or use such a position to take actions on behalf of a client. for clarity. TonyBallioni (talk) 16:05, 4 November 2017 (UTC)
My issue with raising OTRS here is not that it hasn't proven to be an issue, but that my understanding is that OTRS policy is managed at meta, so I assumed that a change in that policy in regard to paid editors has to be presented and discussed there. If this is not the case I have no problems with agreeing to the policy change here, but I had always assumed that OTRS policy is outside of our immediate control.
I still need to return to my issue with the AfC problem. I do not see permissions or "positions of trust" as the primary concern, based on what I've been told. What I think we need is not the change being discussed here, but a clear and unambiguous change to Wikipedia:WikiProject Articles for creation that states that you are not permitted to approve an article where you have a COI, and in particular you are not permitted to approve an article in return for remuneration. It isn't about positions of trust or advanced permissions, but simply who can and cannot approve an article. - Bilby (talk) 16:28, 4 November 2017 (UTC)
Well, my thought was that AfC would be covered under system access on or off wiki not normally available to all users. It's true that can't actually enforce anything at OTRS. But I think we can probably still say that someone abusing OTRS to make changes to is exactly half in jurisdiction, and we can still say that we don't approve of it.
Also, I'm fine with Tony's suggested addition. And I think the absence of policy on when to remove these rights is part of the problem, and part of why sysops are rightfully hesitant to do so. GMGtalk 17:00, 4 November 2017 (UTC)

    • Yeah, AFC Reviewers need access to a helper-script, designed for the purpose, that heavily eases the process/workflow.It may be noted though, that all auto-confirmed editors have the right to move articles from draft space into mainspace or that any body could choose to follow a tedious manual reviewing process, that existed before the development of the script.Winged Blades of GodricOn leave 09:08, 2 November 2017 (UTC)
      • In that case, there are no special permissions needed for AfC? Just optional access to a helper script that is open to any autoconfirmed editor? - Bilby (talk) 10:08, 2 November 2017 (UTC)
        • Manually reviewing articles is sufficiently tedious so as to be prohibitive for most users. It is a de facto user right. GMGtalk 10:27, 2 November 2017 (UTC)
        • Echo Timothy.In a very strict sense, AFC is not a right.But, in my wiki-life, I have neither seen someone evading the script-access-barrier by manually reviewing the submissions nor someone who is moving other author's AfC draft(s) to mainspace without using the script.Winged Blades of GodricOn leave 10:45, 2 November 2017 (UTC)
          • I guess what I'm wondering is if you need special community-granted permission to use the tool. Is this the case? Or an anyone use the tool? - Bilby (talk) 11:41, 2 November 2017 (UTC)
            • AfC works similarly to rights granted at PERM, but at a different venue. All you need is to convince one sysop that you're competent. The major differences are 1) it doesn't automatically come with the admin kit, although theoretically any admin could grant it to themselves, similar maybe to the way some things work with stewards (unless I'm mistaken), 2) it's not technically required for reviewing, but it's a bit like saying you don't technically need access to the elevator to get to the top of the Eiffel Tower. GMGtalk 11:49, 2 November 2017 (UTC)
  • There was "consensus for some language on this issue" last time and it is still a good idea, so support. Alanscottwalker (talk) 10:57, 2 November 2017 (UTC)
  • Regarding Doc J's wording, if it is to be used, it may be simpler and more effective to say No one may use advanced user rights.... I have a hard time imagining a scenario where any right couldn't potentially be abused, which is why they're restricted. In fact, with ACTRIAL in effect, it could be easily argued that creating a paid article outright, instead of going through AfC is itself a type of abuse of auto-confirmed.
For rights with a greater potential for damage (e.g., sysop, AfC, page mover, AWB), and especially for those which have a comparatively limited amount of public oversight (e.g., OTRS, CU, OS)... Well... until very recently I should have thought that this actually didn't need to be spelled out at all, and that anyone with enough sense to use them would have had enough sense to assume this as a matter of course. But since the laundry list of rights and the myriad ways they could be abused is so lengthy, probably best to spell out the principle, and let the community decide the specifics, For example, is it an abuse of auto-patrolled if an editor doesn't unreview their own paid article creation? I don't know that we've ever needed to answer that question, but we might at some point. GMGtalk 10:59, 2 November 2017 (UTC)
Actually, after thinking my way through a hot shower:
  1. It may be better to say No one may use abuse advanced user rights...
  2. I realize most autopatrolled users probably can't unreview their own article in the first place, because they probably don't have NPP. Which adds another layer of hypothetical problems.
  3. It's not entirely clear that pieces of the admin kit that non-admins may also have should be on the one hand, specially covered for sysops, or on the other, specially exempted for non-sysops. GMGtalk 11:10, 2 November 2017 (UTC)
  • No to allow use of "community granted tools in exchange for money" - for all the obvious reasons. Yes to policies that disallow it.Atsme📞📧 11:56, 2 November 2017 (UTC)
  • An even more perverse variant of this problem crops up periodically at AFC. An author/submitter of a declined (or deleted) draft is contacted off-wiki by someone who claims they will approve (or undelete) the page for payment. This practice of holding a page (draft or mainspace article) to ransom has been condemned as a form of extortion. There is a standing request that all such incidents be reported to WMF Legal. Roger (Dodger67) (talk) 12:07, 2 November 2017 (UTC)
  • NO - No one should be paid this way. This smacks of bribery. ←Baseball Bugs What's up, Doc? carrots→ 12:15, 2 November 2017 (UTC)
  • No- this is a horrible idea. Reyk YO! 12:21, 2 November 2017 (UTC)
  • I'd like to be clear that the question here is quite different from "Can an editor simultaneously be a paid editor and have access to certain user rights, so long as they do not overlap those roles?" ~ Rob13Talk 14:12, 2 November 2017 (UTC)
    • I'd planned on commenting on this today and it was closed before I could. Rob makes a good point, and I think it is worth clarifying if there are circumstances when being paid is incompatible with a role: the only thing I feel somewhat strongly about in this regard as an absolute no is the autopatrolled flag since it's impossible to turn off for only paid articles. Other areas I do think need clearer guidelines as well, and I think this is a first step in the direction of setting up those guidelines. Obviously this is a nuanced topic where there are strong opinions on both sides by the community, and I think further discussion (if not on this question then on other questions) is needed. TonyBallioni (talk) 14:24, 2 November 2017 (UTC)
    • (+1) to Rob's queries.But, primarily this discussion has in itself stemmed from an overlap.I have requested CPower678 to vacate their close.Winged Blades of GodricOn leave 14:40, 2 November 2017 (UTC)
      • The close is fine, mostly because the question as posed was wrong. The question is "should volunteers in roles of trust be allowed to use their tools for money?" The answer is a snow no, which is obvious. There is quite a separate question of whether volunteers can both hold roles of trust and separately be paid. For instance, should Wikipedians-in-residence be able to be admins? That is a very nuanced issue that would need a very different discussion. We can't have that discussion when it starts with such a flawed question. ~ Rob13Talk 14:59, 2 November 2017 (UTC)
At least to my mind, one of the more intuitive ways to go with this is that if you have an account with basically any userrights other than extended confirmed or autopatrolled, and you want to do disclosed paid editing, then you need to register a separate account for the sake of propriety. GMGtalk 15:11, 2 November 2017 (UTC)
As to off wiki access like OTRS, that's a blanket no from me. It can't be separated technically, since access is granted to a person, and not to an account, and it has comparatively little oversight. Probably similarly with CU since they have access to private information, possibly also ACC, and being part of ArbCom is right out. (Jesus this list gets long fast.) GMGtalk 15:14, 2 November 2017 (UTC)
(edit conflict) The WiR issue in particular is complex because while generally a wonderful program it has caused issues in the past (I think I'm thinking of one WiR who copied compatibly licensed advocacy pieces into about 6 months back). That being said, having worked with Doc James on PAID issues several times, he typically is not referring to individuals employed by orgs that share the WMF's mission and values (the WiR program or similar), but to those who are paid to edit commercially.
This could be spelled out better, I agree, but I don't think the question is fundamentally flawed: establishing a principle that people agree on has value, even if it is only a very basic one. That gives a starting point for agreement for any future conversations on the issue, which as Rob rightly point out will be nuanced out of necessity. TonyBallioni (talk) 15:17, 2 November 2017 (UTC)
The UNESCO fellow? GMGtalk 15:20, 2 November 2017 (UTC)
That's the one I was thinking of. TonyBallioni (talk) 15:25, 2 November 2017 (UTC)
Rob, the question, flawed or not, concluded with "or should we have policies clearly disallowing this.". The close failed to address that adequately, or explain why it was overlooking it. I agree with your other sentiments, and a close thus explained would have been fine. -- Begoon 15:28, 2 November 2017 (UTC)
  • No since this is open again, the answer to the question asked is clearly no. I also disagree with Rob that this is a flawed question, and think we can set out some general best practices here for the less complex cases that will make the more complex cases easier to deal with when the time comes to have conversations on those issues (call it the baby-steps approach if you want). These are the policy things I think are fairly easy to deal with:
  1. No one should use a position of community trust to solicit payment for services rendered on Wikipedia.
  2. No one should use any user rights or positions of trust to advocate for their clients or to make technical changes that would not otherwise be possible if they did not have the rights (i.e. an admin undeleting a page or a page mover skipping the RM process for a controversial move over a redirect, etc.)
  3. Technical permissions, use of tools requiring a checklist, and positions of trust that involve new content cannot be used to evade our normal scrutiny system for new content and COI content.
I think these three principles are things most people can get behind, and can help be the policy basis for any guidelines on how to apply the principles that Doc James is asking about. There are obviously others that might be able to be agreed upon as well and questions that can be raised regarding these points, but I think they would provide a basis for future discussions on the more nuanced and complex cases. TonyBallioni (talk) 15:42, 2 November 2017 (UTC)
  • Comment I've seen questions raised about whether buying access to admin capabilities is really a big deal. Yes, it is. Look at the number of admins whose talk pages are filled with begging from conflicted editors whose articles were deleted. Won't spell this out due to BEANS but the possibility for a rent-seeking admin with access to deleted revisions are obvious. Also, very few people know about this, but I've communicated privately my evidence-based concern about at least one other CU confirmed socking account that was trying to gain access in 2015 to OTRS. There are good reasons to believe the socking was undisclosed paid/advocacy editing-related as is often the case. This is a big deal since OTRS handles all kinds of private, confidential information that could lead to WP:OUTING at the very least.
If you can't tell I'm leaning very hard towards "no" on the question, but want to see some refinement of the terms before making a commitment. Behavior that even smells of rent-seeking and bureaucratic malfeasance, aka bribery, could be another piece in the puzzle that results in the end of this worthwhile project. ☆ Bri (talk) 17:35, 2 November 2017 (UTC)
  • Yes? I think Anythingyouwant sort of addresses my viewpoint. There's an unmet need in the economy for moving drafts through AfC and getting images approved at OTRS. I would never want to turn either of those processes into pay-for-play and perhaps that's what the opposition is scared of. The fact is, volunteers do a poor job of meeting our various backlogs. Wikipedians edit where they find satisfaction and avoid the drudgery that's needed to keep our maintenance effort going. So long as editors divulge their payments per ToU, I don't see the problem. I don't think money is universally corrupting. I'd like to see our hard-working Wikipedians get paid for their work, and I'd love if some of our most-talented Wikipedians could make a living off of editing just as we're happy to see our favorite YouTubers be able to focus full time on their content work. Disclosure is the sunshine treatment that prevents corrupt activity. If the WMF would stop spending money on un-asked for coding projects and started on-going investigations for business promotion (among other problems) I think introducing a pay mechanism would help us refine product. I know I've enjoyed getting paid to edit; sadly there aren't many reasonable opportunities anymore. Chris Troutman (talk) 21:42, 4 November 2017 (UTC)
  • Hell no and props to Doc James for raising this issue. Support a common-sense prohibition. Coretheapple (talk) 17:14, 5 November 2017 (UTC)
  • NO in the strongest possible terms - This does not conform to the spirit of the encyclopedia. - Knowledgekid87 (talk) 16:19, 6 November 2017 (UTC)
  • Once again, we have a proposal that would, whether intentionally or not, stop or hinder Wikimedians in Residence in their valuable work. "Should Wikipedians be allowed to use community granted tools in exchange for money?" What, like when I use my account creator status to set up accounts for attendees at an editathon I'm running, as a paid WiR, even thought it was given to me for that purpose? I mustn't move an article that one of my trainees creates? I mustn't use AWB, or rollback, or mark an edit as patrolled, in my WiR role? "No one should use a position of community trust to solicit payment for services rendered on Wikipedia." So, when I apply for a paid WiR role, I mustn't mention my experience as a Wikimedian? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:28, 24 November 2017 (UTC)
Usage of ACC right for editathons etc. and WIR does not fall under the purview of this discussion. Winged Blades Godric 15:05, 24 November 2017 (UTC)
  • No - it seems I inadvertently said this twice; see my comments below under Kudpung's proposal. Ivanvector (Talk/Edits) 15:51, 4 December 2017 (UTC)

We just need acceptable wording and a place to put it

I agreed with the now retracted close. This is a "snow no" to allowing people to use positions of trust and tools for personal enrichment. There are many cases covered here, mainly at AfC, OTRS, and admins, so we need to refine the wording and place it in the right policies. I say policies in the plural because paid editors routinely ignore guidelines and because OTRS is regulated on enWiki by Wikipedia:Global rights policy, admins are regulated at WP:Admins (specifically at WP:Involved}, whereas AfC reviewing is not regulated by any policy that I know of, only by Wikipedia:WikiProject Articles for creation.

I suggest similar wording for all the above, based on User:TonyBallioni's wording just above. Once we get the wording to almost everybody's liking, then place it for an RfC at WP:GRP and WP:Admin. I'll be bold and start the discussion at Wikipedia:WikiProject Articles for creation soon myself.

Basic wording:

No editor may use a position of trust or any user rights to:

  • solicit payment for services to be rendered on Wikipedia, or
  • accept payment for the use of such a position or rights
    • for the benefit a client
    • for advocating for a client, or
    • to evade our normal scrutiny system for new content and COI content.

Payments and grants made by the Wikimedia Foundation or its affiliates (e.g. chapters) are excepted.

Please see AfC and the related talk page. Smallbones(smalltalk) 18:38, 2 November 2017 (UTC)
  • Support since it is based on my wording above, see my reasoning there. I would also extend this to NPP/the NPR flag as well as AfC because that is what gives a user the ability to mark a page for indexing by Google. This wording should cover that, but I did want to mention it explicitly in my support. TonyBallioni (talk) 18:40, 2 November 2017 (UTC)
  • Support as initial wording, without prejudice to editing or improving as with any policy. This seems concise, reasonable, and easy to understand. Everything a policy needs to be. --Jayron32 19:04, 2 November 2017 (UTC)
  • Comment How would this apply to Wikipedians in residence (i.e. people who edit on behalf of universities, libraries, and museums). I personally know someone who was paid by a museum to help write articles on 100 notable New Zealand craft artists as part of a GLAM project. It seems like the wording used here could be made to apply to that project as well. "any user rights" seems ambiguous. I am extendedconfirmed, does that count as a 'user right' in this context? Does that mean that autoconfirmed users are not allowed to use the perks of that 'user right' (i.e. creating articles) to create articles for pay? Or is this meant to only apply to user rights that are community granted (i.e. page mover, rollback). — Insertcleverphrasehere (or here) 19:53, 2 November 2017 (UTC)
    • It'd be pretty simple to deal with WiR's would create distinct accounts, which they do anyway normally, and in most cases, I would expect the accounts wouldn't have additional flags. Autoconfirmed isn't a flag but an implicit group that is determined every time a user action is attempted. Extended confirmed is a flag, but it is automatically granted, so I'd assume we'd use common sense and treat it the same as autoconfirmed. TonyBallioni (talk) 20:23, 2 November 2017 (UTC)
  • Comment I agree with ICPH any paid editor (disclosed or otherwise), any wikipedian in residence that uses an autoconfirmed user right to create a page or even just to edit is in breech of this text; Wikipedia:User right is redirected to WP:User access levels and ALL user groups have right attached to them. Domdeparis (talk) 20:08, 2 November 2017 (UTC)
  • Those creating articles for pay are to go through AfC. Doc James (talk · contribs · email) 20:18, 2 November 2017 (UTC)
  • As I mentioned above, autoconfirmed is not a user right. It is a test that the software does automatically when any action is attempted. TonyBallioni (talk) 20:23, 2 November 2017 (UTC)
You might be right about autoconfirmed. — Insertcleverphrasehere (or here) 21:36, 2 November 2017 (UTC)
Insertcleverphrasehere: yes, this is made clearer in Special:UserRights. See yours here. It lists autoconfirmed as an implicit membership rather than a membership. Its just a software check. From the admin side of it, we can't revoke autoconfirmed status once it has been achieved (there is no tick box for it, and removing the confirmed tick box on the rare occasions that flag is granted does nothing once someone meets the software requirements). TonyBallioni (talk) 21:44, 2 November 2017 (UTC)
  • Support Doc James (talk · contribs · email) 20:18, 2 November 2017 (UTC)
  • I definitely support a prohibition such as this. I would suggest that the way to distinguish someone like a Wikipedian in residence etc. from what we want to prohibit, is that the prohibited conduct occurs when there is a quid pro quo in exchange for something that would not be approved if it were out in the open. --Tryptofish (talk) 20:21, 2 November 2017 (UTC)
    • Tryptofish, WiRs who have distinct accounts for their work as a WiR would be in compliance with the user permissions part of this since that role account would not have additional permissions. We do want to prohibit a WiR who is also an OTRS agent (or hell, hypothetical future arbcom member) from using that position to somehow advance the cause of the org they are being paid by just as much as we'd want to prevent those paid for commercial purposes. The WiR program is good but we also need to recognize that some of them do have a COI on advocacy issues, and that the same principles apply to them as well. I think the overwhelming majority would not abuse it, but I don't want to exempt them completely. TonyBallioni (talk) 20:29, 2 November 2017 (UTC)
      • I agree with what you say. I didn't mean to make it sound like I was saying that there should be anything special about WiR, but I see now that it sounded that way. What I meant was distinguishing acceptable from unacceptable conduct. And I think that what defines unacceptable is (i) a quid pro quo and (ii) a result that would have been opposed by the community if it had happened out in the open. --Tryptofish (talk) 20:34, 2 November 2017 (UTC)
  • Comment - I don't know if this is exactly the right wording, someone can probably improve upon it, but I would suggest going with something more like No editor may use advanced user rights requiring community trust.... Auto confirmed and Extended confirmed are both user rights, but they're not really an expression of community trust, and they're not really a user right in any meaningful sense that we are talking about now. As for the rest of it, if we did have a user with advanced rights go out for WiR, I think it would be totally appropriate for them to either request their rights be temporarily removed, or register a disclosed second account, especially as it concerns auto-patrolled and sysop. I don't really see a reason why a WiR would need to be active at places like NPP or AfC anyway. GMGtalk 20:24, 2 November 2017 (UTC)
I'd support this proposed change in the wording (which I believe was the original and understood intent of the version proposed above). I propose that we amend the proposal to this new wording, and then continue the voting. — Insertcleverphrasehere (or here) 22:11, 2 November 2017 (UTC)
If we are going to change it lets just come out and add normal editing by autoconfirmed or extended confirmed users is not considered use of permissions for these purposes or something like so we don't get into quibbling as to what an advanced permission is or which ones require community trust. TonyBallioni (talk) 22:19, 2 November 2017 (UTC)
Umm... I think I actually disagree on one point. I think the purpose is kindof to be intentionally vague to some extent, and let the community decide the specifics in an actual situation. GMGtalk 22:30, 2 November 2017 (UTC)
Not all forms of advanced editing privileges requiring community trust are backed by user rights. I wouldn't want FAC coordinators accepting money to get commissioned articles on the Main Page, for instance. MER-C 12:57, 3 November 2017 (UTC)
Ah ha! Now this is actually a very good point indeed! There are actually quite a bit of coordinator type positions that have nothing to do with a user right in the software but could be just a easily used improperly and in many cases with greater effect. This should probably be covered here somehow. GMGtalk 14:12, 3 November 2017 (UTC)
  • Oppose for now. I'm 100% in support of the sentiment here, but I still think the wording is a little vague. For instance, last year I spent some time in a paid WIR position. I registered a separate account, and made it clear that I would not be using any of my admin/functionary access for anything related to my work as a WIR. I kept the separation going to the point of CSD tagging old userspace drafts rather than deleting them myself. I did not make a secret of the fact that I was an administrator before taking the job, and I suppose that an overzealous individual could say that by making this clear I was trading my 'authority' as an admin and trusted user in exchange for a job? I am also not sure what problem this instruction creep is going to solve, as in the KDS4444 situation the user was quickly evicted from OTRS once their conduct was discovered without the need for a policy change. This does have the smell of security theatre about it. Lankiveil (speak to me) 02:17, 3 November 2017 (UTC).
    • Wikipedians are not the only audience for this policy. This creates a policy we can point to when reporting spammers to freelance job sites and/or in OTRS tickets regarding commissioned articles. MER-C 12:52, 3 November 2017 (UTC)
  • No editor may use a position of trust... may be overly broad. If you were going to legitimately hire someone to make non-promotional edits, you'd want to engage someone who was trusted by the community. Conversely, if an editor is going to provide copy-writing services, the community should prefer someone who is trusted to follow policies, guidelines, and best practices, versus someone who has failed to be proven trustworthy. isaacl (talk) 03:05, 3 November 2017 (UTC)
  • Support in principle. Wording wise, I suggest something like "Editors with advanced editing privileges requiring community trust must not solicit or accept payments for using said privileges to advocate for or on behalf of a client or circumvent normal editorial processes regarding new and COI content". As for placement, why not put it in WP:PAID as well? MER-C 12:52, 3 November 2017 (UTC)
  • Comment Personally I would go even further and require that any advanced user right cannot be *held or granted* if you are engaged in or offering any commercial or otherwise paid service related to Wikipedia. The inherent conflict of interest that receiving money for services engages means that its too much of a risk. Only in death does duty end (talk) 17:14, 3 November 2017 (UTC)
  • Support, with wording to be refined, particularly regarding acceptable exceptions. And yes, per Only in death, no advanced right or permission should be granted or allowed to paid editors. Justlettersandnumbers (talk) 20:24, 3 November 2017 (UTC)
    I don't see that working generically for practical reasons. The GLAMwikitoolset right has been given to GLAM and Wikimedia Chapter employees for their "official" user accounts in order to manage donations of image archives to Wikimedia Commons and in some cases to run bot-generated reports (with granted bot flag) to support reuse on Wikipedias. They were being paid to do the work, and there is no reason to waste valuable unpaid volunteer time when projects like these are run transparently. -- (talk) 22:56, 3 November 2017 (UTC)
    @: minor questions. a) Is this being run to make edits on enWiki? b) is this right covered at WP:GRP? c) does my proposed wording below make your objection mute? Smallbones(smalltalk) 16:30, 4 November 2017 (UTC)
, what I said in my first short sentence above ("wording to be refined, particularly regarding acceptable exceptions") should be taken as applying also to what I said in the second sentence. Also, what happens on Commons happens on Commons; my opinion expressed here on Wikipedia relates specifically to this project. Justlettersandnumbers (talk) 18:43, 5 November 2017 (UTC)
  • Oppose. I'm ok with the principal, but what is meant by "any user rights"? That seems overly broad. The wording makes it sound as if anything you can do as a user - create new articles, edit, revert, etc - would fall under this. The wording needs to better reflect what rights are at issue. - Bilby (talk) 08:14, 4 November 2017 (UTC)
  • Oppose. The suggestion is that "payment for service" is automatically harming the encyclopedia, that is just suspicion, it's possible to be paid for doing good work, it's also possible for an admin to put their responsibilities to the community last or first, paid is not proof of a problem, it's only proof that we don't trust them. The heart of the issue isn't WHY the editor, or admin might be acting against the community, only that there is a problem with what they actually did. So lets be focused on behavior not mistrust. Dougmcdonell (talk) 19:17, 4 November 2017 (UTC)
Prohibition statements etc. in policies/guidelines oalmost always reflect upon the behaviour of common folks, not that of the outliers.Though, if you had choosen to oppose, because you think, that there's no problem in any editor soliciting payment(s) from potential customers through OTRS channels (as long as the worth the article he/she later churns out is satisfactory) or somebody self-patrolling his own paid creations, despite the elements of obvious cognitive bias or some sysop restoring articles, declining CSDs, closing AfDs in lieu of payments, it's another case.Winged Blades of GodricOn leave 14:05, 5 November 2017 (UTC)
  • Oppose I think Wikipedians should always be able to solicit "payment for services to be rendered on Wikipedia". Chris Troutman (talk) 21:46, 4 November 2017 (UTC)
  • Support long overdue. Coretheapple (talk) 17:16, 5 November 2017 (UTC)
  • Support in principle and most specifics; I prefer the slight modification in the next subsection. It's concise, non-bureaucratic, and consistent with the general community take on these matters. We know there'll be some paid/COI editing, and consensus implemented policy about it. This just closes a loophole.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  00:23, 11 November 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── With very few exceptions there are no opposes here based on principle. We're just arguing about wording (and where to put that wording). Within the limits of my available time, I'll keep coming back to this. There are several places to put this, and I think several are needed since advanced rights are covered in several places. Progress so far:

Other discussions, with possible wording changes, will have to be held at WP:GRP (for ORTS) and WP:Admin. I don't expect any opposition at WP:GRP, and will start that discussion on Monday. My suggestion for wording follow. I'm just adding a line on Wikipedians in residence, but please note that the "who" in the 1st line will change based on where the policy is proposed. Once everything is done, we can then summarize the changes at WP:Paid.

  • I don't get it. As far as I can tell, using any bit in exchange for money is already disallowed so outlining rules for it just makes it easier to game. Anyone misusing any bit is subject to having that bit removed. Doing it for pay is clearly misusing it. There really is no question about it. Any admin unblocking for cash would be dragged to Arb and bit stripped, for instance. No one would oppose that. A new rule is superfluous. Dennis Brown - 20:14, 18 November 2017 (UTC)
  • @Dennis Brown, the TOU—even in the brave new world of the WMF crackdown—aren't as clear-cut as you think, and there are still quite a few loopholes. Show me where in policy it's forbidden for an admin to profit from their access to deleted revisions, for instance—and that's something that does have commercial potential, there are ad-funded websites that literally do nothing but host deleted Wikipedia articles (Deletionpedia is the best-known). ‑ Iridescent 20:23, 18 November 2017 (UTC)
  • As long as policy is based on consensus and consensus is overwhelmingly against selling use of the bits, then it seems obvious to me. If I find any admin using any bit for gain, I won't hesitate to block them, for example. I don't need a specific policy statement, WP:COMMONSENSE covers it well, as bits are based on trust that they will be used only to benefit Wikipedia. Any use of the bit to gain advantage, be it financial, in an edit war, or otherwise, is grounds to lose the bit. Any bit. The community has already said this by providing a vetting system for all the bits, and policies on use of each of the bits. Anyone that doesn't understand that shouldn't have advanced bits, as the reason we have them is to benefit the encyclopedia, not ourselves. I'm afraid once you start setting specific rules, you start creating loopholes. As it is now, ANY misuse of any kind, even those we can't think of ahead of time, is grounds to lose the bit. I truly feel we codify too much that is already covered by common sense, and that is part of the problem with the contradictory maze of policies we have. Dennis Brown - 01:35, 19 November 2017 (UTC)
  • Without a policy to back it up, the odds of a desysop from arbcom are negligible. Sure we could go the community ban route that we went with within the last few days for an OTRS agent, but that would also lead to the inevitable arbcom case. TonyBallioni (talk) 01:45, 19 November 2017 (UTC)
  • I have a bit of a counter-proposal to this, which is that rather than setting out prohibitions for paid editing activities, we should merely set out a very tightly limited list of what paid editors can do, and specify that any action not on that list is prohibited. The list would be something like, following disclosure of having been paid, adding reliably sourced information to a draft, or proposing on an article talk page that content be added or changed. If that is the complete list, then obviously things like unearthing deleted edit histories would be outside the scope. bd2412 T 20:28, 18 November 2017 (UTC)
    • As the United States discovered when it tried to ban alcohol, it is very difficult to regulate that which you prohibit, and I think your proposal comes so close to prohibition that the same principle will apply. If you make the rules too onerous, then at some point paid editors will just not disclose their paid status. I'm sure this already happens, and probably quite a bit, but it will get worse. WP:OUTING is written so strongly (too strongly IMO, but that's a separate discussion) that enforcement will be very difficult. --Trovatore (talk) 21:14, 18 November 2017 (UTC)
  • Support this or a similar version. Gandydancer (talk) 04:33, 24 November 2017 (UTC)


New basic wording:

No editor may use a position of trust or advanced user rights to:

  • solicit payment for services to be rendered on Wikipedia, or
  • accept payment for the use of such a position or rights
    • for the benefit a client
    • for advocating for a client, or
    • to evade our normal scrutiny system for new content and COI content.

Payments and grants made by the Wikimedia Foundation or its affiliates (e.g. chapters) are excepted. Wikipedians-in-Residence should declare their paid status and their paid use of advanced rights, but are otherwise exempt.

Smallbones(smalltalk) 16:30, 4 November 2017 (UTC)

This is an improvement, but I'm still a little uncomfortable with the word "solicit", which I think could potentially cover a wider range of scenarios than what is intended. Am I correct in assuming the intended effect of that clause is to stop people using OTRS and other WMF-sponsored tools for finding work? Lankiveil (speak to me) 02:30, 5 November 2017 (UTC).
Examples where "solicit" may come into play: Orangemoody-type advertising via email, i.e. Pay me to write your article and I'll make sure it sticks because I'm an admin, b) ads on Fiverr "You can pay me to write your article, and I'm an admin". One place that it wouldn't come into play is with Wikipedians-in-Residence because they "are otherwise exempt." I have no problem with a potential WiR saying to a respectable GLAM "BTW I also volunteer at OTRS" because GLAMs are aligned with our aims, and because I think GLAM folks (on- and off-Wiki) would police the activity themselves. I trust librarians!. Smallbones(smalltalk) 04:20, 5 November 2017 (UTC)
Can the scope of "position of trust" be narrowed? What roles that do not require advanced user rights are being targeted? For example, is a co-ordinator of WikiProject Military history, an elected position, considered a position of trust for the purpose of this proposed guidance? How about the Today's featured article co-ordinators? Teahouse hosts? isaacl (talk) 18:26, 5 November 2017 (UTC)
Sorry for my absence here, real-world obligations catch up sometimes. The answer to @Isaacl:'s question is most that there are many places where the rules for different positions and user rights are set out. I believe that each place needs input from the folks that hang out there and that the exact wording for each position can be worked out, In short, it'll be narrowed by doing one position at a time, and by the people involved. That's not to say that folks here can't be involved at those pages as well. So far:
  • small change already made at WP:AFC, with no opposition
  • small change at WP:COI reflecting the AfC change
  • an interesting discussion at WT:Good articles
  • I'll start a discussion very soon at WT:GRP (which covers OTRS and other rights)
Smallbones(smalltalk) 16:47, 8 November 2017 (UTC)
Can you list some examples of roles that would be covered which do not have associated advanced user rights? This would help me consider what type of wording may be appropriate. Personally, I do not think just being trusted by the community should be in itself a disqualifying factor, even though trusted editors inherently have a greater influence on discussions than those who aren't trusted. isaacl (talk) 17:00, 8 November 2017 (UTC)
My main concern is with holders of advanced rights who use their status, rather than the rights per se for paid editing, e.g. OTRS "volunteers" who might come on to enWiki (their rights, if we call them that are used elsewhere) and post something on a talk page, e.g. "From an OTRS ticket, I'm removing .... until a better source can be found." Or say an admin !voting at ANI. That's not exactly using their tools - it's a use of their position or status.
As far as "trusted positions" without tools - the only ones that concern me at all are AfC reviewer (this seems to have been taken care of) and Good Article reviewer (which is still being discussed). Others may be concerned about different positions - but let them make the proposals. As far as the elected director of WP:Military history - I just don't know enough about it - but I doubt that he'd win an election if he declared that he was willing to sell his services as the director. Smallbones(smalltalk) 17:49, 8 November 2017 (UTC)
FA coordinator and the ArbCom election commission have been mentioned above. GMGtalk 17:56, 8 November 2017 (UTC)
Perhaps it would be better to cast the restriction (for editors without advanced user rights) in terms of the type of services offered: the commonality seems to be decisions that are entrusted to one or a small number of persons, or the evaluation of the community's consensus view. So maybe something like this:
  • No editor with advanced user rights may solicit or accept payment for any service related to Wikipedia. Examples of services include advocating for a client, or evading scrutiny for any edits benefiting a client.
  • No editor may solicit or accept payment for any service related to evaluating the Wikipedia community's consensus view, or to deciding on an outcome either as an individual or within a committee, as opposed to part of a community discussion. Examples of outcomes include decisions made by the feature article co-ordinators, and rulings made by the Arbitration Committee election commission.
Further examples of course can be listed. isaacl (talk) 18:35, 8 November 2017 (UTC)
  • Prefer this version to the one in the above section, since it deals with the "coordinators" matter. I do think the admin, CU, etc. policies need to be updated with explicit rules again using such special power/tools/authority on behalf of off-site interests. It really doesn't have anything to do with money changing hands but with PoV, COI, and NOT#ADVOCACY policy.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  00:24, 11 November 2017 (UTC); revised: 12:34, 29 November 2017 (UTC)
  • I've made the relevant additions to New Page Patrol: [2][3]. MER-C 09:33, 22 November 2017 (UTC)

(radical?) counterproposal

Instead of running away and pretending we can stop editing (hint - I've only seen reports and instances of paid editing increase since the change in the ToS from my OTRS work), why don't we almost create a "trusted editor" system - editors that are trusted by the community are added to a page, can be contacted by external editors, and if the subject is indeed notable, the page can be created by them for either a charge or a donation to the WMF? (something a bit like WP:JOB but better publicised) Paid editing is clearly not going to go away - as I see it, we can have a choice where both us (with better paid-for articles, so less NPP needed), and the subjects (article less likely to get deleted, less likely to be scammed). I'm aware this does present a potential COI flag over the foundation, but as it is independent editors carrying out the editing, I don't see this as an issue.

Note: I'm not involved in paid editing, I just regularly dealt with the fall out from it. The current approach clearly isn't working IMO - maybe a shift in our approach may well get better results. Mdann52 (talk) 22:50, 3 November 2017 (UTC)

Those hiring paid editors are often looking for promotional rather than neutral content. The problem is growing as we become more well known and respected and the businesses that do this work increase in number. The rise of sites like Elance and Fivver also contribute. Doc James (talk · contribs · email) 07:18, 4 November 2017 (UTC)
@Doc James: True - however, I think if we are going to keep our head into the sands that this issue can be solved with our current approach, promotional content is going to become more widely available. I think that trialing different approaches to see what impact they make would be at least vaguely worthwhile. Mdann52 (talk) 17:01, 5 November 2017 (UTC)
Our current approach appears to be 1) some pretending the problem does not exist or if it does it does not matter 2) a small group trying very hard to keep our rules against paid editing from being applied and try to do everything possible to prevent any new rules from being created to regulate the practice or enforce our TOU.
So it is not surprising we are here. We do need to try things, but I would like to suggest we try enforcing our current rules or ban paid promotional editing directly in article space completely. Doc James (talk · contribs · email) 04:41, 6 November 2017 (UTC)
  • @Godric on Leave: I can see the parallels there, but that seemed to be far more about money from the WMF rather than subjects. I'm under no illusion this proposal is not going to get any real levels of support - sometimes, I think it's best to throw radical proposals out there to get people thinking, as in my time on Wikipedia, towing the same line has only seen the problem get worse... Mdann52 (talk) 17:05, 5 November 2017 (UTC)
  • Hi all! My opinion is simply disallowing those types of paied contributions because especially OTRs members as will as admins should be of the most confident users and represent the idea of volunteering for wikipedia and if we allow them to be paied for their contributions then wikipedia will become like any paid website and will lost its main principle of free knowledge. Those paied users are more prone to bias than those who are freely volunteering and sacrificing there efforts and time!. Regards--مصعب (talk) 11:18, 4 November 2017 (UTC)
This isn't going to happen.
  • @مصعب: There are a few editors involved with Wikipedia who are paid for their work and tend to produce high-quality articles - I'm of the opinion that paid editors != bad editors as a general rule - hence why I'd rather it was members of the community being paid for writing articles outside their comfort areas, rather than unknown people writing paid promotional content. Mdann52 (talk) 17:01, 5 November 2017 (UTC)
  • Just no TonyBallioni (talk) 13:13, 4 November 2017 (UTC)
  • Hell no! - it would be reputational suicide. --Orange Mike | Talk 20:58, 4 November 2017 (UTC)
  • Heck no! - some people get carried away! Smallbones(smalltalk) 21:44, 4 November 2017 (UTC)
  • Absolutely no . This is even worse than the error that was made in the first place by allowing paid editing under the condition of disclosure. No form of paid editing is compatible with the volunteer philosophy of Wikipedia.Kudpung กุดผึ้ง (talk) 03:36, 6 November 2017 (UTC)
  • Hahaha Worth imagining just so that in my mind I can see the look on the WMF's face if we tried to turn the platform into a donation machine through community consensus... In all seriousness though: not gonna happen. — Insertcleverphrasehere (or here) 12:31, 6 November 2017 (UTC)
  • @Insertcleverphrasehere: Evidently, you've never been on Wikipedia around December while logged out for the annual fundraising drive... :P Mdann52 (talk) 22:12, 6 November 2017 (UTC)
  • Presses nuke button - Seriously though, it is a good idea but per above wishful thinking. - Knowledgekid87 (talk) 16:24, 6 November 2017 (UTC)
  • No. Such a web site would be possible, and might be no worse than the commercial world already is, but whoever wants to run it, can and must do so entirely independently from WP or the WMF, and I do not think anyone could ethically participate in both. The problem is that our copyright permits anyone to use our material, and then add commercialism onto it, but we always knew that's inherent in the license. Personally I sometimes think we should have chosen -NC, but we didn't. DGG ( talk ) 19:14, 20 November 2017 (UTC)

History - people with privileges who edited for pay

Several folks have asked if this has ever happened. I've been spending a bit of time looking at that...

apparent sock (listed at SPI): Homechap (talk · contribs · deleted contribs · logs · edit filter log · block user · block log)
apparent sock (listed in Arbcom decision June 2009): Zithan (talk · contribs · deleted contribs · logs · edit filter log · block user · block log)
crat, oversighter, admin, OTRS.
per edit count first edit in 2004.
status, Zithan blocked; other accounts not blocked, Nichalp retired; last edit on en-WP was Jan 2009 (left enigmatic note here 31 Jan 2009).
Made a 'crat here in September 2005 ; stripped by arbcom here June 2009.
joined OTRS here October 2007; removed from list here July 2009 with edit note No longer active(!)
June 2009 SPI filed and was put on hold for Arbcom, Arbcom finding is here
btw this from July 2008 looks a lot like trying to figure out how to cover their socking tracks after a goof, using the tools.
The arbcom decision spawned a long discussion at the related talk page here.
Led to a slew of AfDs eg linked from Wikipedia:Articles for deletion/Brad Sugars
Led to a mammoth RfC that ran June-July 2009 Wikipedia:Requests_for_comment/Paid_editing
Status. not blocked. Still an admin. not too active per edit count, last edit was Feb 2017
per edit count, created in 2006
diff, June 2009 acknowledged editing for pay; explained here on 11 June that they work for a university and I only add content or modify content with information that is sourced directly from our publications and web-sites, or from accompanying articles.. That diff says that they gave up the bit and they did but they asked for it back in Nov 2009 log)
sock of account formerly called Mrinal Pandey, renamed to Empengent (talk · contribs · deleted contribs · logs · edit filter log · block user · block log)
See SPI Wikipedia:Sockpuppet_investigations/Mrinal_Pandey/Archive (I had never looked at that before. Wow)
arbcom case Feb 2015; desysopped and banned for socking and editing for pay on behalf of a university, Indian Institute of Planning and Management
Master account (edit count) created Dec 2006
Wifione account (per edit count) created April 2009.
user rights log, made admin Sept 2010.
OTRS, autopatrol
status, indeffed Nov 2017)
OTRS (removed Oct 2017)

--(That is what I found so far. Jytdog (talk) 18:31, 18 November 2017 (UTC))

Currently editing for pay through "Mister Wiki"

— (added by JJMC89(T·C) 18:56, 19 November 2017 (UTC))

New Page Patroller
Systematically marked as patrolled new pages created by one of the big UPE sockfarms.

-- added by Rentier (talk) 19:27, 19 November 2017 (UTC))

AFC reviewer
Does work for "Mister Wiki".

- (added by Jytdog (talk) 22:54, 19 November 2017 (UTC))

Other history

Had never seen this list before. Back in 2009 already somebody was tracking ads for paid editing on Elance. See User:Brumski/paid_editing_adverts. Jytdog (talk) 18:31, 18 November 2017 (UTC)

Rather than putting this list on the village pump page, how about including it somewhere under Wikipedia:WikiProject Integrity, such as a subpage of Wikipedia:WikiProject Integrity/Editor Registry, so it can more easily located again in future and kept up-to-date? isaacl (talk) 20:07, 19 November 2017 (UTC)

As I noted at the top, people in the RfC discussion asked about other people with advanced privileges (PWAPs ??) who edited for pay and I wanted to make it easy for folks participating to see. But yes it should be copied to the Integrity page. Jytdog (talk) 21:17, 19 November 2017 (UTC)
You guys should probably take care to separate your own sigs from the list of editors in the section above. ☆ Bri (talk) 00:31, 21 November 2017 (UTC)
thx, added notations and smallified. :) Jytdog (talk) 02:40, 28 November 2017 (UTC)

Current developments

In view of the current case (which is going to be accepted) at Wikipedia:Arbitration/Requests/Case#Mister_Wiki concerning an admin, the entire proposal should be reworded as:

The holding of advanced rights is incompatible with paid editing

Even if a user with advanced rights creates creates another identity for his/her paid editing (such as user:Salvidrim!), it just creates yet another perceived degree of tolerance for paid editing - and its still the same person. No one can claim to successfully manage a voluntary split personality. Kudpung กุดผึ้ง (talk) 01:01, 26 November 2017 (UTC)

  • I didn't realize this discussion was happening here, I had been commenting on the case request. I'll just basically expand on what I said there: I think that it would be a very good idea if we made users choose between holding advanced permissions or being paid to edit. To my mind it's pretty simple: if you want to accept payment for doing something on Wikipedia, you first go to WP:BN and say "I've been hired to do a thing, please remove all of my userrights" (yes, rollback and everything, right down to autoconfirmed). Maybe we should require that you describe the work you're being paid to do, or post a link to the request on Fiverr or wherever, that seems like a good idea for transparency. Then you go do your paid gig, making proper disclosures along the way, and once you're done you go back to BN and say "my paid gig is done, please give me back my userrights". Then, obviously, you don't touch that topic again. It's all done from one account so you're accountable for it, and nobody is prevented from doing paid editing if that's a thing they want to do. And if you're being paid to "manage" content on an ongoing basis, you shouldn't be entitled to any advanced permissions.
As for Pigsonthewing's concern about Wikipedians in Residence, I think it stands to reason that being paid to promote Wikipedia and facilitate outreach events is somewhat different from being paid to edit Wikipedia on behalf of a third party. The WiR program is already pretty transparent, and clearly valuable. Ivanvector (Talk/Edits) 15:43, 29 November 2017 (UTC)
  • I think this would be a very bad idea. There are far too many grey areas and corner cases and times where this would harm the encyclopaedia (making it much harder for someone to revert vandalism they happen across) - not to mention that it would encourage people with rights greater than autoconfirmed to lie about any paid editing making the problem worse rather than better. We will either lose many good editors and admins because of technical violations or the rules will be inconsistently enforced making much more of a mess than we currently have. Thryduulf (talk) 17:15, 11 December 2017 (UTC)

Consensus and copyright law

(non-admin closure) No consensus for any action. There is general agreement that copyright violations are not permitted even if a consensus says otherwise, but there is no consensus (bordering on outright opposition) to any of the proposed policy changes. power~enwiki (π, ν) 01:08, 9 December 2017 (UTC)
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.

This removal by Sandstein apparently need to be discussed. Admins that are closing FFD discussions need to have a grasp on the relevant copyright law(s) in order to make a sound decision. This is one of the few areas were community consensus can actually have a detrimental effect on the project as a whole as consensus, or lack thereof, could result in a violating image being kept on the project when it really shouldn't be.

The question is as follows: Should admins be able to use their knowledge of copyright law to ensure that images uploaded to the English Wikipedia follow said law. Regardless of the actual consensus of a FFD discussion? --Majora (talk) 20:42, 4 November 2017 (UTC)


  • Support allowing admins to use their discretion to ensure files follow the law. --Majora (talk) 20:42, 4 November 2017 (UTC)
  • Support but I assumed this was already covered by WP:F9. A copyright violation cannot be allowed on Wikipedia. TonyBallioni (talk) 00:25, 5 November 2017 (UTC)
  • Adam9007, yes. I think it should be, though I agree that G12 covers this as well. Administrators already have a basis in policy to delete copyright violations regardless of the outcome of discussion. I firmly support the four-eyes principle on speedy deletion even for copyright, but once an editor has pointed out a copyright violation, the CSD allows for an admin to delete the page. Wikipedia almost always sides with taking the most conservative option when it comes to copyright, and that means deletion when there is a reasonable basis to assume that the content is copyrighted and without proof of the content in question being free. Majora, could you explain a bit more why you don't think this is already under the CSD policy? TonyBallioni (talk) 01:46, 6 November 2017 (UTC)
  • (edit conflict) Because having things written down in black and white make it far less likely for someone to find a way around it. I tried to explain the fact that the image that caused all of this was copyrighted but Sandstein claimed that deleting it would constitute a supervote. When I tried to explain to them that it would not be a supervote because of the admin instructions they removed those instructions. If it can happen once it can happen again. So having it in black and white can only avoid such instances in the future. --Majora (talk) 01:54, 6 November 2017 (UTC)
  • Thanks. I'd also suggest opening up a conversation at WT:CSD about the point Adam raised above. Copyright is one area where the CSD policy always trumps XfDs, and getting it is writing there will also be helpful. TonyBallioni (talk) 02:00, 6 November 2017 (UTC)
  • @TonyBallioni: I'd also suggest opening up a conversation at WT:CSD about the point Adam raised above I was going to suggest the same thing. Adam9007 (talk) 02:03, 6 November 2017 (UTC)
  • Support this has always been the case, copyright policing has always trumped consensus because of the legal implications to both us (the Wikimedia Foundation sites) and to our downstream content re-users. We cannot permit copyright violations to remain visible here just because consensus in one deletion discussion is in favour of keeping a file. I would also remind users that we're here to create a 'free encyclopedia' - that is to say, one that is as unencumbered by copyright limitations and restrictions as far as is possible'. We are not here to create an 'online illustrated encyclopedia', one which includes as many images as possible from anywhere and everywhere'. I'm shocked but far from surprised we're having this discussion, and disappointed my colleagues are closing copyright discussions when they do not understand about copyright, nor do they seem to care that they don't understand copyright. Nick (talk) 13:01, 5 November 2017 (UTC)
  • Support the RfC question, sort of, but considering it to be separate from the specific text added/removed that led to this RfC. It may help to reframe it, though. Yes, it's about making a determination about a legal matter using knowledge of copyright, but it's more likely to get support if we just say that the closing admin must base the close on the strength of arguments -- and that we afford admins more leeway in FfD closes to go against the majority or even "supervote" when the majority get it wrong. Notability is more open to interpretation and the consequence of getting it wrong by siding with the majority is far less than it is in matters of IP. — Rhododendrites talk \\ 17:34, 5 November 2017 (UTC)
  • When a closer has not concluded there is copyright infringement, as in this case, the paragraph-at-issue is irrelevant. You can't use it to badger an unconvinced-admin into deleting. If you're convinced a non-consensus should be delete, then either re-nominate or take it to DRV. (It was unnecessary for the admin to delete the paragraph to reject the unpersuasive demand.) On the other hand when a closer is convinced that sufficient evidence of infringement has been established then SUPPORT. There is abundant basis to go against a majority based on strength of argument and the various valid reasons for discounting poor arguments.[4] This is especially true in the case of copyright: Wikipedia policy, which requires that articles and information be verifiable, avoid being original research, not violate copyright, and be written from a neutral point of view is not negotiable, and cannot be superseded by any other guidelines or by editors' consensus.[5] Copyright violation is probably the strongest justification for discounting a faulty majority. If you object to the deletion then take it to DRV. Alsee (talk) 17:22, 6 November 2017 (UTC)
  • Support Consensus cannot overwrite copyright law, so images clearly uploaded that violate copyright can be removed by a knowledgable admin even if consensus thinks it should be kept. That said, we need to differentiate these from problems with NFC rationales, which start with the assume that there's a fair-use claim and all core copyright issues are not a problem. Those need to be taken in consideration with strength of FFD arguments to keep or delete. --MASEM (t) 23:12, 6 November 2017 (UTC)
  • Support copyright is one of a very small number of areas where, because of the potential for serious harm to result, we need to err on the side of caution. As a result if an FFD discussion comes to a conclusion about copyright which the closing admin knows is incorrect then they should be able to place greater weight on the global policy and less on the local consensus. No, we don't select admins for detailed copyright knowledge, but we do expect that admins who don't have the knowledge required to work in some area stay away from it. Hut 8.5 18:11, 7 November 2017 (UTC)
  • Support: I agree with pretty much what everyone has posted above. I also think discussions involving copyrighted content (files or text) need to err on the side of caution. While I can understand how a "no consensus = keep" might be acceptable for AfD discussions, I don't believe such an approach works very well with discussions about files. I've seen some FFD discussions (involving both non-free content and free content) closed as such over the past few months and the logic for doing so seems questionable at best to me. It's seems to me that the licensing of a file should be clearly verifiable; otherwise Wikipedia should not accept it. In cases where a file's licensing is challenged, the burden should be for those arguing for the file to kept to clearly show that the licensing complies with WP:COPY; if they are unable to do so to the satisfaction of the community, Wikipedia should delete the file along the lines of c:COM:PCP. I don't think this proposal is asking for closing admins to offer legal opinions or cast supervotes; I just think it more clearly spells out that file copyright discussions can sometimes be complex and the automatic default in cases where there still exists some significant doubt should not be to keep. -- Marchjuly (talk) 00:56, 8 November 2017 (UTC)
  • Support. Copyright law should trump consensus, and admin discretion to delete to follow copyright law in spite of consensus is perfectly fine. I would also support shifting the default outcome for a no-consensus FFD to be delete to err on the side of caution. ---- Patar knight - chat/contributions 04:10, 8 November 2017 (UTC)
  • Support per above. I'm also concerned that so few editors understand/respect copyright that we actually have to discuss this. For example, if someone uploads a copy of File:TheAvengers2012Poster.jpg under {{PD-self}} and consensus says keep as is, then rest assured I'll be there to delete it. -FASTILY 20:26, 10 November 2017 (UTC)
  • Support Copyright law closures should only adhere to what actual law says, and not care about consensus. The discussion should bring in examples why or why not it is a violation of the law, but the closure should have sufficient copyright law knowledge to close such a discussion. Being an admin is not an end-all reason to be able to close all kinds of discussions, sometimes knowledge in an area, such as copyright is required. / Commons admin (tJosve05a (c) 13:33, 11 November 2017 (UTC)
  • Support. Law (and indeed WMF fair use policy) supersedes a local consensus. Stifle (talk) 10:31, 14 November 2017 (UTC)
  • Only partial support Of course consensus cannot overule copyright law, but the effective copyright law depends upon many layers of interpretation, both the interpretation done in the legal system(s), the interpretations(s)we do here, and there necessary adjustments we have made to accommodate in some manner incompatible legal systems. It's very easy in a discussion to say "copyright law " but the actual meaning is very often "my interpretation of copyright law " or actually "my interpretation of our practices on how we interpret what we think to be copyright law" DGG ( talk ) 02:30, 20 November 2017 (UTC)
  • Support, if a file violates NFC or copyright law, it must be removed regardless of consensus. Those policies are not subject to override by consensus. Admins are entirely capable of having good enough understanding of both NFCC and copyright law to understand when that needs to happen. (That also means it will happen regardless of consensus or lack thereof here, those policies are not subject to consensus at all.) Seraphimblade Talk to me 05:22, 27 November 2017 (UTC)
  • Support. If an admin is confident that there are legal considerations that require file deletion, then the admin should delete the file (generally with a clear explanation) even if the FFD consensus was otherwise. We cannot and should not tell admins to do something that they believe is contrary to law simply because some editors want to do it. But that is not the same thing as saying that admins must make a determination of law, or that any deletion decision cannot be subject to review. --Tryptofish (talk) 00:41, 28 November 2017 (UTC)


  • Oppose As remover of the text, I obviously disagree with it. We do not select our admins for a knowledge of or training in copyright law, and therefore a random admin's understanding of the law (which varies substantially depending on jurisdiction) is only marginally likely to be better than that of other editors. Ultimately, consensus determines which files are kept or deleted and therefore what Wikipedia's collective understanding of copyright law is. Obviously, admins should take strength of argument into account in closing, and therefore give less weight to opinions based on a clearly mistaken view of the law (e.g., "information wants to be free, you can't copyright art!"). But that's not the same as saying that an admin's personal interpretation of the law should override everybody else's views.  Sandstein  20:52, 4 November 2017 (UTC)
    If your knowledge of copyright law is only marginally better than the general editor's perhaps you shouldn't be closing FFD discussions that are partly or entirely based on copyright law? Perhaps leave those to admins that know what they are doing? --Majora (talk) 20:54, 4 November 2017 (UTC)
    I'm talking about administrators generally, because what you propose is a rule that is supposed to apply to all closing administrators, including those who may know nothing at all about copyright law. If you disagree with a closure that did not end in deletion, just renominate the file or go to WP:DRV.  Sandstein  21:02, 4 November 2017 (UTC)
    It isn't about this one file. It is about the actions of an admin who admits to closing a discussion when they didn't know all the facts based on a lack of consensus that violates copyright law. I tried to get you to understand but you refused. I would certainly hope that most admins would have the knowledge of their own personal abilities to know what areas of the project they are best suited for. Those that know nothing about copyright law should not be setting foot into FFD to close discussions based on copyright law. Just as those that know nothing about username violations shouldn't be stepping foot in UAA without at the very least learning about it first. We hold our admins to such high standards for a reason. We trust they won't go bouncing around the project willy nilly without knowing what they are doing first. --Majora (talk) 21:09, 4 November 2017 (UTC)
  • Oppose Suppose there was a discussion where everyone !voted delete based on copyright violation but the closer, based on his superior knowledge of the law that copyright was not being infringed, closed as keep. Would that do? Of course not. The role of the closer is to assess consensus, not to assert any supposed superior knowledge. Thincat (talk) 21:27, 4 November 2017 (UTC)
    I'm trying not to bludgeon the process by responding to every person but that seems much more unlikely to ever occur. First of all, obvious copyright violations are speedy deleted and never get to FFD to begin with. Second, I would assume this hypothetical admin would actually attempt to provide proof to the other respondents? I certainly hope so. If they are closing FFD discussions they are ultimately responsible for proving that the image follows copyright. We trust random people with OTRS access to access copyright based on their "superior knowledge". We should trust admins closing FFD discussions to do so as well. And to provide proof of their actions. --Majora (talk) 21:37, 4 November 2017 (UTC)
    Thincat, Wikipedia:Closing discussions#Policy says it ain't quite that simple. ―Mandruss  21:39, 4 November 2017 (UTC)
    But Majora has raised breach of the law which is narrower than breach of policy. Copyright infringement, generally being a tort, requires damage to be actually caused to the injured party for tort to be proved. And that seems very unlikely to be realistic in this case. (That shows how little I know about the law!) Of course consensus should be policy-based. Take the matter to WP:DRV. Thincat (talk) 21:59, 4 November 2017 (UTC)
    The preservation of the project's safe harbor status under the DMCA requires us to deal with copyright violations immediately, as soon as they are noticed. Actual damage to the party in question is beyond the scope of that carve out in the law. Commons puts this pretty succinctly in their precautionary principle. "We can get away with it" isn't a valid reason primarily because of safe harbor. So an admin using consensus, or lack thereof, to keep a violating image is a serious concern. Hence this RfC, to reestablish that point in the FFD admin instructions. --Majora (talk) 22:08, 4 November 2017 (UTC)
    Thincat, I definitely understand looking at the mirror-situation. However I see a strong asymmetry here. If a closer is convinced that sufficient evidence has been presented to establish copyright infringement, that supersedes a majority-consensus to the contrary. In the opposite case a closer believes it is not copyright infringement, they consider it a poor deletion. However that is not strong cause to disregard a (presumably) reasonable consensus of responsible editors. They should either accept that consensus, or better yet they should simply !vote KEEP and explain why. A good closer needs to be able to do two very important things: (1) Close against a majority when there is solid cause to do so. (2) Close against their own view. This mirror-case neatly packages up those two critical criteria for a closer. Alsee (talk) 17:52, 6 November 2017 (UTC)
    Thank you for your remarks, which are helpful. Because, in my view, the hosting of File:Bob Hasegawa Official Portrait.jpg does not infringe US copyright, I think the arguments that there is a legal tort (or even a crime!) are mistaken. Perhaps when some people are claiming there is a copyright violation what they really mean is that WMF or WP policy is being broken. That position is far more firmly based – WMF do not allow "no harm" as justification even though it is allowed in law and no fair use rationale has been provided (none is required by law). So, to me some of the claims here of impropriety and impending legal calamity seem extravagant. However, I agree that closers should not close against policy (except when you ignore it!) and maybe that happened here. Thincat (talk) 23:03, 6 November 2017 (UTC)
What... exactly leads you do believe that this is in the public domain? GMGtalk 23:13, 6 November 2017 (UTC)
I'm not supposing that for one moment (and I don't know if there is a "free" licence). I am suggesting that no copyright violation (in law) has occurred. Thincat (talk) 23:20, 6 November 2017 (UTC)
  • Oppose Per WP:NOLEGAL, "Nothing on or of any project of Wikimedia Foundation, Inc., should be construed as an attempt to offer or render a legal opinion or otherwise engage in the practice of law." Andrew D. (talk) 12:16, 5 November 2017 (UTC)
  • Oppose - A few points here... First, discussions on copyright are ultimately simply not purely consensus based. They may seem that way, but they're really not for one very important reason: if you have 100 inane !votes to keep, and one !vote to delete that is based on a solid sourced rationale for why the content violates copyright, the admin probably shouldn't close the discussion at all, and should instead take that one well reasoned delete !vote to legal, for actual lawyers to weigh in on the actual law. They should post whatever response they get on the deletion discussion for public review, and at the end of the day that actual legal opinion is much more important than all the inane !votes in the world.
Second, we do not empower any Wikipedia editors to make legal decisions. There are very good reasons why our donations help keep legal counsel at arm's reach.
Third, this probably didn't even need to escalate to that level, and the discussion was fairly evidently one weakly reasoned !vote with nothing to back it up, and one vote that was pretty clearly the exact opposite. Inane !votes don't count toward consensus because they're "inane !votes" and not "inane votes".
Finally, if I haven't made it abundantly clear, This was probably a bad close. But they're bound to happen occasionally, and we have a process in place to deal with that. I don't see a reason that this should be outside of the ability of that process to handle. GMGtalk 12:55, 5 November 2017 (UTC)
Striking all but the final portion after some convincing arguments on IRC. I appear to be generalizing from a particular case in a way that isn't correct. I still oppose the overall proposal. I don't think every bad close requires a change in policy. I don't see any evidence to suggest that this is a persistent and pervasive problem that DRV or renominating isn't able to handle. GMGtalk 13:27, 5 November 2017 (UTC)
  • Oppose. Not only do I strongly second Sandstein's point about copyright-law knowledge not being a criterion for getting the mop, I would from personal experience not trust any close made on that basis by an admin, even if I agreed with it, because there is a lot of misunderstanding out there about how copyright law works, even where only U.S. copyright law is at issue, and our admin corps is certainly not immune. I saw one admin once argue for the removal of a book cover from an article, a book cover that was itself ineligible for copyright in the U.S. as it consisted only of the work's name and some geometric shapes, on the grounds the book cover was covered by the copyright on the book itself. But even in countries where the cover art might have been eligible for copyright, its copyright is still an entirely separate one from the book's text.

    We also have the issue of too many people thinking copyright law and our copyright policy are identical—in fact, the latter is more restrictive than the former, by design, due to values the community has decided it wishes to express through that policy.

    Only one actor within the Wikimedia community has the clear authority to rule on an FFD closure on copyright-law grounds: the Foundation counsel's office. They get paid to know these things, and make such decisions on that basis (which they rarely do; they prefer to leave most of those decisions to the community, and when they do have to get involved in deleting images it will be for reasons that supersede those the community can consider such as a DMCA takedown notice, in which case they will not bother to involve themselves in an FFD since it is moot under those circumstances).

    If an editor feels that a closing admin has applied our image and copyright policies in a manner inconsistent with the relevant copyright laws, there is, as has been noted, a process available to them: deletion review. Daniel Case (talk) 00:24, 6 November 2017 (UTC)

  • Oppose. I'd also like to add that Wikipedia's administrators should also refrain from giving mandatory medical advice, or anything else that would expose the community to liability. NFC is handled by community discussion, subject to the oversight of WP:OA (as I understand it), not by administrators' knowledge of copyright law, or lack thereof. Sławomir Biały (talk) 00:45, 6 November 2017 (UTC)
    • The exact opposite is actually true: an administrator closing an FfD and keeping a file they know could reasonably be under copyright would be the one assuming liability as would be the admin restoring a copyrighted file. An admin deleting a copyrighted file would have next to no liability legally: no one has a legal right to store any image on Wikipedia, even if they are the legitimate copyright holder, so deletion of a file exposes the deleting admin to no legal jeopardy. Being the admin who decides to keep a copyrighted file because of consensus, however, arguably does because individual contributors are legally responsible for their actions, and the liability comes to the contributor, not to the WMF. We would never dream of allowing anything like this for text copyright, I don't see why so many users think we should allow it for files. TonyBallioni (talk) 07:40, 6 November 2017 (UTC)
      • No. There has to be a take-down request by someone with standing. Alanscottwalker (talk) 12:31, 6 November 2017 (UTC)
        • And depending on the circumstances the individual admin could still be liable for not acting. Additionally, it is undisputable that deleting a copyrighted file does not expose an admin to legal jeopardy if it was done incorrectly: no one has a right to host any file here. TonyBallioni (talk) 14:34, 6 November 2017 (UTC)
            • No, but requiring administrators to learn copyright law and police the site might open the foundation or individual administrators to liability. (Notice I said "community", not specifically "foundation" in my vote.) What if it were found that some administrators were negligent in their (apparently new) responsibility? Sławomir Biały (talk) 18:30, 8 November 2017 (UTC)
              • Individual adminsitrators are already liable for every action and edit they take on Wikipedia, whether it is in regards to copyright or not. The same is true of every editor: there is no community liability for anything, all users are legally responsible for their own actions. Deleting content poses zero legal jeopardy to administrators: no one has any right to use WMF servers as a webhost. Taking an administrative action that chooses to actively retain content where the copyright status is legally questionable has significantly more legal risk, though as anyone who is discussing copyright and Wikipedia should point out: its a very complex situation and it would need to be sorted out in the courts. TonyBallioni (talk) 20:32, 8 November 2017 (UTC)
                • You still misunderstand. An administrator is not liable for copyright infringement if he or she simply summarizes community consensus (as keep, say). Currently, closing a discussion one way or another does not carry with it any implicit assumption that the administrator will have evaluated the copyright status him or herself. Administrators are expected only to assess the consensus of discussions based on the strengths, not, in their administrative capacities, to verify the copyright status personally. However, if we require administrators to assess the copyright status of content, then they could conceivably become liable for an incorrect assessment of that status: closing a discussion as "keep" would amount to an administrator personally testifying that he or she has verified that the image is compatible with all relevant copyright laws. We don't want to open administrators up to this additional liability by implying that this is in any way their responsibility. But in any case, I'm not a copyright lawyer. Are you? Sławomir Biały (talk) 20:29, 20 November 2017 (UTC)
          • No. Not doing something is not an act of infringement, not deleting is not an act of infringement, saying "consensus is to keep" is not an act of infringement -- it's just an opinion about consensus that is protected free speech. Alanscottwalker (talk) 14:38, 6 November 2017 (UTC)
            • Knowing that something is a copyright infringement and deciding to use a position of community trust to keep it rather than delete it when one has the option arguably makes one a party to the infringement. This has nothing to do with free speech. TonyBallioni (talk) 15:06, 6 November 2017 (UTC)
              • No. It does not, and if one does not know what free speech is, how can one presume to claim to know copyright infringement. Alanscottwalker (talk) 16:40, 6 November 2017 (UTC)
                • As a point of order, this has nothing to do with free speech. Carry on. GMGtalk 16:51, 6 November 2017 (UTC)
                  • That is not a point of order, that is just not paying attention. It remains, whether you like it or not, 'saying "consensus is to keep" is not an act of infringement -- it's just an opinion about consensus that is protected free speech.' Alanscottwalker (talk) 18:44, 6 November 2017 (UTC)
                    • People often think that the First Amendment prevents anyone or anything from punishing them for their speech. This is not the case. The First Amendment prohibits the government — not private actors — from punishing you for your speech. A private company can censor artistic expression or a private employer often can discipline its employees for speech without violating the First Amendment.[6] GMGtalk 18:49, 6 November 2017 (UTC)
                      • That's not of any meaning, here. It certainly does not change the case that, 'saying "consensus is to keep" is not an act of infringement -- it's just an opinion about consensus that is protected free speech.' (It's those who are trying to imbue it with legal meaning -- in copyright-law -- that are not only wrong, but dangerously so).Alanscottwalker (talk) 19:05, 6 November 2017 (UTC)
                        • The government is not trying to interfere with editors closing XfD discussions. It therefore has nothing to do with free speech, because... that's what freedom of speech means. Freedom of speech has to do with the government. It does not have to do with the not-government. I'm not... totally sure how much more clearly that can be put. GMGtalk 19:56, 6 November 2017 (UTC)
                          • You can pay attention to what is actually being described, an opinion, which falls in the realm of free speech is not copyright infringement. Alanscottwalker (talk) 21:17, 6 November 2017 (UTC)
                            • I... umm... Sure thing. GMGtalk 21:19, 6 November 2017 (UTC)
      • No. The administrator would most definitely not be liable. Then again, hey, what do I know about copyright law? For that matter, what do administrators know? Take it up with the WMF legal team. Sławomir Biały (talk) 18:26, 8 November 2017 (UTC)
  • Oppose. In a no consensus situation it may make sense to allow it, but not in a case of a clear consensus. עוד מישהו Od Mishehu 07:30, 6 November 2017 (UTC)
  • Oppose On the internet nobody knows you're a dog. Only in death does duty end (talk) 12:19, 6 November 2017 (UTC)
    • Which is a great argument to ignore the consensus at FfDs when the possibility of copyvio exists. TonyBallioni (talk) 14:34, 6 November 2017 (UTC)
  • Oppose absolutely nothing we do or adopt should even begin to suggest an admin is rendering their own legal opinion in taking an admin action. -- Alanscottwalker (talk) 18:59, 6 November 2017 (UTC)
  • Oppose, with obvious usual provisos. This is either unneeded WP:CREEP or an invitation for supervotes. Admins should close based on the consensus of the discussion, which already can potentially include weighting certain !votes lightly if they display an obvious failure to engage with the relevant policies. If an admin feels that a discussion has a consensus which is profoundly against their own personal view of copyright, they are free to not close the discussion and instead cast a normal vote, and perhaps the eventual closing admin will be influenced if the original admin's argument really is persuasive. And finally, if the community truly bollocks up a discussion, there is as always WP:OFFICE action to correct it if the actual copyright holder complains and the Foundation's lawyers think the complaint has merit. SnowFire (talk) 06:36, 9 November 2017 (UTC)
  • Oppose on the grounds that if we follow it through to it's logical conclusion, it would likely have the opposite intended effect since users would quickly determine which admins are partial to their own copyright/fair-use/nonfree views, thereby actually giving users greater opportunity to exploit the protections already put in place. Also I oppose, to a lesser extent, (since this view has already been expressed), because copyright law, like any other law, is widely open to interpretation, and single individuals should rightfully be excluded. Even the U.S. justice system espouses a (kind of) consensus interpretation with the 12-member jury. No cop, lawyer, or judge gets to decide if you broke the law. The jury does. Most people think copyright/killing is against the law. Maybe. Maybe, not. What if you killed in self defense? What about justfiable homicide? Accidental manslaughter? Premeditated murder? Who get's to decide? A jury of your peers, that's who. Huggums537 (talk) 14:47, 9 November 2017 (UTC)
  • Oppose copyright law, like all law,needs to be interpreted. Obvious violations are removed by speedy, but anything that reached FFD is somethign where the interpretation is not obvious. The only way for deciding interpretation is consensus. DGG ( talk ) 17:48, 10 November 2017 (UTC)
  • Oppose per Alanscottwalker and Andrew Davidson. --Tom (LT) (talk) 22:40, 10 November 2017 (UTC)
  • Oppose. If it's not a blatant situation, you (and I) must obey consensus achieved at FFD. We can already disregard nonsensical arguments at any XFD nomination, after all; when Randy shows up and says that an image is PD-animal because it was created by sword-wielding skeletons, we can just ignore his opinion when determining consensus the first time around or when evaluating a DRV. Nyttend (talk) 05:00, 13 November 2017 (UTC)
  • Oppose. Let admins be admins and lawyers be lawyers. Conflating the two undermines both. WaggersTALK 13:17, 23 November 2017 (UTC)

*Oppose, consensus doesn't much matter in that case. If the content is a copyvio or in violation of NFC (as an extension of the WMF exception doctrine policy), it must be removed even if consensus is in favor of it. Consensus is totally irrelevant at that point. Seraphimblade Talk to me 04:16, 27 November 2017 (UTC) Oops, seems I misread! Seraphimblade Talk to me 05:22, 27 November 2017 (UTC)

Umm... Seraphimblade The OP's question asks whether you favor admins using knowledge of copyright to decide on a file, despite the actual consensus. Your rationale looks as if you favor an admin using such knowledge. Shouldn't the vote be moved to "support"? George Ho (talk) 04:45, 27 November 2017 (UTC)
  • Oppose - This appears to me to be the sanctioning of a few rogue ultra-deletionists (who tend to populate files policing to begin with) to do whatever the hell they want based on their own sometimes skewed and wrong personal interpretations of copyright law. Take such extremism to Commons if you want and stew on your juices there. Don't mess with what is working at en-WP, which has been successfully sued over file copyvio zero times and counting. Carrite (talk) 14:41, 28 November 2017 (UTC)
  • Oppose. It's been my lengthy professional experience (working for a non-profit law firm for a decade as a policy analyst (IANAL) that people who think they understand copyright law almost always do not, and even those who really do know a lot can still frequently be wrong if they're not intellectual-property specialist attorneys who've been keeping up with caselaw and legislation closely (especially with regard to digital media). [And WMF is notoriously, excessively paranoid about copyright anyway; what we're allowed by WMF to do under fair use is only a fraction of what we actually legally allowed to do under that doctrine. While WMF does have exposure to legal liability for images that it should not be using at all (e.g. because someone uploaded something under false licensing), it has virtually none when it comes to reuse of promotional images (movie posters, publicity shots, etc.).]

    It's an admin's "job" to interpret and apply policy, not the law (and the law on this is much more about caselaw than about statutes at this point). When a legal question arises, the entire community in a consensus discussion is more apt to identify correctly whether there's a potential copyright problem that a lone-wolf admin who is not an attorney, or an attorney who's not an int-prop specialist. If WMF itself is concerned about this stuff, it can appoint staff counsel to review keep decisions at FfD and selectively override them by WP:OFFICE action. Or it can create a special class of admin with verified legal credentials in the relevant jurisdiction. Or come up with some other plan. But the notion that "I was trusted to become an admin because I seem sane and to be not a jackass" magically transmogrifies into "I know better than the community about copyright law just because I said so" is not viable. We have a lots of editors who are actual intellectual property attorneys, and they greatly outnumber the admins who are, and are likely a converge on FfD as an area of interest. If we have a consensus formation and assessment problem at FfD where people who really have no idea WTF they're talking about are !vote to keep images on a WP:ILIKEIT basis, a) this should be easy to detect, and b) we can provide specific "arguments to avoid in FfD discussions" at the FfD page, e.g. about arguing to keep a file, when copyright is at issue, without presenting an actually legally defensible rationale. "Admin knows best" is not the solution to this problem, if it is even a real one.
     — SMcCandlish ¢ >ʌⱷ҅ʌ<  13:22, 29 November 2017 (UTC)


  • If the laws of a country make any admin feel at personal risk of civil, criminal, or terrorist/paramilitary-mediated liability for upholding Wikipedia consensus, he should recuse himself and leave it to some member of the consensus (there must be many, after all) to decide what to do. Our policy should actually be to require he recuse himself in that position. (Note he would not be required to recuse himself if he honestly feels he is upholding consensus by following the law, which is far more common) Wnt (talk) 13:32, 5 November 2017 (UTC)
  • This RfC is moot - copyright is one of those policies with legal considerations which isn't subject to consensus. Copyright-violating material is required to be removed immediately; any community consensus which conflicts with that is irrelevant. Ivanvector (Talk/Edits) 11:50, 19 November 2017 (UTC)
  • The hard part is determining WHETHER the material violates copyright. Blueboar (talk) 16:17, 19 November 2017 (UTC)
  • ’’’Moot’’’ per Ivanvector. As a policy with legal considerations, our policy on copyright is not subject to consensus. ~ Rob13Talk 21:37, 6 December 2017 (UTC)


  • There has been an incident that facilitated the need for this discussion beyond Sandstein's removal of that part of the admin instructions for FFD. The no consensus close of an image that is clearly in violation of copyright. --Majora (talk) 20:42, 4 November 2017 (UTC)
    In the context of this specific example, I think the framing is somewhat wrong. An uploader (and those who support keeping files) have an affirmative burden of proof when it comes to establishing that the file meets our copyright restrictions. In such a discussion, I would suggest that a lack of consensus about whether copyright obligations have been met should generally be treated as delete result by default. In the absence of consensus, the need for a precautionary principle when it comes to copyright ought to favor deletion. Dragons flight (talk) 12:40, 5 November 2017 (UTC)
  • Generally, when I see a discussion which seems to go counter to what would be disallowed (or permissive) under copyright law, I comment or skip. This is essentially a collision between copyright and Wikipedia:Consensus; Commons as a file repository is a lot more exposed to copyright issues so they give more weight to the first point. I think it's also the reason why Commons has no equivalent to WP:INVOLVED. Jo-Jo Eumerus (talk, contributions) 11:16, 5 November 2017 (UTC)
  • Couple of points here. This is not about NFC. It never was and never will be. Non-free use is a completely different policy that has nothing to do with this. If you believe that this is about NFC please revisit your post.

    To those that are bringing up NOLEGAL. I don't see how that is relevant at all. Would you considering deleting things under F9 or G12 legal advice? I certainly hope not since that would cripple our ability to deal with copyright infringement. This is about the community being able to override legitimate copyright law via consensus or lack thereof (in the case of a no consensus close). Right now that is possible. This RfC is an attempt to rectify that. --Majora (talk) 01:15, 6 November 2017 (UTC)

    • Agree on the NOLEGAL point. Yes, we don't try to present legal advice to readers, but internally we have to be 100% of legal matters and implement policies like EL, BLP and NFC to comply with legal requirements, as best as we can interpret them. There are times we turn to WMF to help resolve matters, but they have charged us to keep content within legal allowances for US law. --MASEM (t) 23:15, 6 November 2017 (UTC)
  • User:Marchjuly has very helpfully raised the matter at com:vpc where there has been a useful discussion. The position of "clearly in violation of copyright" does not seem to be supported. However, there seems to be sufficient doubt about the licensing of the image that Commons would not host the image because of Commons' Precautionary principle which is a matter of policy rather than law (and one I agree with). PRP is clear that what is relevant is whether there is significant doubt about whether an image is freely licensed. That is a different matter from whether its display here or on Commons is unlawful. My own view is that it is disallowed by policy but allowed by law (but I'm an internet dog). Thincat (talk) 11:53, 7 November 2017 (UTC)
  • I think the "no consensus = keep" closes when it comes to file discussions is something that needs to be addressed. Such closes may be less problematic in other XfD discusssions, but when I comes to files I think they need to be seriously reconsidered. File copyright issues can be quite tricky and I am certainly no expert on them, but it does seem that in almost every case a file's licensing either clearly complies with WP:COPY or it doesn't, and in the latter case the default should not be to keep the file. Wikipedia should adopt an approach similar to c:COM:PCP in such cases and delete a file whenever significant doubts have been raised about its licensing.
In this particular case, there were a number of things that probably should have been considered before closing the discussion.
  1. The actual link cited in support of the PD claim actually does no such thing:it states that most of the content found on the website is not copyrighted, but some might be copyrighted by others. This is quite common for government website, even US federal government websites, so assuming that something hosted by such a site has to be PD is often a mistake.
  2. The EXIF data of the file shows that the copyright is not held by the organization given as the source of the file, but is actually credited to a different party, which means that it needs to be verified how this party licenses it content. If not clear, then clarification should be sought (perhaps at WP:MCQ).
  3. Consideration also should have been given as to whether this file would be accepted by Commons. There's no reason for an official PD-licensed photo of a US state government official downloaded from one of the state's official websites to be hosted locally on Wikipedia and such files should (eventually) be moved to Commons. So, the administrator should've considered whether the file would be accepted by Commons. When there's doubt as to whether it would be appropriate to move the file per WP:MTC#Do not Transfer, then perhaps clarification should be sought at c:COM:VP/C. If a PD-licensed file of US origin is unlikely to be kept by Commons, there's no point in moving it, thus no point in keeping the file locally since the {{PD-ineligible-USonly}} cannot be used and {{Keep local}}/{{Do not move to Commons}} should not be used in a case like this.
So, unless the closing admin actually felt strong enough to cast a keep !vote, the FFD should have been (in my opinion) either relisted (with perhaps clarification sought at MCQ or COM:VP/C) to see if a stronger consensus could be established or should have been deleted without any prejudice against the file being restored at a later date via WP:DR if the PD claim is subsequently verified. I understand that this might be alot to ask for an adminstrator to do and appreciate all the admins who try to help and reduce the backlog at FFD, but I do think that perhaps that it would be better in most cases for an admin to pass on closing a discussion if they only feel confident enough in reaching a "no consensus = keep" close. -- Marchjuly (talk) 01:53, 8 November 2017 (UTC)
  • TonyBallioni brought up the exact same thing to me a few days ago. It seems like a precautionary principle at FFD might be acceptable. But it would have to be specifically tailored to make sure it isn't gamed. The principle would not apply to any file being brought to FFD on fair use grounds, etc. That seems like a discussion that should be had in my opinion and would probably make this entire RfC moot. --Majora (talk) 02:09, 8 November 2017 (UTC)
@Majora and Marchjuly: the basic principle that I believe every admin who is working in any form of copyright deletions (text or file) should follow is this: if an administrator would be unwilling to take on the personal liability of restoring the content if it had already been deleted, and they are considering actively declining to delete it, they should let an admin who is more experienced with copyright issues handle the request, whether it be CSD, XfD, or revdel. This would address all the no consensus situations above when admins who are not familiar with copyright default to keep when a file would be eligible under one of the CSD criteria. TonyBallioni (talk) 02:47, 8 November 2017 (UTC)
@Majora: Nitpicky perhaps, but I think Wikipedia should try to maintain a distinction between non-free content and fair use because Wikipedia's policy is considerabally more restrictive than the US concept of fair use and different countries may treat "fair use" or refer to it differently (e.g., fair dealing than the US. It's easy for those not familiar with Wikipedia and the difference to treat them as one and the same, which is why it tends causes a fair amount of misunderstandings as expalined in WP:ITSFAIRUSE. Now having said that, I don't think non-free content use should be automatically excluded from any Wikipedia PCP because I've seen some "no consensus = keep" FFD closes for non-free files which also seem questionable. While it's true that not every FFD discussion regarding non-free content use involves immediate deletion, they do in a sense involve a discussion of Wikipedia's policies on using copyrighed content. I think it would be acceptable for deletion/removal via FFD per a Wikipedia PCP type of rationale because the burden for justifying non-free use seems to be strongly placed upon those wanting to keep/use a non-free file per WP:NFCCE. If there exists substantial disagreement as to whether a non-free use rationale which clearly shows how all ten non-free content criteria are met to the satisfaction of the community has been provided for a non-free file, the default fallback close should not automatically be "no consensus = keep/not remove". The discussion can be relisted as necessary, but if a consensus still cannot be achieved, then maybe the use should be disallowed per such PCP type of rationale. I understand that opinions on non-free use can be quite subjective, but if a consensus cannot be clearly established via a FFD that the a particular non-free use is justified per relevant policy, keeping the file as a default seems (in my opinion) to be a mistake. -- Marchjuly (talk) 03:23, 8 November 2017 (UTC)
There is definitely a line between what is an outright copyright failure that must be deleted immediately (eg someone posting something like the Flag Raising at Iwo Jima and claiming they are the owner of the copyright), and NFC problems which require a bit more care and human handling to make sure it is not small issues or consensus-based decisions to be made. Admins should be able to delete images on a precautionary measure if they are reasonable certain there is a copyright problem (eg clearly wrong license, clear lack of ownership to claim licenses, etc.). If they do have doubt (as would be commonly the case with works published overseas in the mid-20th century, which become embroiled in a mess of legalese), that should be discussed at MCQ or some other place to figure out the legal issue. Once that legal issue is dealt with, the rest of such images then become subject to NFC and image use policies, which means that's where consensus should be engaged. Admins can tag such images for removal, but this does require a 7-day period for editors to respond to and a second human review to delete. --MASEM (t) 16:59, 8 November 2017 (UTC)
@Masem, Majora, and TonyBallioni: I understand what you're all saying, but let me use Wikipedia:Files for discussion/2017 July 17#File:Robert Goldston01.jpg as an example of where I think some kind of c:COM:PCP-type of policy/guideline could also be helpful regarding an FFD discussions about non-free images. The file in question is of a individual who is presumed to be dead, but for whom no reliable sources can be found to establish that he is truly dead. So, per WP:BDP, such individuals are assumed to be living until the age of 115. The file was originally tagged for speedy deletion per WP:F7, but it was sent to FFD because being born in 1927 apparently means that an individual in unlikely to still be living. The file was nominated at FFD and the only response in favor of keeping the file was that BDP is unjustifiably long based upon a Wikipedia article about average life expectency,, which might be the case but which is not a justification for non-free use. FFD does not always attract lots of attention from the community at large and the FFD was relisted twice by two admins before by closed by a third admin as "no consensus = keep" with the comment "There aren't enough people interested in the issue to establish a consensus." After the FFD was closed, the application of BDP in this particular case was discussed at Wikipedia:Biographies of living persons/Noticeboard/Archive257#Robert Conroy Goldston and the consensus of one other admin and two very experienced editors (one who is now also an admin) was that it did apply and the use of the image should not be allowed per WP:NFCC#1. When the closing admin was asked to clarify the close, they seemed to give as a reason that a non-free file of the author in his prime would be better than a freely equivalent photo of the author at his current age, which is something that has really nothing to do with NFCC#1 and which is essentially a !vote which the admin should've been made in the FFD itself. Having to re-nominate this at FFD might have been avoided if there had been some PCP-type of guidance for admins that "no consensus = keep" should not be the default FFD close even for a non-free file whenever there are significant doubts raised about the file's use/license, and that either relisting or seeking further clarification at WT:NFCC or WP:MCQ (or even in this case at WP:BLPN) is preferred. If clarification had been sought, then perhaps the one of the three FFD admins would have learned that there is actually a pretty strong consensus which has been stable for many years that non-free images are, in principle, simply not allowed for identification purposes in articles about still living individuals, even long retired not publically active individuals, except in certain cases such as when the individual's Wikipedia notability is primarily based upon their physical appearance. FWIW, I am not trying to re-FFD this file here (the file can be nominated at FFD again), but just using it as an example how a default "no consensus = keep" close, even for non-free files, does not seem to work as well as it might in other XfD discussions and giving administrators a little more leeway/guidance might actually be a good thing. -- Marchjuly (talk) 14:34, 9 November 2017 (UTC)
See, that's a reasonable fair NFCC discussion, and the type of thing that an admin shouldn't step over "consensus" (of which there was no feedback for all purposes on that FFD). If the guy was alive or not is a fair question that we can't prove either way, but we can at least make reasonable guesses that both what their apparent age would be (115, unlikely) and the forum post that says he's likely dead, and thus we keep under NFCC allowances. We have to make some judgements like that, but none of that is a outright copyright violation problem that an admin should overstep. --MASEM (t) 14:39, 9 November 2017 (UTC)
  • Do we have any indication of whether a discussion closer who allows a copyright violation to stand would be legally liable if they were wrong? And I am asking legally. Jo-Jo Eumerus (talk, contributions) 11:12, 11 November 2017 (UTC)
Well, it wouldn't be the first time that someone tried to bring legal action against an individual editor (e.g., [7][, [8], [9], [10]). Would they have enough knowledge of our deletion process to pin it on a particular closer? Would they succeed if they tried? That's probably speculation all the way down. I think the more interesting question that comes to mind, is if WMF were hit with a subpoena to reveal the identity of an editor who was identified to the foundation, would they have to comply with it? GMGtalk 12:16, 11 November 2017 (UTC)

comment: I would just like to point out that every single !vote supporting the nomination so far doesn't seem to recognize we already have a system of checks and balances in place for blatant copyright violations to be removed without question by any single user no matter what the consensus is. I see no point in granting "special privileges" to admins when they (and everyone else) already possess such a privilege. If the admin/s or editor/s in question did not know how to exercise such privilege in the case/s provided by the nominator, then I will suggest to you that this would be another example of why we should oppose special privileges. Admins are just as susceptible to misuse as anyone else. And, as I pointed out in my !vote, it would likely fail by having the opposite intended effect. It didn't work out for the Galactic Republic when they awarded Senator Palpatine special powers, and it will be bad for us too... :) Huggums537 (talk) 23:51, 23 November 2017 (UTC)

What are you talking about? Last I checked editors can't "remove" files. That would require their deletion which unless I slept through a seismic shift in Wiki-policy can only be done by admins. Are you thinking about text copyright? Text copyright can be removed by anyone by simply rewriting the content. Although that still requires an admin to intervene to actually rev'del it from the history. Sure you could remove any violating images from articles but that doesn't solve the problem. It still exists. --Majora (talk) 03:15, 24 November 2017 (UTC)
Sure, some things still require admin intervention. I stand corrected on that. However, those things which require admin intervention can easily be achieved by admins who already have the special powers to do so. That was my whole point. In any case, every editor does in fact possess the power to correct any one of these problems by way of proxy. They need only to enlist the assistance of any single admin to do so. This is all possible because the special powers already exist. One only needs to know how to access these powers to make use of them accordingly. Now that we have properly dispensed with my technical error, perhaps we could address something else in my statements other than just the minor mistake I made? (Please don't say you want to address my Star Wars references!) Huggums537 (talk) 06:54, 27 November 2017 (UTC)
I think you have missed the entire point of this discussion entirely. Could I have just asked another admin to delete the image? Sure. I probably could have gotten it done in two seconds if I really wanted to. I know plenty of admins that would have done it. That is really not the point at all. Me "accessing those powers" is completely irrelevant. The point is that the closing admin didn't want to "go against a lack of consensus" even though they were told by multiple people that the image couldn't be hosted here. Even though there was plenty of evidence that the image was not public domain and was actually F9'able. --Majora (talk) 02:45, 28 November 2017 (UTC)
I understand THE point just fine. Frankly, it's the only point that concerns me, and that point is simply if we should or shouldn't allow admins to have a special power. However, It is not really needed by your own admission, "I probably could have gotten it done in two seconds if I really wanted to. I know plenty of admins that would have done it." Furthermore, giving said powers introduces new problems, which have already been raised earlier in discussion. "I came across a stubborn admin who stood his ground, so give me special power" [paraphrased] is simply not reason enough for me to do so. I understand that may seem like an oversimplification to you since you have all these complex copyright/policy rationalizations to justify YOUR point, but this is how I sometimes like to reduce things to their simplest form in order to make the decision easier for myself. Thanks. Huggums537 (talk) 10:39, 28 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 for changing the production section guidelines. 2

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

RFC on Chinese railway station title/style conventions

It's only six days into the RFC, but I see a broad consensus, with no major opposition, so closing early. The decision is that Chinese stations and others should conform to the convention used elsewhere - i.e. to lower-case "station", "railway station" etc. unless there is strong evidence that "XXX Station" is actually a proper name in any specific case. SMcCandlish's suggestion of a MOS:TRANSPORT guideline for this is a good one, and I suggest that go ahead.  — Amakuru (talk) 12:03, 16 November 2017 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should railway stations in China by titled with capitalized "Railway Station", as suggested at Wikipedia:Naming conventions (Chinese)#Railway stations, or with lowercase "railway station" as suggested in conventions for all other countries (WP:USSTATION, WP:UKSTATION, WP:CANSTATION, WP:Naming conventions (Australasian stations), WP:NC-PLSTATIONS)? That is, is there reason to treat made-up English names of Chinese stations as proper names, unlike what we do in the rest of the world, or should we work on bringing these into alignment with WP:NCCAPS and MOS:CAPS? 06:43, 10 November 2017 (UTC)

  • Background – A user has suggested that a centralized discussion is needed instead of just working on these incrementally; see Talk:Harbin Railway Station.

Comments on Chinese railway conventions

  • Lowercase like everywhere else – Tons of discussions resolved this issue in the US, UK, Canada, Poland, etc., over the last 5 years, and other places have gone along (lots of recent fixes have been made in Philippines, Vietnam, Malaysia, China, etc.). Many articles already start with the "name" at the top of infobox omitting "railway station" altogether, since it's not really part of a name, just there to say what kind of thing we mean. Many just say "station" or "railway station" without caps in the article, including sometimes the lead and sometimes not. Sources are mixed, with lowercase being pretty common on all that I've looked at. If there are Chinese stations that actually include "Railway Station" in their name, the way Union Station (Pittsburgh) does, I haven't found it. We should fix the aberrant convention and fix the articles, even if it takes a while. Dicklyon (talk) 06:52, 10 November 2017 (UTC)
  • All station articles that use the term "railway station" should have the term in lower case. Mjroots (talk) 14:40, 10 November 2017 (UTC)
  • Note: Thailand railway stations are subject to the same question. A few hundred Category:Thai railway station stubs use capped "Railway Station". Any reason not to fix those? Dicklyon (talk) 20:10, 10 November 2017 (UTC)
  • Lower-case, per WP:CONSISTENCY, MOS:CAPS, WP:NCCAPS. Sources use a wild mixture of styles, and WP does not capitalize unless the souces do so with remarkable consistency.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  22:20, 10 November 2017 (UTC)
  • Thank your for starting this discussion, Dicklyon. I am happy to support lower casing "railway station" in titles for all East Asian/SE Asian countries (I think I've also seen this come up with Vietnamese stations). Jenks24 (talk) 22:32, 10 November 2017 (UTC)
    Thanks for your support, though I'm not sure why you thought we needed to go through this again. I pretty much dealt with Vietnam stations already (see Category:Railway_stations_in_Vietnam), and got no pushback on that. In my experience, I see pretty much all stubs being created with Title Case, and someone needs to fix them; so when I find big clusters of over-capped stubs, I work on them; sometimes following the links leads into related areas, which is how I got from Vietnam to China, I think, perhaps via Category:Asian railway station stubs. A handful per day, in fits and spurts as time allows. Dicklyon (talk) 22:43, 10 November 2017 (UTC)
    Because as has been proven on numerous occasions, mass-moving hundreds of articles is rarely uncontroversial and has created a lot of headaches in the past when things get stuck halfway. Even in cases where it does end up being uncontroversial (and I don't think you can exactly say this one has gone smoothly), it hardly hurts to have a discussion prior to moving hundreds of articles. There have been plenty of times in the past where you something you, SMc, Tony and co. thought was a straightforward reading of the MoS turned out not to be the case when brought to a wider discussion. Jenks24 (talk) 10:02, 12 November 2017 (UTC)
  • Lowercase for all articles for Chinese stations titled "Name Railway Station". If this RfC applies to them, also change "Station" to lowercase for all rapid transit station articles in Mainland China, except where "Railway Station" is part of the proper name (e.g. Hongqiao Railway Station (metro) → Hongqiao Railway Station station). Also rename MTR station articles, Light Rail stop articles and probably West Kowloon Station to use lowercase, since sources generally don't care about the capitalization. (West Kowloon Station could be renamed "West Kowloon railway station" for consistency but there are very few sources which have called it that rather than West Kowloon [Ss]tation.) Jc86035 (talk) 04:17, 11 November 2017 (UTC)
  • Lower case. (Responding to the RfC alert). This seems fairly clear cut, and is probably just some misunderstanding of the rules on capitalisation that just doesn't happen to have been noticed/challenged until now. Since their actual names aren't in a language that uses capitals, we should apply the usual rules for this site when determining what's capitalised and what isn't. If it applies in the UK (say), hard to see why it wouldn't for English translations of Chinese names. Anaxial (talk) 07:13, 11 November 2017 (UTC)
    • Not that it has direct relevance here, but for Chinese, the Wikipedia house style includes WP:PINYIN and pinyin capitalisation rules for proper names mirror those of English, i.e. title casing rather than Romance- or Slavic-style lowercase titles.* AjaxSmack  19:28, 11 November 2017 (UTC)
  • Comment This photo shown the English name wasn't makeup at least for this station. [11] Matthew_hk tc 11:27, 13 November 2017 (UTC)
    That's a point. It's good that the name we use agrees with what's displayed at the station; we do list alternative names, too. But we don't set it in all caps like that station sign does, nor in title case as you're suggesting. Dicklyon (talk) 05:11, 14 November 2017 (UTC)
It just depends on the interpretation on "proper name". For some metro station, for example trans Perth, just "City West" was used in the broadcast, but for Chinese train station, full name was used as the same location may have bus and metro station. Form a MoS and then have an expectation like Central Station, NY, seem odd to me.Matthew_hk tc 05:21, 14 November 2017 (UTC)
[] Matthew_hk tc 05:29, 14 November 2017 (UTC)

Extended discussion of Chinese railway conventions

Further, we should consider a merge of all of these things into a single MOS:TRANSPORT page (with a WP:NCTRANSPORT section, or small separate page, to cover the handful of titles-specific issues) along with all the stuff about rail way and bus lines, highways, yadda yadda. All of these things are basically wikiproject WP:PROJPAGE essays that someone has slapped a {{Guideline}} tag on without a WP:PROPOSAL process. It's just a WP:POLICYFORKing farm, with every little topical fiefdom trying to make up its own rules instead of normalizing on a single set of conventions that are actually consistent with the overall guidelines like MOSCAPS and NCCAPS. A merge process would be a great opportunity to remove a lot of WP:CREEP.

And, basically, there isn't anything about train stations in China that especially has to do with Chinese culture, the subject of MOS:CHINA, so that page should never have entertained such a section. I checked, and there was never a consensus discussion to add it. Someone from the trains projects with a real jones for overcapitalizing has simply been adding "rules" that fit their preference to various pages, without regard to whether they represent consensus or conflict with existing site-wide norms.
 — SMcCandlish ¢ >ʌⱷ҅ʌ<  22:20, 10 November 2017 (UTC)

  • @SMcCandlish and Dicklyon: Thank you for starting this RfC, although I personally would have done it for all train/tram/metro stations instead of only ones in China. Does this apply to the articles of the 30 or so rapid transit systems in China; does this apply to Hong Kong or Macau, or Taiwan (which is not part of China but it would be better to clarify this); and how does this apply to rapid transit stations whose proper names are the name of the adjoining railway station, e.g. Beijing South Railway Station (subway), where "Railway Station" is part of the station's proper name (noting that Hongqiao Railway Station (metro) is already named differently to Shanghai Hongqiao Railway Station, as with Tianjinzhan [Tianjin Railway Station] Station)? Jc86035 (talk) 03:26, 11 November 2017 (UTC)
    That's a great question! I do think this applies pretty generally, but I've also stated that where "Railway Station" or "Station" is part of a proper name, we'd cap it. I hadn't thought about a subway station names for a railway station, but yes, I do think it's a proper name in such cases. So Beijing South Railway Station (subway) is good, but Beijing South Railway Station Subway Station would not be. I don't think there's any new principle here, just following the usual style and naming guidelines, which sometimes requires a second look. I'm not asking for a new rule like always downcasing "Railway Station", just following old guidelines like not capping what's not part of a proper name. Dicklyon (talk) 03:36, 11 November 2017 (UTC)
    @Dicklyon: If I voted for "lowercase" and nothing else, would my vote be for "Hongqiao Railway Station station" or "Hongqiao Railway Station (metro)", given that the latter would then be inconsistent with the other stations in the system which would have a lowercase "station" at the end? Could you clarify in the description that the RfC only applies to the PRC, including Hong Kong and Macau and all rapid transit systems, but not including Taiwan? Jc86035 (talk) 04:17, 11 November 2017 (UTC)
    I don't have any firm ideas what all it applies to. If you have information about how Taiwan might differ, let's talk about it, rather than leaving it open. Dicklyon (talk) 04:24, 11 November 2017 (UTC)
    @Dicklyon: I don't think it would differ much (though I haven't checked), but since this RfC is currently for Chinese railway stations, if you add Taiwan you may as well also add Japan and the Koreas. Jc86035 (talk) 04:59, 11 November 2017 (UTC)
    Yes; my premise was that China was so far capped differently from the rest of the world. If we see similar elsewhere, I'd presume the result would be similar; that is, there's no know special exception for Japan or Korea or Taiwan or Isreal, so let's work on fixing those, too, if we find over-capitalization there; I'm fixing Israel at present. Dicklyon (talk) 05:17, 11 November 2017 (UTC)

    I wasn't part of starting this RfC, I just noticed it when I did the one below. For my "drive-by" part, I'll just reinforce what Dick_Lyon said: The entire point is WP:CONSISTENCY with the rest of the categories and with site-wide norms, not inventing a new pseudo-norm. We're getting rid of a pseudo-norm someone tried to impose without consensus on a particular category by naming the articles "their way". I'm sure they meant well, but it was misguided. There's not only no rationale for a "China exception" to MOS:CAPS (et al.), there's less of a possibility for one at all because these aren't even really the names, they're English approximations of them, and are basically descriptive. (I'll defer to others' judgement on whether some subway stations and the like might actually be proper names; it's a hair I don't feel like trying to split.)  — SMcCandlish ¢ >ʌⱷ҅ʌ<  03:40, 11 November 2017 (UTC)

@SMcCandlish: Off topic, but I just noticed that all Oslo Metro stations and most Oslo Tramway stations (stops) are named “Xxx (station)” rather than “Xxx station”. Useddenim (talk) 17:09, 11 November 2017 (UTC)
As long as we have a situation where random wikiprojects are making up their own "rules" on the fly without any concern for consistency, that sort of thing's going to happen. Thus, my suggestion to merge the material into one MOS:TRANSPORT (or whatever) page.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  20:44, 11 November 2017 (UTC)

Sitewide stats

I don't have a great count, but based on searches like this one, it looks like we have at least 10,000 articles with "railway station" in the title, and fewer than 5% of those capped as "Railway Station". The easiest way to find lots of examples of the capped ones is to search for China within the search results; that accounts for most of them.

Extending to "Station", including "Metro Station", we do find a lot more capped, esp. in Japan, the Koreas, Thailand, Hong Kong, and Iran. The percentage capped in searches like this one is closer to 10%.

Once we discuss these enough, it might make sense to get some help constructing a list carefully and them commission a bot to do the moves, like we did for the long tail of nearly 2000 WP:JR fixes. Dicklyon (talk) 04:22, 13 November 2017 (UTC)

User:Certes has made a list at User:Certes/Railway station of article titles that include capped Railway Station or Railway station. By his first-cut categorization, it looks like about 90% of these should be downcased. I believe he said there are about 1500; I've asked if he can also count how many have lowercase railway station, as my search topped out at 10,000 and the total is probably several times that. Dicklyon (talk) 05:16, 14 November 2017 (UTC)

It would be many months of work to fix all these by hand (I've moved maybe 2500 articles by hand so far this year); but if we approve a list and get a bot, it's a few days. This has worked well in the past, and it looks like there's support here, in principle, to fix these, if we come up with the list, yes? Dicklyon (talk) 05:20, 14 November 2017 (UTC)

Article namespace (excluding redirects) has 19,094 pages with "railway station" in any case, of which 1,594 have a capital somewhere, so 17,500 are in lower case. I'm hoping we can ignore those titles as being already correct. Certes (talk) 10:19, 14 November 2017 (UTC)
Thanks! So my "fewer than 5%" was a bit of an underestimate of how many we might need to fix; closer to 8%. For "Station" without "Railway", likely similar but probably more in total. Dicklyon (talk) 16:17, 14 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.

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)

RfC on naming of Chinese railway line articles

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 1Place 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.

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

  1. 1A is not actually an option (per MOS:CAPS, WP:NCCAPS, WP:NOR).
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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 conventions1B 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 [12] 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 [13]) 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)

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)

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)

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)
  • 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 - 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.[14] This RfC was initially closed as not supported but Rentier reversed the close.[15] 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)

RfC: Comma or parenthetic disambiguation for "small places"

There are recurrent disputes about article titles for what could be called "small places" – churches, sporting event arenas and other venues, schools and other institutions, malls, plazas, parks, outdoor statues and monuments, railway stations, and other things to which one can go but which are structures or otherwise have an architectural component, and are not villages, cities, forests, or other large areas. Just today, for example, there was move-warring between Nieuwe Kerk, Amsterdam and Nieuwe Kerk (Amsterdam), both moves performed via WP:RM/TR despite being potentially controversial. I see stuff like this all the time, and the amount of disruption (both to article locations and to editorial tempers) has gotten to the "enough is enough" point.

Should Wikipedia:Article titles#COMMADIS be applied to such "small places" consistently, or should we continue to arbitrarily apply parenthetic disambiguation to some of them? If the latter, what determines whether to use the one style versus the other?

Background: according to WP:ATDIS policy, parenthetic disambiguation is the third (that is, quite disfavored) choice in disambiguation style, with comma-based disambiguation ahead of it as number 2, and natural disambiguation preferred over all. An argument can be made that comma style in this sort of case is actually a form of natural disambiguation because it is regularly used in everyday English (i.e., comma disambiguation that isn't also natural is really more like Robert Scarlett, 2nd Baron Abinger and Robert Scarlett, 6th Baron Abinger – an awkward formalism, though still less awkward than parenthetic). The section in this policy on comma disambiguation gives both royal styles/titles and locations as examples, but not only is this not an exclusive list, it specifically says "Comma-separated disambiguation is sometimes also used in other contexts". The counter-argument appears to be that "places" was meant to be interpreted strictly as jurisdictions, is not inclusive of structures, fields/pitches, and other "micro-places", and that "sometimes also used in other contexts" doesn't apply to them.

 — SMcCandlish ¢ >ʌⱷ҅ʌ<  05:51, 23 November 2017 (UTC)

What are you raving about, McCandlish? There has only been a single move, which I performed (not by WP:RM/TR), at Nieuwe Kerk, Amsterdam, to what you admit (behind the usual smokescreen of verbiage) is the right title. You might be thinking of Oude Kerk, Amsterdam, which is where it has long been, until some well-meaning type briefly moved it to Oude Kerk (Amsterdam), to agree with the Nieuwe Kerk as it then was, and I moved it back (via a WP:RM/TR request). The vast majority of churches are disamed with a comma, and rightly so. No "move-warring", still less "pointless but heated and near-constant disputation", & nothing "potentially controversial", Johnbod (talk) 13:22, 23 November 2017 (UTC)

Comments on COMMADIS scope

  • Apply COMMADIS consistently, as more in keeping with WP:CONSISTENCY and WP:NATURAL policies (not to be confused with WP:NATURALDIS, which is dependent on it), and to put an end to pointless but heated and near-constant disputation over this disambiguation trivia, which is predicated on subjective, unclear, idiosyncratic distinctions about what is and isn't a "place".  — SMcCandlish ¢ >ʌⱷ҅ʌ<  05:51, 23 November 2017 (UTC)
  • Support for all cases where there's no good reason to do otherwise. Tony (talk)
  • No objection to adding churches, parks and stations to the list. But for example this generally does not work for paintings in art galleries (or in cities). Johnbod (talk) 13:40, 23 November 2017 (UTC)
    • Sure; this isn't mean to apply to anything no one would think of a "place", i.e. something one can neither enter nor (thinking of large monuments with no doors) climb. If it's big and outside, it should qualify. More like: stuff that our language naturally disambiguates with commas qualifies generally (per WP:ATDAB policy's order of disambiguation-style precedence); but commas don't work well for small, indoor things, or for stuff that's abstract or a person, or otherwise not something we non-awkwardly use commas with in English.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:49, 26 November 2017 (UTC)
  • I do not get how this works for neighborhoods/sections of a city, where there is also a park or other geographical feature with the same name. Alanscottwalker (talk) 13:47, 23 November 2017 (UTC)
    • Same as for any other such naming clash: disambiguate further, probably parenthetically. The idea that "Foo Bar, Baz" and "Foo Bar (Baz)" with each term identical between the examples (i.e. Foo = Foo), is supposed to meaningfully disambiguate between (e.g.) a park and a neighborhood is silly and impractical. The fact that people have been trying this and that readers and even many editors have been confused by it is a part of why this RfC has been opened. The sensible approach is to use "Foo Bar, Baz" for the WP:PRIMARYTOPIC and "Foo Bar, Baz (park)" or whatever for the non-primary one(s).  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:42, 26 November 2017 (UTC)
  • Comma disambiguation is a relic of the fact that this is how names of populated places tend to be addressed in the real world. I think it would be absurd to apply it to objects like statues. With respect to natural features like rivers and mountains, it typically distinguishes between those features and place names that happen to include the word "River" or "Mountain". bd2412 T 05:51, 24 November 2017 (UTC)
  • Note: An editor has expressed a concern that editors have been canvassed to this discussion. (diffs: [16], [17], [18])  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:37, 26 November 2017 (UTC)
  • Consistency is not needed... What determines whether to use the one style versus the other? Discussion and local consensus. Blueboar (talk) 15:11, 26 November 2017 (UTC)
    That doesn't seem to be particularly meaningful. This is a discussion, and WP:CONLEVEL specifically exists to prevent a "local consensus" from making up its own rules that conflict with site-wide policy like WP:ATDAB.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:38, 29 November 2017 (UTC)
I’m not saying that a “rule” should be made at a local level... I’m saying that the “rule” is: “There are several acceptable forms of disambiguation”... and the determination of WHICH acceptable form of disambiguation is most appropriate to use in any given article has to be made at the article level... on a topic by topic basis. Blueboar (talk) 13:04, 3 December 2017 (UTC)
  • This RfC seems a poorly framed (i.e., unclear) attempt to make policy based on edge cases. In general, I really, really do not understand why some editors have such an irrational dislike for parenthetical disambiguation. Personally, I think parenthetical disambiguation should be the default EXCEPT in those cases where there is a commonly used natural language title. Parenthetical disambiguation makes it clearer to readers what part of the title is the actual name of the subject rather than some arbitrarily appended term to disambiguate. So, I think that would place me firmly in the oppose camp. olderwiser 15:25, 26 November 2017 (UTC)
    Cognitive dissonance. It seems "unclear" to you, and you "don't understand" and think there's something "irrational" going on because you've made an incorrect assumption that this has something to do with likes and preferences. In reality, it's about how to apply the WP:ATDAB policy more consistently, to avoid continual pointless dispute on the matter. By way of analogy 1: You can harbor a dislike of a particular rule in Texas hold'em poker and wish that the game were a little different, but you'll still strenuously object when one of your opponents cheats under the rules as-written. Analogy 2) Your argument is effectively indistinguishable from "Kosher and hallal are weird nonsense. I don't get why these people hate pigs and have emotional issues with dairy. It's irrational that they won't eat my pepperoni pizza." It has nothing to do with emotional preferences, but with wether the food you put in front of them complies with rule systems they take seriously.

    I personally don't mind parenthetic DAB at all. I'd be quite happy if we eliminated all other options. But we have a four-tier system of DAB, with parenthetic in next-to-last place of preference, and that's what consensus has decided we collectively want. Analogy 3: Don't show up to a football game with a basketball and complain about all this kicking and grass and lack of a hoop.
     — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:45, 29 November 2017 (UTC)

    I stand by the assertion that this is unclear (not only that it seems so). You want to read WP:ATDAB policy as being more hierarchical than it is or than how others interpret it. Sorry, I remain unconvinced. Ignoring your deprecating asides as off point and irrelevant, I continue to maintain it is more beneficial for readers to clearly mark the disambiguating terms with parentheses rather than make implicit suggesting that the comma term is a part of the name. olderwiser 16:18, 30 November 2017 (UTC)
  • Close per WP:FORUMSHOP. See Wikipedia talk:WikiProject Trains#RfC: UK railway station disambiguation. --Redrose64 🌹 (talk) 21:24, 26 November 2017 (UTC)
    • Nonsense. That's an only tangentially related discussion, primarily about word order, for one topic+country intersection. This is about a general principle across all topics, site-wide.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:36, 29 November 2017 (UTC)
So what was the objection to advising those participating in that specific discussion that a discussion of the 'general principle' had now been initiated (and would outrank the local discussion)?Rjccumbria (talk) 16:48, 30 November 2017 (UTC)
I don't know. Where is this objection of which you speak, so we can look at it?  — SMcCandlish ¢ >ʌⱷ҅ʌ<  10:53, 3 December 2017 (UTC)
  • There is absolutely nothing wrong with comma disambiguation for these places. It should be applied as it has always been applied. Consistently according to consensus (e.g. in most Commonwealth countries, the consensus is and has long been to use commas). -- Necrothesp (talk) 14:20, 29 November 2017 (UTC)
  • I have several issues:
    • I agree with Bkonrad in believing that my esteemed colleague, SMcCandlish, is mistaken in asserting that, because in WP:ATDIS policy, parenthetic disambiguation is listed third, it is a "quite disfavored" choice in disambiguation style. In fact, WP:ATDIS says, "When deciding on which disambiguation method(s) to use, all article titling criteria are weighed in," and then it lists 5 methods. There is no basis for concluding that these methods are listed in order of most-favored to least-favored.
    • The topic heading here is vague. Streets and roads are long and narrow; are they small places? For example:
    • Schools are typically disambiguated with parentheses, see, e.g. Lincoln High School.
    • It was recently decided that rail lines should use parentheses disambiguation.
    • "X, state" implies that X is the name of a locality within a state, for example, Syracuse, New York. We should avoid using comma disambiguation when it incorrectly implies that something is a locality.
    • In conclusion, I think this proposal should be quietly forgotten, i.e.,
    • Close. —Anomalocaris (talk) 10:20, 3 December 2017 (UTC)
  • Use parenthetical disambiguation for geographical objects which are not, as Wiktionary says, "inhabited areas" (place § English § Noun 1.3). While both would be correct but strange if inserted into the middle of an English sentence (and assuming we can't use "in place" as a disambiguator), using parentheses would marginally help with some consistency in naming for classes of physical objects which are disambiguated by things that are and are not place [inhabited area] names, such as railway stations. Jc86035 (talk) 15:13, 3 December 2017 (UTC)
  • Prefer comma disambiguation when it would be a natural way to describe a place in a sentence. As Jc86035 says, some "would be correct but strange if inserted into the middle of an English sentence"; the comma-disambiguated ones that would be correct and not strange should be preferred that way. I would think this would apply to a lot of Main Streets and railway stations. Dicklyon (talk) 16:17, 3 December 2017 (UTC)
  • Close. I cannot see how any one rule is going to fit well for all purposes, places, and regional styles; the reasonable exceptions may well outweight the "majority". "Small places" is imprecise, likely to create more EW, not less. Maybe this RfC could be broken down in a few manageable sub-cases (like the railway naming), but not one rule to ring them all. --A D Monroe III(talk) 18:04, 3 December 2017 (UTC)

Extended discussion of COMMADIS scope

Are these "small places" actually places, or are they just things which happen to have a fixed place because they're too big to move easily? For example, Forres railway station just moved. (Must update the article...) The term "Forres railway station" now applies to the new facility (even though they built new platforms rather than shifting the old one), suggesting that the article's topic is an object rather than a place. There is an argument for COMMADIS applying, but I don't think it's an obvious consequence of "small places" being a subset of "places". Certes (talk) 15:18, 26 November 2017 (UTC)

@Certes: See also wiktionary:place#noun. I think you could look at this debate as entirely based on which sub-definition of "place" is supposed to be meant. Jc86035 (talk) 15:21, 3 December 2017 (UTC)

Should there be an absolute deadline on drafts in Draft space?

(non-admin closure) Consensus is that the WP:G13 deletion guideline is sufficient. power~enwiki (π, ν) 01:13, 9 December 2017 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I realize that there is (generally) no WP:DEADLINE, but under our current policy, a draft can be deleted after six months of inactivity. However, an editor could theoretically create a draft and make only a very minor improvement once every five months and 29 days forever. I think that after some length of time - say, five years, a draft should at least be subject to some sort of mandatory review by an uninvolved third party to figure out why it has dragged on in draft space for so long. My suspicion is that if it takes longer than that to write the article, then it is probably not worth having. bd2412 T 05:48, 24 November 2017 (UTC)

There is no need to have a time limit. If someone wants to waste their time doing something once every six months, but you think the draft is totally useless, then you can try out MFD. But if you think it has potential then you can edit it and move it to be an article. There is no need to waste too much time looking at every draft to see if someone is gaming g13! Graeme Bartlett (talk) 08:39, 24 November 2017 (UTC)
I would still like to know that it exists to make that call. Is there a list of oldest drafts somewhere? bd2412 T 13:35, 24 November 2017 (UTC)
You can probably find the oldest pages in Draft space using a simple SQL. For example, this shows you the top 10 pages that have been "touched" last. So it seems there are not really any such "sleepers". Anyways, I do agree with Graeme Bartlett: As long as someone works on it, let it be. And if they are "gaming" the system, MFD can always handle it. Regards SoWhy 14:00, 24 November 2017 (UTC)
MFD doesn't work very well for this. If a draft is in draftspace and fulfilling the requirements to be in draftspace, then it is unlikely to be MFD'd. If its not in draftspace (so user subpage) then its variable. There is one user with approx. 500 drafts in his userspace, some of which have not been touched for over a year. Try MFD'ing one and see what happens. Only in death does duty end (talk) 15:10, 24 November 2017 (UTC)
I have MFDd multiple drafts in draftspace where the user who started the draft was returning every 6 months, and tweaking the page such that it did not improve to meet mainspace standards. --Izno (talk) 16:21, 24 November 2017 (UTC)
How do you find them? bd2412 T 16:24, 24 November 2017 (UTC)
In general or for a specific user? If you want to see a user, you just go to their userpage, select page information on the left, then 'number of subpages of this page'. Eg: this. You can also the do the search the same way if you know the syntax. This of course does require suspecting or knowing the user has a load of drafts. I see this hasn't had any work on it since February... Only in death does duty end (talk) 16:32, 24 November 2017 (UTC)
I am referring to drafts in draft space. To be clear, I am looking for the oldest drafts, not the drafts that have gone the longest without editing. bd2412 T 16:49, 24 November 2017 (UTC)
So, you are suggesting that we should not allow users to keep drafts just because of their age, in spite of the fact that there is no deadline and they are following the rules of being edited within 6 months? Besides, your proposal will probably eventually backfire since a limitation of 5 years will turn into 3, then 1, and the 6 month time limit already in place to make improvements to drafts will soon become a deletion benchmark to rush drafts into mainspace before they are "too old" and all the time invested into them is lost. This will only encourage users to crank out crap. No thanks. I'd rather let them sit in draftspace forever than have to deal with the flood of crap that will only consume valuable time and resources to review, and end up deleting anyway. I agree you have a point that sitting in draftspace for lengthy periods is indicative of not warranting an article, so why not leave it alone where it belongs in the developmental setting until it is ready? Research and development can often take years. Also, the term Development hell exists for a reason, and many projects stuck in this state have eventually completed successfully. Huggums537 (talk) 06:01, 25 November 2017 (UTC)
Why the enthusiasm to delete old drafts? It is not as if the WMF is wasting money buying 55 gallon drums of ink and railroad boxcar loads of paper. Hey, I have some uncompleted drafts in my sandbox space that are older than six months old, and maybe I will finish them after I retire, which will be in a year or two. Why spend valuable editor time trying to delete old drafts, when the actually visible encyclopedia needs so much work? I simply do not understand this "delete active drafts" compulsion. Cullen328 Let's discuss it 07:48, 25 November 2017 (UTC)
I am mainly in agreement with Cullen here. There is all too much enthusiasm, for no good reason in my opinion, to delete "stale drafts". Often there is usable material that should be retained and used, and those doing the deleting are often not in a position to judge that. The drafts are causing no harm where they are, and are not indexed by Google, so I am baffled by the zeal for deletion for deletion's sake. Softlavender (talk) 09:33, 25 November 2017 (UTC)
Count me as baffled too. I'm not sure what "itch" the would-be deleters of "stale drafts" just for that "reason" feel so compelled to "scratch", but there are far more pressing things to worry about than some unfinished texts in an unindexed area designed to contain just that, however long they have existed there. As Cullen points out, they are neither "stealing resources" nor hurting our encyclopedia content, indeed they may eventually improve it, so why is it so desperately important to "exterminate" them? -- Begoon 09:51, 25 November 2017 (UTC)
Without taking a position on this issue, the reason people are concerned is the same reason G13 exists in the first place; things falling through the cracks. Yes, most stale drafts are harmless, but there are plenty which are attack pages, copyright violations, spam, fake articles, and so on. The basic question is whether decreasing the load those put on MfD (where these things are invariably deleted) is worth the trade-off of less oversight in deleting them. The Blade of the Northern Lights (話して下さい) 16:20, 25 November 2017 (UTC)
As these types of problematic pages can already be deleted under existing guidance, what's needed is a process to review the draft pages. A change in guidance to introduce a mandatory review after a fixed period isn't necessary; the draft articles can be reviewed for these sorts of issues at any time. isaacl (talk) 18:10, 25 November 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── No, because the existing guidance requires someone to review each draft while a G13-like process can be handled by a bot. It takes much less manpower to police for such issues when drafts have a deadline (and thus a number of problem drafts are deleted when hitting that deadline, something that can be automated to a large degree) than when not (when someone has to check every draft). Jo-Jo Eumerus (talk, contributions) 10:27, 26 November 2017 (UTC)

Jo-Jo Eumerus, it's not quite clear what you are saying no to, especially since you seem to actually agree with the Question of this thread. Could you quote what you are saying no to? Thanks. Softlavender (talk) 10:31, 26 November 2017 (UTC)
I was disagreeing that these types of problematic pages can already be deleted under existing guidance is enough to address The Blade's concern about non-obvious problems lingering in draft space. I am not necessarily committed to having a draft deadline given some of the counterarguments (for example, that a deadline may motivate people to rush drafts into articlespace) presented here, I just wanted to note that while manual/individual review is a great idea it often requires more manpower/manhours than what is realistically available. Jo-Jo Eumerus (talk, contributions) 10:40, 26 November 2017 (UTC)
Which is essentially what I meant when I said MFD doesnt work well (as the existing process in place) for this. Only in death does duty end (talk) 10:49, 26 November 2017 (UTC)
The original proposal, though, required additional review, and so it would not help with the problem of available volunteer time (which I agree is a key factor in any process). To help keep this discussion focused on the viability of the original proposal, I suggest having a separate thread to discuss ideas on the concern regarding drafts with problematic issues covered under existing guidance (attack pages, fiction, and the like). isaacl (talk) 15:58, 26 November 2017 (UTC)
I seriously doubt there are more than a mere handful of people who are willing to make edits to a page every 6 months for more than the suggested 5 year limit. The guidelines that are currently in place are well equipped to handle this minor problem. The suggestion to create a bot for this is like creating a bomb to kill a fly. It's overkill. Creating a deadline and a bot to serve that deadline will not address any of Blade's concerns either, and will lead to other problems as I mentioned earlier. Instead, suggest to create a bot that will seek out and destroy spam, copyright, and attack pages. That would be a suggestion worthy of nomination, but not this deadline. Huggums537 (talk) 21:45, 26 November 2017 (UTC)
The fact that drafts can be maintained forever with just a once-every-six-months edit may lead editors to create a large number of drafts with the intention of getting around to them eventually, and then procrastinating with a small edit every six months, and every six months after that. Draft space is not web hosting space either, even if a draft is not an attack, a hoax, or a copyvio. I would like to know some metrics on this. How many pages are there in draft space right now? How old are the oldest drafts, in terms of the date of page creation? What is the rate at which drafts are moved to mainspace? bd2412 T 21:55, 26 November 2017 (UTC)
User:Nettrom, is there any chance that you have some numbers on the pages in the draftspace? Whatamidoing (WMF) (talk) 03:07, 1 December 2017 (UTC)

The first step is look at the data (corpus of Draft articles) and see if there is a problem, how big is the problem, and why does it happen. Has anyone done that? Understood it's quicker to create policy based on intuition. Is 5 years the right cut off? Is there even much of a problem? Certainly spammers might use Draft space to get SEO content well placed indefinitely.. -- GreenC 22:07, 26 November 2017 (UTC)

Part of the problem, from my perspective, is that I have no idea where to get any metrics about drafts. I know we have fewer than six million articles, and more than 43 million pages overall, so the number of drafts is somewhere in that group of 37 million pages. bd2412 T 22:32, 26 November 2017 (UTC)
So we want to penalize well intentioned procrastinators based on our fears about alleged web hosting abuse (of which we have no evidence for) without first knowing any metrics on drafts? I see the logic of BD2412's rationalization that the ratio of articles to drafts has some implications, but I agree with Green that we need to identify an actual problem first so we can attempt to define what those implications might be rather than simply basing them on our worst fears. Huggums537 (talk) 23:04, 26 November 2017 (UTC)
I want to give well-intentioned procrastinators some motivation to get their drafts in shape to get into mainspace. It is also bad for us if these are topics that we are missing, and that reasonably should be included in an encyclopedia, but that are not included because the editor who was interested enough to start a draft has not been interested enough to work on it. bd2412 T 04:01, 27 November 2017 (UTC)
I'm afraid you have just contradicted yourself. At the beginning, you suggested that those drafts were "not worth having", but now they have become "topics that we are missing". I'm not sure if it's because you're starting to see things differently or beginning to change your mind or what. At least you seem to have good intentions though. It's commendable to desire improvement. I just think a deadline and mandatory review is the wrong way to go about it, but now that we have some data it can be a good starting point to figure out the right way... Huggums537 (talk) 15:49, 27 November 2017 (UTC)
It's not a contradiction, just an open problem. We don't have any metric for determining whether a given draft is trash or treasure other than someone happening upon it, or the draft getting deleted for going stale. bd2412 T 02:35, 28 November 2017 (UTC)
Wikipedia:Database reports/Page count by namespace shows 33404 Draft articles. -- GreenC 03:35, 27 November 2017 (UTC)
Thank you Green, for some factual data. So, it's not even in the same solar system as the "estimated" 37 million that our earlier reference to disparage in ratios would seem to imply... However, to be perfectly fair, the total page count (including pages with redirects) was 66617 when I looked at it. But, still... a huge difference! Huggums537 (talk) 04:16, 27 November 2017 (UTC)
I think when a Draft moves to mainspace it gets redirected ie. completed Drafts. But not positive. -- GreenC 14:55, 27 November 2017 (UTC)

Oppose - does Wikipedia need the used server space? It is an interesting idea but It would take editor time hours, and I don't see any meaningful impact it would have. - Knowledgekid87 (talk) 23:41, 26 November 2017 (UTC)

Also, because deleting an article causes an increase in the use of server space, not a decrease. Because every state of an article is saved on the servers, every action, including deletion, uses extra server space. Ergo, if server space were even an issue, deleting a whole bunch of articles (because of the way that a Wiki works) uses up more space. The only thing to do (if that were a concern) would be to leave it alone. The only reason to delete is if it violated some other core principle, such as being a BLP violation or being an attack page or obvious hoax, or the like. If its just a plausible article in development, then it does no harm. --Jayron32 14:57, 28 November 2017 (UTC)
No per much of the above discussion, this is a solution in search of a problem. Roger (Dodger67) (talk) 15:05, 27 November 2017 (UTC)
Yes, but only if drafts with clear potential are saved by one of the following methods: 1) Clear claim of notability and least two WP:INDY RS that provide non-trivial coverage: move to mainspace, even if it badly needs work, since it will survive both CSD and AfD. 2) Clear claim of notability but insufficient sourcing to survive AfD in its present state: 2a) userspace to principal author if still active, or 2b) otherwise leave in place, and invite others to "adopt" it (e.g. we could have a page for this, or maybe notify relevant wikiprojects, or others have edited it in a non-gnome capacity.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:56, 29 November 2017 (UTC)
I've yet to see a reason I even understand, for doing this. It feels very controlling to me and actively harmful to the encyclopedia. Where there are problems you can use MfD. Hobit (talk) 03:00, 5 December 2017 (UTC)
Well stated. We shouldn't be controlling and harmful. Sławomir Biały (talk) 03:07, 5 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.

2018 Temporary Policy?

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Whilst the proposal was well-intentioned, this ain't happening.Everybody is a volunteer and is free to choose the area and amount of their workload.Thankfully, Winged Blades Godric 14:54, 3 December 2017 (UTC)

Can I politely suggest a temporary policy for 2018 that anyone requesting/renewing/etc their adminship be tasked with helping at Wikipedia:Backlog, emptying a single long-since-embarrassingly-pathetic category like Category:Wikipedia articles needing factual verification from June 2007 and Category:BLP articles lacking sources from October 2006? We could use the help, and I doubt any of them would (admit that they)'s a community effort! AMightierHeart (talk) 00:44, 27 November 2017 (UTC)

Wow. That's pretty sad. Do you have to be an admin to participate? Nevermind. I just answered my own question. I'll never have to search for an article to edit again... I have an endless supply!! Huggums537 (talk) 01:06, 27 November 2017 (UTC)
  • Oppose: I just can't condone any kind of forced labor. Also, I'm very unsure about "temporary" policies as well. Huggums537 (talk) 01:54, 27 November 2017 (UTC)
  • Oppose all volunteers. Also, we should not be creating more hurdles to people requesting admin rights. TonyBallioni (talk) 01:58, 27 November 2017 (UTC)
  • Comment This request strikes me as a special case of something I proposed some time ago: Tour of Duty. It didn't get traction then, but I still think it has merit, and the three categories identified would all be suitable candidates.--S Philbrick(Talk) 04:32, 27 November 2017 (UTC)
  • Oppose None of that requires the admin bit. Everybody - including unregistered users (who form the majority of our readers) - can assist in finding sources. If such users cannot edit the articles (because of semi-protection, a conflict of interest, etc.) they can still suggest sources on the articles' talk pages. Now, if you were proposing that somebody take on Category:Administrative backlog it might be a different matter. --Redrose64 🌹 (talk) 11:13, 27 November 2017 (UTC)
  • Oppose - There is generally no connection between sourcing and adminship; some would be good at the latter and bad at the former. עוד מישהו Od Mishehu 08:53, 28 November 2017 (UTC)
  • Oppose the very idea is unworkable; but if I had to pick a backlog to conscript people for, I'd pick the one at WP:GAN. power~enwiki (π, ν) 04:53, 29 November 2017 (UTC)
  • Oppose We each have our own priorities and all of use struggle to recruit more participants for the endless work needed. BLPs are not my priority. Doc James (talk · contribs · email) 18:06, 29 November 2017 (UTC)
  • Comment from Nominator, yes, BLPs are nobody's priority...that's the problem, and why we have liabilities strewn around the project ten years after they've been pointed out and tagged...anyways, turns out I was incorrect, apparently a lot of people are willing to admit that they'd really rather not do any clean-up that isn't fun... AMightierHeart (talk) 17:24, 1 December 2017 (UTC)
  • Oppose - I appreciate the well-intentioned effort, but these are not only for administrators. But I would support reminding users (everyone) about backlogs where they are welcome to help, planned editathons on obvious needs, for instance. —PaleoNeonate – 05:48, 2 December 2017 (UTC)

The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

RfC about river disambiguation conventions

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)

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

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)


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)

Notice of RfC on journalistic independence and notability

See Wikipedia talk:Notability (organizations and companies) for an RfC on notability's independence concept.  Unscintillating (talk) 03:28, 2 December 2017 (UTC)

Nope. Killed it. Jytdog (talk) 03:38, 2 December 2017 (UTC)

Proposal to create a divergent naming convention for animal breeds

FYI: Pointer to relevant discussion elsewhere.

Please see: WT:WikiProject Dogs#Domestic animal breed page names, an informal RfC of sorts, in response to a WP:RM discussion the (entirely routine) outcome of which someone objects to. The proposal would reverse over two years of RM discussions to apply natural disambiguation to animal breed article titles, and instead impose not just parenthetic, but multi-word parenthetic, plus allow it to be variable by wikiproject. Perhaps this is a good idea, perhaps not.

I think broader input is needed specifically because a) it's an attempt overturn long-standing and many-times-confirmed consensus (which is possible but unlikely without a strong site-wide showing of agreement), yet b) the discussion has not been "advertised" anywhere but wikiprojects about animal breeds (i.e., the only editors who've ever favored parenthetic disambiguation in such cases, because it matches breeder jargon better, have effectively been directly canvassed, though I doubt that was the intent).  — SMcCandlish ¢ >ʌⱷ҅ʌ<  09:39, 2 December 2017 (UTC)

MOS:PN to MOS:CAPS merger

FYI: Pointer to relevant discussion elsewhere.

General community input requested at Wikipedia talk:Manual of Style/Capital letters#Merge in MOS:PN.

Summary: We have a page (which is virtually never edited or cited) at WP:Manual of Style/Proper names that is redundant with WP:Manual of Style/Capital letters and its material on proper names/proper nouns, but the former is a bit more specific on a few things, and these should probably be retained. Ergo, it's proposed to merge the salvageable material from MOS:PN into MOS:CAPS. Some of MOS:PN would not be retained in MOS:CAPS because it is non-MoS material about article titles, redundant with various naming conventions pages such as WP:Naming conventions (people), etc.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  10:18, 3 December 2017 (UTC)

  • The reason I oppose this at the discussion is that the long-time "WP:Manual of Style/Proper names" guideline includes the wording Wikipedia does not seek to judge such rival claims, but as a general rule uses the name which is likely to be most familiar to readers of English and SMcCandlish hasn't agreed that when a merge occurs that this language be included in some form. "As a general rule uses the name which is likely to be most familiar to readers of English" is wonderful encyclopedic-appropriate language, and is a common sense guideline/policy which is now in place. A merge should include this language, which has been stable. Randy Kryn (talk) 15:04, 3 December 2017 (UTC)

RfC: Accessibility versus convenience in indentation

Rejected. See more comments below. Nyttend (talk) 21:27, 10 December 2017 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should MOS:MATH and WP:INDENT be updated to comply with the WP:MOS and MOS:ACCESS instructions on accessible indentation in 2017 Wikipedia's article content?

Background: WP editors have long misused description list markup for indentation (we do it all the time on talk pages). MoS has also long advised to not do this in articles, and to instead use indentation templates (e.g. here). We provide various templates for doing accessible indentation that does not cause problems for screen readers (for details, see MOS:ACCESS, specifically WP:Manual of Style/Accessibility#Indentation).

WP:Manual of Style/Mathematics (MOS:MATH) has been advising (in one section) the continued use of description list markup for visual indentation in articles, for reasons that do not appear clearly articulable other than that doing it with : list markup is simply easier for editors. This appears to be a guideline PoV fork. (And a pointless one, since no one would be "punished" for doing it the crude way, we'd simply advise the better way and WP:GNOMEs would incrementally fix cases of it being done the bad way).

A decade-old essay, Wikipedia:Indentation (WP:INDENT), is also providing outdated and incorrect information on how to indent on Wikipedia; it pre-dates these templates' deployment. Editors are reverting WP:MOS- and MOS:ACCESS-compliance updates to MOS:MATH on the basis of this essay [19].

A background point from the opening paragraph of WP:MOS: "If any contradiction arises, this page has precedence over all detail pages of the guideline [e.g. MOS:MATH], style essays [e.g. WP:INDENT], and the Simplified Manual of Style." The policy basis of this is WP:CONLEVEL: no individual or group of topical editors can make up their own rules to override site-wide consensus based on their personal preferences. No WP:IAR rationale has been provided for forking MOS:MATH from the rest of MoS on this trivial point. This RfC is a procedural one, since at least two editors are edit-warring against MOS:MATH's accessibility compliance and demanding a show of consensus to comply.

 — SMcCandlish ¢ >ʌⱷ҅ʌ<  13:32, 3 December 2017 (UTC)

A better summary of the RFC issue is: "Should articles be forbidden from using colons to indent displayed equations, as in mathematics, chemistry, and other fields?" Tens of thousands of articles, including featured articles such as Californium, use colons for indentation. There is no recent "fork" here, as the language at the Math MOS has been in place since at least 2005 [20]. There is also no template that is even somewhat often used instead of colons to indent equations that appear on their own line - this indentation is essentially always done with colons. The MOS should reflect this near-universal usage, where the Wikipedia style is very clear from practice. At the same time, the developers should work to make this style emit better HTML. — Carl (CBM · talk) 13:41, 3 December 2017 (UTC)
Separately, neither WP:ACCESS and WP:MOS forbids the use of colons, and I think that all of the MOS policies are currently in agreement that colons can be used. — Carl (CBM · talk) 13:50, 3 December 2017 (UTC)
Congratulations for just contradicting yourself. It isn't possible for a guideline to "forbid" anything anyway. If there's a technical necessity for some reason to use : markup for non-list indentation, anyone can cite WP:IAR and just do it. It's difficult to imagine such a scenario, but whatever. No one can be "punished" for not writing in compliance with MoS. The only issues here are PoV-forking in an MoS that has nothing to do with indentation, way from the main MoS page and the accessibility MoS page, which do have something to do with indentation; giving bad advice when better advice is available; and (in theory) interfering with editors using the better advice to produce more accessible markup after the fact. No where anywhere in this is there any suggestion that anyone will be forced to stop misusing colons for indentation in articles (and it's not like we're going to stop doing it on talk pages, a lost cause until they're replace with some kind of threaded messaging system that's also capable of rendering MediaWiki markup samples accurately).  — SMcCandlish ¢ >ʌⱷ҅ʌ<  03:28, 4 December 2017 (UTC)
  • Indents are perfectly fine to do with colons, and I would oppose doing them with any other methods. Headbomb {t · c · p · b} 13:55, 3 December 2017 (UTC)
    Also, to all those complaining that the issue hasn't been addressed in years, Mediawiki is open sourced. If the WMF hasn't coded the solution to this rather low-priority thing, why not apply a little WP:SOFIXIT? Headbomb {t · c · p · b} 22:21, 6 December 2017 (UTC)
    What Wikitext is VE producing for indents? · · · Peter (Southwood) (talk): 14:02, 3 December 2017 (UTC)
    Nothing. You can use blockquotes if you want something indented in the visual editor. (In the wikitext mode, it's whatever you type, just like the older wikitext editors.) Whatamidoing (WMF) (talk) 19:47, 6 December 2017 (UTC)
  • Indenting in this way makes sense in this context... and if it conflicts with MOS? Well, MOS does say that there will be exceptions. I think this is a valid exception. Blueboar (talk) 14:08, 3 December 2017 (UTC)
    • I don't think there is a conflict - the MOS has always allowed colons for indentation, as evidenced by their use in featured articles. I think the proposal here is, essentially, to change the MOS to forbid colons. Some language was added to WP:ACCESS just today [21]. — Carl (CBM · talk) 14:25, 3 December 2017 (UTC)
      Wait... there wasn’t any conflict between practice and guidance... until SMC created one with his recent edit to ACCESS? With no prior discussion for that recent edit? And then he points us to CONLEVEL? (Based on an edit that had a consensus of exactly one person... himself!) ... talk about gaming the system! I have reverted his edit. The way this is supposed to work is that we hash it out first, reach consensus, and THEN write guidance to reflect that consensus. An editor can’t slip in a change to guidance, with no discussion, and then immediately turn around and claim CONLEVEL applies. Blueboar (talk) 15:07, 3 December 2017 (UTC)
  • Not yet. You haven't really come up with, or let everyone figure out, a good alternative. There have been some thoughts discussed, but this RFC is premature until there's something more solid to recommend. You also haven't addressed the technical feasibility of an automatic conversion tool, because something like "the gnomes will fix it all", is not a proper answer for that. –Deacon Vorbis (carbon • videos) 14:11, 3 December 2017 (UTC)
  • No but only if it's technically possible to distinguish indentation and actual definition lists with an acceptably small increase in parsing time. Semantically, since the <dd> tag is only supposed to appear as a definition following a <dt> tag, if a ;/: MediaWiki list doesn't begin with a ; item (or doesn't contain any ; items) then all : in that list could be treated by the software as <p> with indentation. Jc86035 (talk) 14:30, 3 December 2017 (UTC)
  • Oppose. If the MOS does not correctly explain that colon indentation is how Wikipedia presents displayed equations, fix the MOS instead. Or maybe go for a technical fix and stop treating ":" as a HTML "definition list" for screen readers: everywhere on Wikipedia, it is used for indentation level. A fix for this should include talk pages. —Kusma (t·c) 14:32, 3 December 2017 (UTC)
    There is no (forthcoming) technical fix. One has been asked for from the MediaWiki developers for over a decade and they've done nothing to fix it.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  03:22, 4 December 2017 (UTC)
    There might be, if m:2017 Community Wishlist Survey/Reading/Functional and beautiful math for everyone were more popular. But in general, if you're interested in technical fixes, you should start there and work backwards to the detailed discussions at the German Wikipedia about this subject (earlier this year; look for a proposal by User:Debenben). Whatamidoing (WMF) (talk) 19:47, 6 December 2017 (UTC)
  • Oppose proposed change to longstanding guidelines. Firstly, this is arguably one of the most ill-formed RfCs I've ever seen, and is unlikely to lead to a new consensus because it is not even clear what the "consensus" concerns. How, exactly, should displayed math be indented? As a block quotation? Using math display="block">? Some other method using templates? The phrasing is also highly misleading and non-neutral ("WP editors have long misused..."), with evidence for the "long misuse" apparently consisting of this edit and this revert, both from today by the same editor attempting to assert that the MOSMATH guideline is in conflict with ACCESS. Concretely, what seems to be proposed is this: that the way displayed math is typeset in Wikitext is to be changed on all of our mathematics and scientific articles, including all featured mathematics articles and good articles. Implementing this proposed change would require someone trusted by the community, with toolserver access, to change possibly millions of lines of code in tens of thousands of articles. Legions of mathematics and scientific editors would need to familiarize themselves with a more complicated syntax for doing basic Wikipedia editing (and it is not even obvious what that syntax actually is as of this writing). Editing Wikipedia would become correspondingly less inviting for new editors because of the more arcane methods of indentation that are proposed (when those new arcane methods actually are properly proposed). Not only has there been no such impact assessment, but the stated reasons for the proposal are spurious, as far as I can tell. The referenced part of WP:MOS discusses the formatting of block quotations, not displayed math. The relevant content guideline, with longstanding established consensus, on how math should be typeset when displayed on its own line, is WP:MOSMATH. It has also been asserted that this longstanding guideline is in conflict with WP:ACCESS, but while WP:ACCESS notes that the use of colons is not semantically ideal for this purpose, it even provides guidance on how to use colons for exactly this purpose. I agree with others here that, if the semantics of the way the colon is translated into html do not agree with the intended semantics, the issue should be fixed at the software level, not by requiring Wikipedia's new editors to learn CSS. Finally, I do not think this is a significant issue with screen readers and displayed math. Far greater is the issue of making equation alt text understandable to the vision impaired. The semantics of indentation are by far a secondary concern. Sławomir Biały (talk) 15:10, 3 December 2017 (UTC)
    Hear, hear! I'm sick and tired of hearing about how screen readers can't understand this and that. If I can see it, the screen reader can describe it. Fix the broken screen readers. EEng 17:32, 3 December 2017 (UTC)
    You realize you're supporting a minor MoS page contradicting two major ones, including the main one, in away that violates WP:CONLEVEL policy, right?  — SMcCandlish ¢ >ʌⱷ҅ʌ<  03:22, 4 December 2017 (UTC)
    Among several points that I raised in my vote, was your failure to show any contradiction with existing guidelines. Sławomir Biały (talk) 11:16, 4 December 2017 (UTC)
  • Oppose. WP:MOS has not section about indentation and use of colon for that. All occurrences of "indentation" is this page are about block quotations, not at all about the usage of colons in math and talk pages. MOS:ACCESS says Colons (:) at the start of a line ... is not ideal for accessibility or semantics, but is currently in wide use. Thus, there is no guideline discouraging the use of colons for indentation (except for quotations), and there is nothing to which MOS:MATH and WP:INDENT should comply. Moreover, accessibility includes ease of reading sources, and any replacement of colons must keep reading sources easy. No such replacement is proposed. D.Lazard (talk) 15:33, 3 December 2017 (UTC)
  • Support The use of colons produces broken definition lists (and broken html) that are yet another unnecessary annoyance for anybody using a screen reader. Their use should be discouraged, and it should be obvious that we ought to be bringing guidelines documenting poor practice into line with guidelines recommending best practice – which is to use one of the already existing templates that produce visual indenting without causing any problems for visually impaired readers. --RexxS (talk) 18:04, 3 December 2017 (UTC)
  • Comment: This is Yet Another Case of the WMF doing something stupid (putting out HTML that contains definition lists for content that isn't even close to being a list of definitions) and the community trying to work around the stupidity.
Wikimedia Foundation financial development multilanguage.svg
$90 million dollars in assets, but somehow they can't afford to hire someone to fix the ancient creaky wikimarkup-to-HTML conversion software. --Guy Macon (talk) 19:04, 3 December 2017 (UTC)
That is a misstatement of the case. They haven't gotten around to it because that would cause a single wikitext encoding to create two different kinds HTML. That's bad for everyone--developers, users, and editors. --Izno (talk) 21:11, 4 December 2017 (UTC)
  • Tentative support per RexxS. The {{in5}} template appears to be an adequate replacement for indentation of formulas and other things. I don't see this as creating a huge burden for the community: those who wish to change colon indentation to something more suitable could do so as they please with the support of the MOS; this proposal wouldn't mandate an immediate change of every instance, as at least one "oppose" suggests. I also don't see this as being problematic for new contributors: they can continue to use colons, just as many use hyphens instead of en-dashes in numeric ranges—no one is punished, but those who notice will quietly fix it. Rebbing 19:10, 3 December 2017 (UTC)
  • Oppose. This is the wrong fix to a problem that is invisible to most editors and is really an issue in the Wikimedia engine having nothing to do with math. It would make Wikipedia mathematics editing harder, pointlessly, at a time when Wikipedia still lags behind literally every other mathematics-publishing site on the web in the quality of its mathematics formatting (see m:2017 Community Wishlist Survey/Reading/Functional and beautiful math for everyone) and when we still have battling gnomes some of whom are systematically going through mathematics articles stripping out <math> formatting and replacing it with html because our <math> formatting is so bad and some others of which are doing the opposite. The correct solution is for the Wikimedia developers to realize that the users have overwhelmingly decided that : means indent, not definition list, and to change how it is translated into html to reflect that. —David Eppstein (talk) 20:07, 3 December 2017 (UTC)
  • Comment If we are to do it then the <math display="block"> is the format we should use, it is a special software feature specifically designed to work with this problem. There are something of the order 35,000 articles which use math tags, I can generate a list if needed. It's not an unreasonable number of articles to use some bot or tool to process the articles. I'm not convinced there is enough need to do this and whether this is really a case of busy work. --Salix alba (talk): 20:27, 3 December 2017 (UTC)
  • Oppose deprecating ":" as standard indent. The recommended alternative, such as it is, is more cumbersome for something as often-used (especially for multileveling), and is fragile (equal-signs in math equations!). The use it too widely ingrained in too many places to change without being disruptive. If the problem is that colon makes HTML with incorrect screen-reading for the visual effect it creates and everyone uses it for the visual and visual-content/semantics effect it creats, then fix the HTML generator. I think WP:DLISTs are fairly rare. And they are fragile (in general and also towards screen-readers) when written using semi-colon/colon. We have a template set for them that is less fragile. So let's:
    1. Work towards using a template to in a less-common situation and to make things less fragile.
    2. Then make colon just do intending because that's the common use anyway.
For #1, a quarry for "line beginning with a semicolon" would be useful. that would also find places that such a syntax is used as inappropriate WP:PSEUDOHEADs. DMacks (talk) 20:58, 3 December 2017 (UTC)
  • Oppose. A classic case of the tail trying to wag the dog. If the problems arise because of the association of the starting colon with the HTML definition element, then the solution is obvious, you change the association instead of attempting wholesale behavioral modification of the editing population.--Bill Cherowitzo (talk) 21:03, 3 December 2017 (UTC)
  • Oppose. A colon means indentation in Wikipedia and changing that is a silly idea. What should be fixed if anything for accessibility is how : is changed into html. Figure out how we should represent indents in the first place rather than having people use some other symbol which generates this other html. Dmcq (talk) 21:13, 3 December 2017 (UTC)
    This is not a change; it's a conflict between an old MoS page (focused on nothing but math and having no bearing on indentation) advising bad markup, and two better-maintained MoS pages which absolutely do have normative things to say about page formatting, one of them being the main MoS page which trumps its subpages in the event of any conflict.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  03:22, 4 December 2017 (UTC)
    No, it doesn't. As you can see, consensus supports the currently used style, and the MoS as a descriptive document should reflect that. —Kusma (t·c) 09:57, 4 December 2017 (UTC)
  • Support, obviously, as the one who opened the RfC, and for reasons already given.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  03:23, 4 December 2017 (UTC)
  • Support. MOS:MATH#Typesetting of mathematical formulae and MOS:DLIST contradict each other on colon indents and should be made consistent. The former leads to HTML that fails validation. That's not just of academic concern. It generates nonsense output for visually impaired users, complicates navigation for keyboard-only users, and scrambles the page structure with possible SEO consequences. Even if colon indents were valid HTML, they'd still be an HTML hack doing poorly what CSS does well. Sure, <dl><dd> displays the desired way in some configurations, but that's not true of all browsers, devices, and skins. For example, a <dl><dd> between two <p>s is noticeably off-center vertically in the Minerva skin. MOS:DLIST leads to conforming HTML, and avoids all of these problems. Maybe someone can suggest for Extension:Math to support <math class="some-class"> to make it nicer to attach CSS to the tag in lieu of colon indents. Matt Fitzpatrick (talk) 11:10, 4 December 2017 (UTC)
    Wouldn't it make more sense to bring MOS:DLIST into line with the standard usage on Wikipedia? And then fix the conversion to html? Sławomir Biały (talk) 11:18, 4 December 2017 (UTC)
    As noted above, fixing the conversion to HTML has been listed in the WMF MediaWiki bug tracker as a to-do item for over ten years. They simply do not ever get around to doing it, and apparently never will. It is thus upon us to write accessible code rather than rely on the software to fix it for us when we don't. PS: Using : for indentation is not a "standard". There is no policy requiring it, and there is no guideline demanding it, other than one disputed line in MOS:MATH (a page which has nothing to do with indentation) trying to WP:POLICYFORK from the rest of MoS, which is itself against CONLEVEL policy. Using : for indentation is a bad habit we should not continue to do in actual articles (even if we think talk pages are a lost cause), because we know it's an accessibility problem and we know there are very easy other ways to do it properly. There is nothing even faintly challenging about doing {{blockindent|Foo bar baz}} instead of :Foo bar baz. It costs us nothing but a few characters, and is actually far more robust, because the colon markup is easily bollixed. For example, if an inexperienced editor closes a linebreak, Yadda yadda.:Foo bar baz, it fails, but this is not true of the templated version. There are various other circumstance under which the colon markup fails, such as being the first line inside a newly opened block element (full bug documentation here). The way the "I don't get it and don't care" responses above are going, this bulk of this RfC is just a big "fuck you" to people who depend upon even marginal accessibility at this site. Not cool. Not viable.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  11:49, 4 December 2017 (UTC)
    Comment: As one can see by looking at the source of the preceding comment, the one who opened this RfC uses colons for indenting. There is something wrong here :-) D.Lazard (talk) 12:03, 4 December 2017 (UTC)
    But the problem with screen readers and math is not the indentation, it's the math. This is a "fix" for the wrong problem. In any case, as the Phabricator link shows, the devs are aware of this issue but apparently do not think it is a substantial accessibility concern despite knowing more about the technical side of things than probably most of us here. If there is a strong case for an ACCESS violation, then I would raise it with the devs or the foundation. Sławomir Biały (talk) 12:33, 4 December 2017 (UTC)
  • Moot. This seems to have gotten lost, but I just wanted to say again that this is all pointless until someone comes up with a workable alternative, and tests it – extensively. I've seen multiple different templates suggested, but are we sure we really want to co-opt something beyond its main purpose for something this major? Should we come up with a new dedicated one? Should we add an attribute to the <math> tag? Will whatever is ultimately proposed work if it's set on a line by itself surrounded by spaces without adding extra paragraphs? Because if not, then page sources become more difficult to read and edit. I'm vaguely aware of a desire to add MathJax support (although I haven't really followed this); will a proposed solution play nicely if it's added? Again, until this sort of stuff is hashed out, any sort of policy change is premature – and yes, SMc, it is a change. –Deacon Vorbis (carbon • videos) 15:01, 4 December 2017 (UTC)
  • Support in principle, per RexxS, though I would have liked to see a more concrete draft change on which to comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:52, 4 December 2017 (UTC)
  • Comment: FWIW, I'm trying to start a discussion specifically on the "expand the functionality of the math element" aspect of this issue at Wikipedia talk:Manual of Style/Mathematics#Extending math element functionality (merely to consider the possibility/feasibility of providing this alternative method of indenting math in particular). Also, just to make this explicit: as indicated in a piped link above by the OP, other relevant discussion predating this RFC is at Wikipedia talk:Manual of Style/Mathematics#Indenting. - dcljr (talk) 19:00, 4 December 2017 (UTC)
  • Oppose: I think I understand the issue (that the use of a colon is an abuse), but unless there is a workable solution, I cannot support the change. -- Taku (talk) 21:42, 4 December 2017 (UTC)
  • Oppose in over twenty years of writing HTML, I have not once used a dd/dl style list. I would support an alternate proposal to formally redefine ":" to be an "indented list", in a way that codifies and allows for its co-mingling with ul and ol lists, yet allows it to serve as generic indentation as well. power~enwiki (π, ν) 01:51, 9 December 2017 (UTC)

Math block display

^ That looks indented to me. That seems like the functional and correct alternative. --Izno (talk) 21:11, 4 December 2017 (UTC)

Yes, that produces the correct appearance, but it's much more cumbersome to type. And it's not an improvement to use the usual solution when things are too cumbersome to type, templates, because | and = are used too often within mathematics formulas and are a pain to use as characters in the arguments to templates. Apparently, though, this solution is even worse in its html semantics than using a colon for indented formulas, because it nests <div> within <p>, not allowed in html. And if that were fixed, the right solution would be for the engine to recognize :<math> and translate it into the block display as it already does (note that when math is part of an indented block, it's displayed bigger than in inline text) and to produce cleaner html for it. —David Eppstein (talk) 21:30, 4 December 2017 (UTC)
div-not-in-p: Is there an actual Phabricator task regarding that issue? (Edit: I have submitted one at T182041.)
right solution would be for the engine to recognize :<math> and translate it into the block display You and others keep saying this. I do not agree that it is a true statement, for multiple reasons (already elaborated on the Phabricator task for that "improvement" already).
cumbersome to type There are many things cumbersome to type--for example, image syntax. Yet we somehow persist. I am not entirely sure why you're going on about templates, as the above is not a template nor is it in a template. --Izno (talk) 21:55, 4 December 2017 (UTC)
Maybe the better solution would be for the system to treat <math> when it is placed on its own line always as if it were a block. That reduces the burden further on us, and I would guess that's the intent in most cases when math appears on its own line. --Izno (talk) 21:58, 4 December 2017 (UTC)
<math> already sets its content to be class=mwe-math-element, so why don't we just use CSS (as was asserted to be the "correct" solution) in our skins to indent it? DMacks (talk) 22:09, 4 December 2017 (UTC)
The reason that doesn't work is because the Math extension HTML doesn't provide the necessary classes presently, without setting the math element explicitly to display as block, to differentiate block formatting from inline formatting for targeting in the CSS file. This failure is at presently due to the task on Phabricator I just filed. If the div were not placed inside of a p, we'd be fine to sort that out that way (minus the benefits that explicitly setting block currently provides, which is slightly larger presentation I think, but we don't get that already :D). I think I'll go file my other suggestion and see who pops up. --Izno (talk) 22:25, 4 December 2017 (UTC)
"more cumbersome to type" is a pretty poor reason to break accessibility and harm the ability to access Wikipedia for people with visual disabilities. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:29, 5 December 2017 (UTC)
Do really screen readers allow accessibility for math articles? I am not a specialist, but I am not sure that screen readers are useful for reading math. As far as I know, people with visual disabilities prefer the latex description of formulas rather than a spatial description of their displayed form that ignore the mathematical semantic. Thus accessibility implies to leave latex source as simple as possible, and this is in favor of keeping colon for indenting math. In any case, if screen readers are unable to deal with the present use of colon in math, they are certainly unable to deal properly with displayed formulas, and, in this discussion, the argument of accessibility is a pure fallacy. D.Lazard (talk) 09:34, 5 December 2017 (UTC)
To answer your question. Yes, all math has alt tags, which can be read by the the screen reader and some modern screenreaders can handle mathml to some degree (there is a hidden mathml description). There are also some specialised extensions, which can be used to enhance that even further. Screenreaders are able to handle colons just fine btw, it's just that they might tell screenreader users that a list will follow, while there won't be a list. This adds several words/sentences to the pronunciation that might be confusing and distracting for screenreader users. —TheDJ (talkcontribs) 10:14, 5 December 2017 (UTC)
If you are talking of the option <math alt= > you are wrong: it is rarely used in math articles, and, when used, the provided text is usually confusing, and, in any case, less clear than the latex source. In any case, alt tags are the worse solution, as you will never find math-competent editors that are willing to translate latex in English. The few alt tags that I have encountered in my edits (more than 1000 math articles in my watch list) are not understandable, or at least highly confusing. D.Lazard (talk) 11:15, 5 December 2017 (UTC)
No, the math tag where it displays an image includes the LaTeX as the alt attribute automatically. --Izno (talk) 15:25, 5 December 2017 (UTC)
The behavior is also different between the two versions in terms of what gets produced depending on if there are blank lines before/after the formula, or if there are no blank lines, but newlines, or if it's all written as a single line. I don't know HTML well enough to really know what's better, worse, or wrong, but it seems like a displayed equation should be part of the same <p>...</p> block, since it's usually part of the same paragraph (often part of the same running sentence even). It's not like that currently, but regardless, <math display="block">...</math> is producing some inconsistent results. Is there a wikitext token to just say "leave this line blank"? Like a hyphen on a line by itself or something. That would at least mitigate the problem of having LaTeX code crammed together with English if there's going to be some difficulty in figuring out if blank lines should be ignored or not. –Deacon Vorbis (carbon • videos) 23:07, 4 December 2017 (UTC)
{{Block indent}} uses <div>, and it's valid markup to nest divs inside each other. There is nothing faintly "cumbersome", as wikitext goes, about {{block quote|1=Your math here}}, expecially given the arcane geekery that goes into formula markup itself. This "it's too hard, so I'm going to use : and screw all those people who use screen readers" is about as plausible as NASA engineers claiming it's just too complicated to use turn signals when they're driving to work.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  11:24, 6 December 2017 (UTC)
If you convert to templates, then you won't be able to use the equation editor in the visual editor. If you haven't tried it before, then this link should take you to a little equation in my sandbox. (Setting block formatting is one click from the quick edit mode, or under the 'Options' tab in the full editing mode, but the other features in the full mode are even cooler.) Whatamidoing (WMF) (talk) 20:07, 6 December 2017 (UTC)

@Whatamidoing (WMF): Thanks for the ping and for taking the time to try and help with the problem.

I did a little survey in the German Wikipedia a few months ago. The long term goal that got the most votes was to turn <math> into proper inline math with \textstyle as default and use something like <math display="block"> or some equivalent notation as a proper block formula. The plan that I would have suggested is the following: Resurrect the MathJax display method which already was configured such that <math> was inline. It only turned it into a block equation for new lines with a colon in front. If that is done, one could replace the colons with some other markup.

I still think this would be a good plan, but at the moment it does not seem to be possible to get enough support for it. The biggest problem in my view are not the colon indentations but all those workarounds like {{math}} etc. I might be biased because the German Wikipedia is one of the few projects not using them and in the survey they decided unanimously not to introduce them. As far as I know those are not accessible to screenreaders at all and I continue to be surprised that so many editors are happy to learn some special mix of HTML and wiki-templates to write some formulas. Other options I can think of:

  • Push ahead with turning <math> into inline math even without MathJax: I do not know any website that uses server-side generated svg images for mathematical equations. I doubt that it is possible to use this technique to get a rendering that is at least as good as those HTML workarounds. If templates are used for inline math, there is no strong reason why inline should be made default for <math>. Also <math display="block"> cannot replace a lot of block formulas, because \text{} often looks ugly and for non-latin languages it might be not readable at all. Even dots at the end of a sentence look different in math tags than outside of them. Currently some editors prefer to write them outside of the math-tags of a block equation even though this might lead to them being broken into a new line. Finally one would need something that can take care of the numbering of equations and replace templates like {{NumBlk}}. Without those problems solved, such a change would just be a lot of work and might result in more workarounds.
  • Bring back the "use HTML for simpe formulas" option that was abandoned in favour of MathJax: I still frequently encounter those \!\, hacks used to circumvent some bugs or because some editor wanted to ensure that all symbols and expressions have the same appearance. I am afraid that a solution like this might backfire and make everything worse.
  • Change the global CSS to match that of enWP to make <math display="block"> indented everywhere: I think this does not really help. More or less everyone still uses the colons for indentations and with the problems mentioned above I do not see that this is going to change in the near future. In case this encourages people to use the new <math display="block"> option, there would be more than enough formulas still needing the colon indentation. Finally I do not know if there is a more intelligent solution than the
    .mwe-math-mathml-display math { display: inline; }
    abuse or if one should just leave the MathML rendering inconsistent.

Summary: At the moment I do not see a way out of this deadlock. I am kind of getting tired of all those meta-discussions and trying to convince people why something like MathJax is needed or why the WMF should care about math rendering. For now I will probably just go back to spending my time writing articles and maybe try again in a few years time.--Debenben (talk) 13:44, 9 December 2017 (UTC)

So I finally broke down and took a quick look at MathJax, and oh my god, why aren't we using this already? It really seems like the way to go. And if we're worried about accessibility via screen readers, it's apparently way better in that regard too. I'd also be fine with <math>...</math> for inline and <dmath>...</dmath> for a block as I saw suggested elsewhere (I can't remember where). I also still think that it would be good to keep these on separate lines in the editor with blank lines surrounding them to make it more readable, especially for long equations. And then it would be a lot better if there were a way to tell the parser to just "ignore this line" (no new paragraphs, and no breaking of lists, which would already be useful for separating comments on talk pages without having to worry about those same MOS:LISTGAP issues). But I have no idea how feasible that is, or how likely someone is to add it, even if it is. –Deacon Vorbis (carbon • videos) 17:27, 9 December 2017 (UTC)
MathJaX was supported at one point, but was removed in 2015. See phab:T99369 for a long discussion on the topic, and Wikipedia talk:WikiProject Mathematics/Archive/2015/Aug#Future of MathJax on wiki as well. Anomie 17:14, 10 December 2017 (UTC)


After running for seven days, this discussion has largely gotten opposition; people make strong points, including the absence of a comparable alternative (as demonstrated by colons being used by the proposer), the fact that this proposal would render numerous good and featured articles at variance with policy, and above all else, the fact that the proposer has added his preferred wording to MOS:ACCESS and then half an hour later referred to that change as a basis for this proposal. Moreover, over at WP:VPT, the proposer left the following note:

The RfC at Wikipedia:Village pump (policy)#RfC: Accessibility versus convenience in indentation was opened as a question of whether it's permissible for MOS:MATH, which has nothing to do with indentention, to demand that editors misuse definition list markup in articles for this purpose, when the main WP:MOS page and MOS:ACCESS have for years recommended a better method of indenting. This has somehow turned into a torches and pitchforks campaign to ban the use of accessible alternatives to the abuse of : markup. I've never seen anything like it in my entire 12 years here, and am skeptical that the regulars of VPTECH would agree with the rationales being offered there. There's a palpable hostility in play, toward accessibility, HTML specs, and WP:CONLEVEL policy.

Our policies outright forbid such hostile characterization of other editors, and blatant canvassing like this has the effect of tainting all further support. Editors who falsify pages for their own purposes, or commit blatant personal attacks on others, or who engage in public canvassing are typically given extended blocks as well as having their proposals closed. Final note, since much of the opposition was related to the mode of resolving this screen-reader compliance problem, rather than the underlying idea of addressing the problem in the first place, it's of course all right for someone interested in the discussion to formulate a new proposal without waiting for days or months to pass. Nyttend (talk) 21:27, 10 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.


  • The pile of accusations in the closer's WP:SUPERVOTE at the bottom of the RfC have all been refuted in detail. The actual canvassing to this discussion was by CBM here, in which he grossly misrepresented the nature, intent, and actual effect of the RfC's proposition, which is why the RfC had virtually no participation other than from WT:MATHS editors all making off-topic points about mathethematics, when this RfC was about WP:CONLEVEL policy and HTML specs. I don't really care, since the outcome has been slightly productive anyway; I'm just not going to let Nyttend's shipload of false WP:ASPERSIONS go unanswered.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  11:49, 12 December 2017 (UTC)
  • Productive ongoing discussions since the RfC:
 — SMcCandlish ¢ >ʌⱷ҅ʌ<  11:49, 12 December 2017 (UTC)

Is Wikipedia:WikiProject Video games/Sources a guideline?

While reviewing an RFC, one of the arguments raised assumed Wikipedia:WikiProject Video games/Sources was a legit guideline. While someone did, a long time ago, incorrectly substitute the guideline template onto it (hence no tracking cat to discover it until now), there doesn't seem to be any actual discussion about it, which leads me to believe it was never raised for greater community discussion. Maybe it's fine as-is, though, since nobody's really raised it as an issue, but I thought I'd point it out here regardless. If it actually should be a guideline, the template should probably be updated to be non-subst, the page should likely should be moved out of its Wikiproject-subpage location, and its linkages (e.g., on WP:RS, WP:LGL) should reflect its official-ness status, if applicable. If not, it should probably be (un)tagged back as an essay or similar (and obviously can be otherwise left as-is). The latter is what seems safest to assume is the default in the absence of input to the contrary. --slakrtalk / 03:06, 5 December 2017 (UTC)

No, that's a WP:PROJPAGE (wikiproject advice essay). It's way, way too full of micro-detailed instruction creep to be a guideline.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  11:26, 6 December 2017 (UTC)
Where does it contradict policy? Benjamin (talk) 19:14, 10 December 2017 (UTC)
Its nothing to do with contradicting policy. Its a wikiproject advice page on the better (or worse) sources out there. To be elevated to an actual guideline it would need all the specific 'This is reliable, this isnt' removed - as reliability is dependant on context and information used, not solely the source. It could be turned into a guideline but what you would end up with would just be a cut-down version of WP:RS. So it would be completely redundant. Only in death does duty end (talk) 12:28, 11 December 2017 (UTC)
Speaking for the VG project, we don't consider it a policy, nor an attempt to override it. But it is meant to say "in our field, these are the sources we have deemed to meet WP:RS", so that new editors know where to look for sources, and when we go to GA or FA, we can point questions about source reliability to that page. I will note that its discussion page , that's where we do determine if sources qualify or not, following the principles of WP:RS, in context of the video game industry. In any case, the top box on it was changed to be a WikiProject guideline ("essay" for all purposes). --Masem (t) 17:12, 11 December 2017 (UTC)

RfC on first contact between journalists and users

Snow oppose. TonyBallioni (talk) 17:07, 7 December 2017 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should there be a protocol governing first contact between someone stating they are a journalist and those Wikipedia users who can only be contacted via their talk page? Or are current rules clear enough to determine if such contact is permitted, prohibited, or acceptable under certain conditions? If clarification is required, what should be clarified? For example, should there be requirements for journalists to identify themselves, or their publication, or their reason for the inquiry or intended recipient/s, or go through some other qualifying process or procedure to provide assurance the contact isn't likely to cause alarm, distress or disruption to Wikipedia or its users?

This question specifically only covers the permissibility and nature of first contact with user/s, on the assumption that what happens in subsequent communications, if any, can be managed as normal. It is assumed that users will always be allowed to decline, ignore or remove any attempt at first contact, or indeed subsequent messages, and that should always be respected.

James Marshall Y (talk) 14:07, 6 December 2017 (UTC)


Comment from question setter Obviously there was a trigger incident that prompted this query, a block of a person saying they were a journalist and attempting first contact with users, but I don't think it serves anybody to focus on that one incident at the expense of considering the general case.

I have been accused many times of being the person who was blocked, so I will repeat here categorically, that I am not. Nor am I a Wikipedia user hiding their "regular account", for reasons nobody claiming it has quite explained to me would be a profitable exercise. I am here out of nothing but a desire to see the interests of bona fide journalists and wider society are represented in the internal decision making of Wikipedia, regarding future cases.

This question is intended to avoid the sort of confusion and contradictory views that have emerged since that block, over what would or should happen in a future case (which I won't repeat here, as they should be properly registered by those who advanced them). It is sufficient to note the disagreement includes Administrators, suggesting a lack of clarity in the rules. Based on all those comments, the relevant pages seem to be PAID, NOTHERE and AGF, but I can't rule out the possibility there are others, hence the question.

My own personal view is that journalism is a vital component of a healthy society, and the ability of journalists to speak to people involved in things which affect society, as Wikipedian surely does now, is a vital aspect of it - stories about Wikipedia based only on what is publicly visible on the pages of the website, will be as poor as people can surely imagine they would be if the same standard was applied to other areas of public interest.

Any barriers put in place to the initiation of first contact by the rules of Wikipedia, logically have to make sense to wider society, have to respect the principles of Wikipedia (open, transparent, welcoming), and have to trust that both journalists and the people they seek to contact are best placed to judge what sort of approach will yeild the best results or should be engaged with.

Accordingly, accepting the pre-conditions of the question, I believe it needs to be made absolutely clear in Wikipedia's rules that the mere act of calling oneself a journalist and attempting first contact, should not trigger a block, and no other qualifying conditions or expecations should be placed on them, especially not the rather bizarre idea that supposedly derives its legitimacy from NOTHERE, namely that trading access for productive effort makes any kind of sense at all.

They should also not be treated as PAID editors for the purposes of forcibly extracting further details because of their presumed profit motive, not least since journalism is increasingly a volunteer activity done for the public good, just like writing Wikipedia is. The argument that journalism is in of itself a self promotional activity, therefore must be banned outright, or limited to whitelisted persons, seems to give out the entirely wrong message.

The only justification for expecting any more details than the fact the person wants to present themselves as a journalist, is if it is determined to be justifiable as a means of preventing the aforementioned alarm, distress or disruption, which I think it is not. It is ultimately about trust and good faith, which should hold until absolute proof it is unwarranted emerges, which can only come after the first contact is made. But sufficiently detailed answers to the question should hopefully provide clarity, if I am mistaken.

I am personally quite sure Wikipedia users are well capable of not having a panic attack at hearing the words, 'hello, I am a journalist, and I was wondering if you would like to speak to me?'. And I am quite sure assuming they would, sends out the wrong message. It won't always be a lie, a scam, a carefully crafted ruse, a troll, a mischief, a trap or a sting.

Detecting and stopping these after first contact seems like an easy job when compared to the work involved in implementing the suggestions I've seen for how they could or should be prevented before first contact, in addition to the damage of the inherent presumption of guilt they carry.

There are very good reasons why a serious and responsible journalist, who often are mere bloggers in these difficult times, might not want to say anything more than that, on their first approach, as they wait to see if the user is at all receptive to an approach. Reasons that relate to their personal safety and the production of good journalism.

It seems logical to give the journalist the freedom and the choice, than assume the existence of absolutes that may not actually exist. At the very least, if it is expected further details are required, do not block first, without warning, and only then ask for them, as happened in the aforementioned incident. That is decidedly illogical, presupposing a level of threat or urgency that surely doesn't or ever would exist in such a scenario.

What happens after that first approach, seems to already be well covered by the existing rules of the website, up to and including having processes for how and when to collect and present evidence of a private, privelaged or confidential nature. James Marshall Y (talk) 14:07, 6 December 2017 (UTC)

  • Oppose per WP:CREEP. It's not an issue because it just does not happen, and the singularity of it happening needs no policy, people are here to write the encyclopedia and maintain the technology, or they are not, if they are not, they should be elsewhere. Alanscottwalker (talk) 14:19, 6 December 2017 (UTC)
  • Oppose If anything, this is perfect content for outreach:. Reciprocal pages for Wikimedians and journalists may be very useful there. ―Justin (koavf)TCM 19:32, 6 December 2017 (UTC)
  • The Wikimedia:Terms of Use apply, so strictly speaking, paid journalists must identify who is paying them. Where this could be tricky is when someone writing on spec, since no payment has occurred yet. Would a freelancer have to retroactively identify with whom their edits are affiliated, after a submission is accepted? isaacl (talk) 23:47, 6 December 2017 (UTC)
    • Upon further reflection, if the only edits made were to contact other editors to arrange discussions, since no actual content is being modified or discussed, including articles and non-articles, there is no conflict of interest issue. So although technically a disclosure is required, there is no harm in allowing anonymous contact to be made. isaacl (talk) 02:56, 7 December 2017 (UTC)
  • Oppose Ethical professional journalists are open and transparent. Anyone claiming the privilege to operate as a professional journalist and ask people questions should identify themself as a paid journalist editor, and disclose who is paying them. If they do not want to identify themself and their employers, they should limit themselves to reading articles, reading article histories and reading talk pages. They can email editors who have chosen to activate email communication. They can report whatever they want as readers, with no limits. If the journalist is working on spec and wants to question volunteer editors on Wikipedia, then they should say, with honesty, "I hope to sell this article to publications A, B and C. I have sold articles to A and B before, and C once expressed an interest in one of my articles". Complete honesty and transparency is what I expect of paid professional journalists who want to edit Wikipedia. Cullen328 Let's discuss it 05:27, 7 December 2017 (UTC)
  • No need. I've had journalists show up on my talk page before. I simply referred them to WMF communications. This is not something to get one's knickers in a knot about. One either ignores, arranges for other contact, or responds as one desires. And no, if the journalist is not touching content or recommending edits, there's no conflict of interest involved. Further, since they are not contributing to the *content* of the project - either directly or indirectly (e.g., via article talk pages), there is no requirement for them to disclose a conflict of interest, since they have none. Anything they publish would be outside of Wikipedia. There is no difference, really, between a working journalist contacting editors and working research scientists contacting editors. I've been approached by both for the same issue, and they were pretty much asking the same questions. Since both are being paid to do their work, and their intention is to publish that work outside of Wikipedia, there's really not much difference except perhaps for the nature of the "peer review". Risker (talk) 05:50, 7 December 2017 (UTC)
  • Oppose - Should a protocol be put in place, anyone can say "I am a journalist" and use that as a shield to sock, avoid scrutiny and generally troll the place. I suspect that is happening as we speak. Wikipedia is not a place to exercise the US Constitutional right to free speech. The idea is absurd. I would also echo Cullen, as anyone who is profiting in any way from the encyclopedia is expected to disclose, per the spirit of the TOU. Dennis Brown - 14:16, 7 December 2017 (UTC)
  • - Oppose - Instruction creep. Common sense should rule in every unique situation. Carrite (talk) 15:15, 7 December 2017 (UTC)
  • Another example of after-the-fact changes in status: I believe there have been long-time Wikipedia editors who have written articles about their experiences. Should they be required to place a disclosure on their user page? For most editors, there would presumably be an overlap between the decision to write an article and their editing history on Wikipedia. isaacl (talk) 15:34, 7 December 2017 (UTC)

Comment from question setter Already in just the first 24 hours, we have contradictory views over whether PAID applies, or whether contact should even be permitted (the sort of division I expected to see, based on the original incident). We also have confirmation from Risker that this is not a theoretical or ignorable issue, contact is being initiated repeatedly just in their case, which mirrors what others have said. The need for a protocol for how people avoid being blocked for the mere act of first contact, seems obvious, given the confusion. Trusting it to luck based on who happens to be around, or a belief common sense will always prevail (and journalists will be happy to wait in Wikipedia jail while their case is discussed), seems naive and irresponsible. James Marshall Y (talk) 16:32, 7 December 2017 (UTC)

  • You've shopped this all over, and the fact that you know the system and have no prior edits makes it pretty obvious that you are a sock of someone. I think we have entertained you long enough. In no venue has a consensus formed in your favor, not here, not at WPO, no where. At some point put put down the WP:STICK and get over it. Honestly, I'm shocked you haven't been blocked yet for the obvious socking, as you are either blocked in your other account (likely) or at a minimum, evading scrutiny. Dennis Brown - 16:47, 7 December 2017 (UTC)
  • Snow close - There is unanimous opposition to this, and even if there was overwhelming support, the question is sufficiently broad for there to be nothing to gain outside a vague feeling that we should formulate some undefined solution to some nebulous problem. Someone save us the trouble of carrying this on any further please. GMGtalk 17:01, 7 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: Russian metro line article titles

The section was named "Russian railway line article titles" when the first users started to comment. I hate to open yet another railway RfC (why is that topic area so fraught with dispute?) but move-warring has broken out and it needs to stop. How should articles on railway lines in Russia be titled?:  — SMcCandlish ¢ >ʌⱷ҅ʌ<  04:11, 9 December 2017 (UTC)

Topic Option A Option B Option C Option D
Description En dash and lowercase "line" Hyphen and uppercase "Line" En dash, but uppercase Hyphen but lowercase
Example line Kalininsko–Solntsevskaya line Kalininsko-Solntsevskaya Line Kalininsko–Solntsevskaya Line Kalininsko-Solntsevskaya line
Example station Aviamotornaya (Kalininsko–Solntsevskaya line) Aviamotornaya (Kalininsko-Solntsevskaya Line) Aviamotornaya (Kalininsko–Solntsevskaya Line) Aviamotornaya (Kalininsko-Solntsevskaya line)

Comments on Russian metro lines

  • Use option A per WP:CONSISTENCY, MOS:DASH, MOS:CAPS, and WP:USEENGLISH. What the official name looks like in Russian bureaucratese is irrelevant on English Wikipedia, since English and Russian do not have the same punctuation and capitalization practices, nor do signage and encyclopedic writing, even in the same language. The English title of our article is a translated approximation of the name in Russian, and is subject to English orthography and to Wikipedia's title policy and its naming and style guidelines. Option B is wrong twice over, and options C and D are just pointless mishmash, listed only for completeness.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  04:11, 9 December 2017 (UTC)
Second Avenue Subway, BMT Fourth Avenue Line (more at Category:New York City Subway lines); Washington County, Sixth Avenue (more at Category:Streets in Manhattan). Who claims WP:CONSISTENCY and promotes an option that reduces consistency? Ping User:Dicklyon. (talk) 00:18, 10 December 2017 (UTC)
Ah, you noticed some New Yorkers can be pretty stubborn, too. See Talk:IRT Lexington Avenue Line#Requested move 17 November 2017 where I failed to find a consensus in spite of the guidelines and evidence. Shit happens. As for street names, those became consistently treated as proper names (in the US at least) over 100 years ago. Counties, too. Lines, not. Dicklyon (talk) 00:26, 10 December 2017 (UTC)
Dicklyon could you compile a list and add evidence? Do you have more examples for lower case apart from lines? How is the distribution, e.g. [] has "Picadilly Line", a UK website, about a UK line. (talk) 00:50, 10 December 2017 (UTC)
Like many things, London Underground names are sometimes capped in sources. I believe the UK Trains project looked at that specifically and decided that all those would use lowercase line, hence Piccadilly line. See Wikipedia:WikiProject London/Naming conventions#Transport. And no, I'm not going to compile a list (of what?). Dicklyon (talk) 01:02, 10 December 2017 (UTC)
Dicklyon you claimed "Counties, too. Lines, not." but refuse "I'm not going to compile a list". So, what to do with a claim without proof? I gave an an example for X Line, but then you refer it to a UK WP project. Good to see double standard, WP:RUSSIA not allowed to handle things by its own. (talk) 01:12, 10 December 2017 (UTC)
Well, it's not that simple. The London folks make their lines and stations MOS compliant a long time ago (2007?); but it was a recent big mess to convince the UK Railways project; see the archives of Wikipedia talk:WikiProject UK Railways for all the dirt on me that you want. We had a big to-do about similar problems in China recently, though it actually went easier; moved about 1600 "Xxx Railway Station" to "Xxx railway station" with the help of a bot after getting consensus that it was OK noncontroversial. Your situation should be similar, I think. Bottom line, there's a general consensus, usually, that we should follow our house style, not let wikiprojects make up conflicting styles. This still leaves them considerable latitude on titling and disambiguating conventions, as you see what's going on now in Taiwan and Iran discussions. Dicklyon (talk) 01:23, 10 December 2017 (UTC)
  • I agree with SMcCandlish on this matter. Tony (talk) 05:32, 9 December 2017 (UTC)
User:Tony1: Second Avenue Subway, BMT Fourth Avenue Line more at Category:New York City Subway lines. How would changing titles of articles about Moscow Metro lines to use lower case increase WP:CONSISTENCY? (talk) 00:20, 10 December 2017 (UTC)
  • A obviously is the WP MOS way. Take a look at Kalininsko-Solntsevskaya Line which in it's Sept. 2005 state said "The Kalininskaya is a line of the Moscow Metro. Today it is the only line to be named after a figurehead instead of the areas that it connects." This makes it pretty clear that all (or nearly all?) of the Moscow metro lines are named for places they connect, like many other lines in most other cities and countries and metro systems; the en dash is clearly the right punctuation for connecting the two place or direction names, while the hyphen makes no sense. In Russian orthography, I expect things are different, and it's OK to use the hyphen in the Russian. And the capped "Line" came to this article in December 2005. Not too surprising to see overcapping this old, but that's not a reason to avoid fixing it. It's not capped in the Russian, so not clear why anyone thought that was a good idea in English; most likely it was done originally, back in the day, by someone unaware of WP:NCCAPS. There's work involved to fix all this, but it's not a big problem compared to some others we've fixed this year, so let's get started. Dicklyon (talk) 06:00, 9 December 2017 (UTC)
Comment the comment "This makes it pretty clear that all (or nearly all?) of the Moscow metro lines are named for places they connect" - makes it pretty clear that the author uses false information. Koltsevaya Line, Moscow Monorail, Moscow Central Circle, Third Interchange Contour. No, it's not like Beijing–Shanghai Railway where the two items connected by "–" mark the end points of a line. Several lines have been extended without any name change. Propsers have no clue and should leave it to WP:RUSSIA92.231.182.37 (talk) 06:26, 9 December 2017 (UTC)
Sorry, I intend the scope of my comment to be the metro lines with hyphens in their titles. I stand corrected. And no I did not suggest that the places named would necessarily be at the ends of a line, though that's common in many systems, at least ones that aren't growing. Dicklyon (talk) 06:42, 9 December 2017 (UTC)
  • A ticks the most MOS boxes and IMO should be treated as a de facto standard format. Jasphetamine (talk) 10:44, 14 December 2017 (UTC)
  • Oppose:
  1. Procedural
    1. Should be taken to WP:RUSSIA because the editors of that project are the ones that do the actual work. Cannot find any improvement by User:SMcCandlish, User:Tony1 to the actual content. Will they do the maybe 100 000 edits that are needed to convert all occurences visible to the reader? (talk) 06:10, 9 December 2017 (UTC)
    2. Status quo (Option B) is not presented fairly, was written by user that supports Option A. Also why would the current naming be put at "B"? That's no neutral representation.
  2. Policies
    1. MOS:DASH - fine, see Guinea-Bissau, "-" is allowed. No, it's not like Beijing–Shanghai Railway where the two items connected by "–" mark the end points of a line. Several lines containing "-" in the name have been extended without any name change.
    2. WP:CONSISTENCY - WP:RUSSIA has Moscow Oblast, Shatursky District, Central Administrative Okrug, Varshavskoye Highway, Mira Avenue, Mokhovaya Street, Cosmonauts Alley, Chistoprudny Boulevard, Boulevard Ring, Nakhimovsky Prospekt, Sivtsev Vrazhek Lane, Lefortovo Tunnel, Moskvoretskaya Embankment, Moscow Ring Road, German Quarter, Vodootvodny Canal, Arbatskaya Square (Red Square too), Tsar Cannon, Chudov Monastery, State Kremlin Palace, Alexander Garden, Kremlin Arsenal, Spasskaya Tower, Bagration Bridge, Donskoye Cemetery, Bolshoi Theatre, Vnukovo International Airport, Nekrasov Library, Cosmos Hotel, Rumyantsev Museum
    3. MOS:CAPS - all fine.
    4. WP:USEENGLISH - the titles are already English. (talk) 06:10, 9 December 2017 (UTC)
A detailed response to this has been posted in #Extended discussion of Russian railways, below.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:48, 9 December 2017 (UTC)
  • I can support Option A per Dicklyon. It looks like it ties out to what is used for lines in other systems. Some of the stuff that got ported over to English ended up with some odd variations. There are a few that I’ve been meaning to get to myself. I can certainly help with some of the work on this if you need it. TastyPoutine talk (if you dare) 06:30, 9 December 2017 (UTC)
  • Option A per WP:CONSISTENCY and WP:USEENGLISH. It would be just too unsightly and confusion to change the articles titles to something that is inconsistent with related articles. It would also fall out of line with the manual of styles linked above to change them. Boomer VialHappy Holidays!Contribs 06:38, 9 December 2017 (UTC)
  • Follow the sources. The entire discussion seems irrelevant navel-gazing. What do reliable sources use? Wikipedia's policy is to always do what reliable English-language sources do, if they exist. What do Moscow travel guides use? As reliable sources about different topics often use different conventions, Wikipedia is not internally consistent (and that is not a particularly worthwhile goal anyway). —Kusma (t·c) 11:22, 9 December 2017 (UTC)
@Kusma: this is a common misapprehension. We do not always follow the styles used in reliable English language sources, for a number of reasons: like other publications, we have our own style rules embodied in the Manual of Style; reliable sources are of different kinds, some more specialized than others, and we take into account those that are appropriate for a general encyclopedia. Peter coxhead (talk) 11:33, 9 December 2017 (UTC)
Of course, our rules are not fixed in stone and can be changed (if there is consensus to do so)... there are a lot of editors who think our MOS rule should be changed to “follow the sources”. Don’t know if it is a majority of editors who think that... but if not, it is a sizable minority. Blueboar (talk) 11:57, 9 December 2017 (UTC)
A response to this has been posted in #Extended discussion of Russian railways, below.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  12:24, 9 December 2017 (UTC)
Sourcing tends to be all over the place. Just as in some cases, there isn’t consistency in transliterating Russian, you also don’t get consistency in this matter. The Metro itself uses lowercase [22] while TASS uses an uppercase [23]. For what it’s worth, TASS also called the Koltsevaya Line the Circle Line which is probably correct since Koltsevaya in Russian is meant to be descriptive. But that’s a fight with another IP editor for another day. In any case, even the Moscow Times which is one of your best local sources isn’t particularly consistent (lowercase [24]) and (uppercase [25]) The New York Times wavers between the colloquial name with uppercase [26] and the official name with lowercase [27]. So in that case, my guess would be that the MOS is the best guide. TastyPoutine talk (if you dare) 13:35, 9 December 2017 (UTC)
Thank you TastyPoutine. To add a not particularly RS: the English translation of Metro 2033 uses both "Red Line" and "Sokolnicheskaya line". In the absence of a strong argument that points in a different direction, lowercase "line" probably works best, although if a different convention has been in place for years, I see no particularly good reason to change that. —Kusma (t·c) 19:23, 9 December 2017 (UTC)
I would put it out there that it may be worth making effort to change. Articles that got ported over from foreign languages were pretty inconsistently set up and it’s probably better to get it right than settle into inertia. Something written a decade ago likely set it but without a good MoS and did their best. And the extensiveness of the system makes it difficult to make wholesale change. But if we can, I think wwe should make the right change now and move on.TastyPoutine talk (if you dare) 20:02, 9 December 2017 (UTC)
  • Comment Option B is used since 2005 [28] (talk) 17:11, 9 December 2017 (UTC)
    I presume you are the same as the dynamic IP who made the big "Oppose" section above, which I interpret as a vote for B. It would be better to clarify there than to vote again. Dicklyon (talk) 19:18, 9 December 2017 (UTC)
    Dicklyon, statement by says "Comment", which is not a vote. And it does not even endorse any of the options, only adds a new finding in chronological order, so all voters before might have been under-informed. (talk) 23:49, 9 December 2017 (UTC)
    Since the anon is now pretending to be different editors, I've taken this to WP:SPI.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:04, 10 December 2017 (UTC)
    User:SMcCandlish claims the untrue. Where did anyone here claim to "to be different editors"? (talk) 05:19, 13 December 2017 (UTC)
    Covered at the SPI report; VPPOL is not the place for this discussion.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  05:24, 13 December 2017 (UTC)
    User:SMcCandlish - VPPOL was the place where you made a claim regarding an activity that occurred here. Now you refuse to show the evidence. Did User:SMcCandlish lie? Where is the diff of the SPI where you cover that? (talk) 05:42, 13 December 2017 (UTC)
    Take it to the right venue. See also WP:Tendentious editing; repeating demands after your told they're off topic doesn't make them on-topic.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  05:59, 13 December 2017 (UTC)
    Thanks for pointing out that Arbatsko-Pokrovskaya Line that's been capped since 2005. As you can see in books, sources often call it "Arbatsko-Pokrovskaya line" with lowercase line. It is not near the usual threshold of "consistently capitalized in sources" that we use to determine proper names. Dicklyon (talk) 05:25, 10 December 2017 (UTC)

Extended commentary by anon with multiple IP addresses

Comments regarding MOS:DASH

MOS:DASH lists Guinea-Bissau, so "-" is allowed. The "-" in the Moscow Metro articles are not connectors like Beijing–Shanghai Railway where the two items connected by "–" mark the end points of a line. Several lines containing "-" in the name have been extended without any name change. (talk) 06:45, 9 December 2017 (UTC)

Comments regarding WP:CONSISTENCY

WP:RUSSIA consistently uses the type name in upper case:

The content is consistent as it is. All Moscow Metro lines are named consistently. Hundreds of pages contain the line names. (talk) 06:45, 9 December 2017 (UTC)

Also outside Russia many items use upper case. Even rail lines: Second Avenue Subway and all the lines in Category:New York City Subway lines. (talk) 23:55, 9 December 2017 (UTC)

Comments regarding WP:USEENGLISH

WP:USEENGLISH - the titles are already English. They are perfect English. (talk) 06:45, 9 December 2017 (UTC)

They are as English as possible : NYC's BMT Fourth Avenue Line, Moscow's Filyovskaya Line. (talk) 23:57, 9 December 2017 (UTC)

Comments regarding MOS:CAPS

MOS:CAPS does not prohibit capitalization of proper names. MOS:NAMECAPS explicitly allows it. (talk)

Extended discussion of Russian metro lines

  • This discussion has been "advertised" to WT:AT, WT:NCCAPS, WT:USEENGLISH, WT:MOS, WT:MOSCAPS, WT:TRAINS, and WT:RUSSIA. The "WP:Naming conventions (Russia)" page is an old draft abandoned around 2011, so I skipped that; no one uses its talk page.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  04:36, 9 December 2017 (UTC)
  • Response to the anon's long block of FUD up there: This is not a "support" or "oppose" RfC; its a four-way multiple choice. Option B is not the status quo ante; they were at totally different names until you (at a different IP address) moved them [29] just over a day ago. And, no, it will not be taken to WT:RUSSIA (which has already been notified of this RfC). The entire point of WP:Village pump is to get broad editorial input, to assess actual site-wide consensus and avoid a bloc vote by an insular wikiproject or other knot of editors apt to produce a WP:FALSECONSENSUS. This was already explained to you at RM/TR, so I have to wonder why you're pretending it was not and are recycling the same "I want this on my turf" argument when you already know that is not going to fly.

    To address your various policy mis-citations: MOS:DASH: Guinea-Bissau is a single place, it is not a construction expressive of a relationship linking two different places the way Kalininsko–Solntsevskaya line does. WP:CONSISTENCY is a site-wide policy; it does not mean "make articles on my favorite topic consistent with each other but inconsistent with those on all the other topics just for the hell of it". MOS:CAPS: if "all fine", why are you back at RM tendentiously and falsely pushing more of the same moves as "non-controversial" [30]? USEENGLISH: Yes, these titles are in English, which means they follow English-language norms, not Russian ones. That's the entire point.

    PS: Option B is written accurately, based on the exact justifications that you (at yet another IP address) offered at RM/TR [31]: because the Russians, in their language, use a hyphen and capitalize (according to you, anyway; even that has not been verified yet, but is irrelevant).
     — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:47, 9 December 2017 (UTC)

  • Response to Blueboar and Kusma: "Follow the sources" already is the rule, just applied in a common sense manner. MoS is based on major style guides, ironing out where they conflict. Beyond that, an unusual stylization (i.e. which doesn't match what MoS says to do based on what mainstream style guides in print say to do) is permissible here if it's used consistently in a sizable majority of reliable sources. Unless I'm sorely misremembering, you brokered that codicil yourself, Blueboar, so it's weird to me to see you acting here today like it's not in place. You and Kusma and a handful of others (not a large minority, or MoS probably would no longer exist) seem to want style at every article to follow the style used in specialist material for the topic on question. That's never going to happen for various reasons, the most obvious of which are: A) Music-journalism writing about rock stars and physics-journal writing about cosmology [and so on] use styles that are not appropriate for encyclopedic writing. B) Sources reliable for specialized facts about a topic are not reliable for how to best write English (unless they're coincidentally sources specialized about how to best write English, such as reputably published style guides). C) Few topics are the exclusive subject of a single specialized field, and different fields use different styles, so a unified MoS becomes inevitable if for no other reason that to stop specialists in different fields from fighting over style. That's how and why MoS arose in the first place, less than a year after WP was started, because the squabbling was already intolerably disruptive by then. Publishers have style guides for a reason.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  12:29, 9 December 2017 (UTC)
    @SMcCandlish: Indeed consistency of style across all of Wikipedia is not an achievable or even worthy goal. (WP:ENGVAR/MOS:RETAIN is one of our traditional rules in this regard, which achieves peace without enforcing consistency between articles). With respect to article titles, following the sources appropriate for the field is what we have done for years. Mao Zedong and Go Seigen and Shiing-Shen Chern and Chiang Kai-shek and Samuel C. C. Ting are five articles about Chinese people alive during the 20th century following five different and wildly inconsistent conventions for their name order, romanisation, language use, capitalisation and hyphenation. Each of them is at the correct title per Wikipedia:Naming conventions (use English). Legislating a consistent style for foreign topics against the evidence of scholarly publications just does not work. It is to Wikipedia's detriment to force people to use conventions against those correct in the article subject: it drives experts away and makes articles inconsistent with their sources. "Consistency" isn't worth that. So again, are there any relevant publications about Russian railways in English and what style do they use? —Kusma (t·c) 19:04, 9 December 2017 (UTC)
    Note that the discussion is not even about railways (which in Russia never use "line" or "Line" anyway), but specifically about metro (mainly Moscow Metro, though it will apply as well to other four cities which have more than one metro line).--Ymblanter (talk) 19:31, 9 December 2017 (UTC)
    The wording has been fixed.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  04:44, 12 December 2017 (UTC)
    Kusma, all you're doing is demonstrating my point for me. We do in fact have standard naming conventions for Chinese people (see WP:NCCHINA#Names of people); there are variations from it precisely because in those cases the bulk of the RS consistently do something different – and the same different thing – for those specific individuals. And if you think MoS's primary purpose is not cross-article consistency, you're not thinking about it very hard. If that were true we would need not a style guide at all, and it would simply be left to every wikiproject or even every random cluster of editors at every article to decide topic-by-topic on all style matters. We tried that in WP's first year and it was a disaster.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  05:11, 10 December 2017 (UTC)
    The question is always when we should follow the sources instead of our standards. Our difference seems to be that I think in cases of doubt, we should follow the sources. You seem to say in cases of doubt, we should impose some arbitrary standard. And indeed I agree that some sort of style guide, describing Wikipedia's common practice, is useful. However, I object to your characterisation of the MoS as saving Wikipedia from a "disaster" in its first year. I have admittedly not been here for Wikipedia's first year, but in the last thirteen years, the MoS has been a source of constant bickering that has created several ArbCom cases. The date unlinking debate alone led to millions of edits and thousands of hours of editor time that were used without a measurable overall improvement to Wikipedia. Infobox and citation style debates have cost us many good editors. It may look different from your end, but I have not perceived editors enforcing "standards" through the MOS to be a positive for Wikipedia: sometimes the net result is almost neutral (because the difference between "Line" and "line" is minuscule), sometimes negative (good editors gives up). —Kusma (t·c) 10:24, 10 December 2017 (UTC)
    It's not really clear what you're thinking when you say "follow the sources" in "cases of doubt". When sources are clear, we do follow them, as MOS:CAPS advises. When they're not, we default to our style (lowercase when it's not clear that sources treat the term as a proper name). Have you looked at sources on these metro lines? I have, and there's an awful lot of lowercase line there. In particular, see books like The Rough Guide to Moscow, Lonely Planet Moscow, and most fiction works that talk about Moscow metro lines, all with lowercase line. Dicklyon (talk) 17:29, 10 December 2017 (UTC)
    Kusma's anti-MoS fingerpointing is in the wrong direction anyway, on all counts (though see below for the spirit of the matter, which Kusma seems to intuit without realizing our guidelines are the solution not the problem).
    1. WP:NCCAPS, which is really the guideline central to these rail and metro moves, isn't part of MoS, but a subsidiary guideline of WP:AT policy. (It is and should be consistent with MOS:CAPS, of course, or we'd have a WP:POLICYFORK and conflicts between article titles and body text).
    2. The date auto-linking fiasco was caused by the MediaWiki developers deploying a problematic "feature" that did not work well here; MoS didn't cause that. (And it's not unique – similar disputes have erupted about WP:Flow, WP:Visual editor, and many other WMF technical debacles, like doing visual indentation with <dd> markup). There was an ArbCom case about date delinking in 2009 because certain individuals were engaging in uncivil behavior over the matter. ArbCom does not settle content disputes or write policy; "there was an ArbCom case" just means "certain editors were accused of being jerks". The end result of the de-linking (which the community decided in a series of RfCs and polls – not ArbCom, not MoS regulars) was obviously a net positive for the project, in getting rid of a problematic mess over which people were uncivilly squabbling, while reducing the pointless "sea of blue" overlinking effect our readers were being subjected to for no encyclopedic reason.
    3. MoS is entirely neutral on infoboxes, and leaves their inclusion up to editorial discretion at each article (see WP:INFOBOXUSE). People get into emotional infobox-related fights for MoS-unrelated reasons (and arguably WP-unrelated ones, to do with personal philosophies of information architecture and Web design "elegance"). Quitting in a huff after getting too emotionally invested in fighting about infoboxes (or any other trivial dispute) is a WP:CIR matter, not a policy problem.
    4. Citation style is covered by WP:CITE, which is not part of MoS. While I agree that disputation about citation style has frequently been disruptive, it has nothing to do with MoS. (MoS, including MOS:DATE, expectations are of course applied to citation content, when doing so does not directly conflict with a specific citation style that's used consistently in an article.)
    5. The other partly-MoS-related ArbCom case, in 2012, concerned incivility at WT:AT and WT:MOS in disputes about the wording of that policy and guideline (respectively) – just another editorial behavior matter, which could as easily have been about Pokemon or fungi. When ArbCom was asked last year if it considered the issue broad enough to apply to title and style discussions more generally (e.g. RMs, and RfCs like this one) it explicitly denied that expanded scope interpretation.
    "MoS has been a source of constant bickering that has created several ArbCom cases" simply isn't true; it's like blaming "the gov'ment" for all one's problems. Kusma's central concern, once the mis-blaming of MoS is cleared away, amounts to "people shouldn't bicker over stylistic trivia", which is true and good. MoS has eliminated the vast majority of style-related bickering that used to plague the project, article by article over the same trivia again and again; the handful of ArbCom cases were triggered by a few individuals who persisted in uncivil bickering. The most common "style" squabbling that recurs is actually over AT and NC, not MoS, matters (though citation to MoS often resolves them, because its applicability is so generalized and AT is not a style policy).

    Yes, "line" versus "Line" is trivial; continual disruptive bickering about it is not a trivial problem. The very fact that people will sometimes engage in it doggedly is why we need RfCs and naming conventions and style guidelines, to settle the question consistently and move on. Otherwise the same tedious dispute will still be happening in 2020 and in 2025. See also previous RfC on this page that closed a week or so ago in favor of developing something along the line of a MOS:TRANSPORT guideline; this RfC is another step toward that prescribed goal.
     — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:42, 12 December 2017 (UTC)



As some mention below, this is more about metro lines than railways. I propose that to keep the noise down we limit to titles that come from Cyrillic titles such as "Святошинсько-Броварська лінія" which is now at Sviatoshynsko-Brovarska Line which is a line in the Kiev Metro in Ukraine (that is, not limit to Russia, but limit to such place-descriptive metro lines for now). This will reduce the fear of over-generalization, and we can discuss generalizations to other things elsewhere. Dicklyon (talk) 20:24, 9 December 2017 (UTC)

Quoting Ymblanter (19:31, 9 December 2017): "Note that the discussion is not even about railways (which in Russia never use "line" or "Line" anyway), but specifically about metro (mainly Moscow Metro, though it will apply as well to other four cities which have more than one metro line)." - Spasibo Yaroslav! I agree with Dicklyon that it should be consistent with Kiev Metro. It should be consistent accross with Minsk Metro too. And also with systems outside the capitals. (talk) 00:35, 10 December 2017 (UTC)
  • Section headings updated to reflect narrower scope. The original section names are preserved with anchors, so links don't break.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  04:40, 12 December 2017 (UTC)


I wouldn't quite agree with SMcCandlish that move warring has broken out, but we do need to hash this out, again, apparently. An editor changed some disambiguators (not changing the caps and dash issues, but bringing them to my attention at WP:RMTR). So I moved a few things to conform with normal style. He asked for a revert of those moves, at WP:RMTR. The admin who did (part of) what he asked unfortunately made a mistake and overwrote a line article with a station article somehow before going off for the evening. Another admin saw the requests still there, now with SMcCandlish's objections, and tried to finish up, without noticing the problem. It's still a mess. We'll get it sorted, maybe not today. So it's a good thing SMcCandlish didn't provide a link to the line article, because it would just confuse by taking you to the station article (this is since fixed). Nevermind, back to the real issue. Dicklyon (talk) 05:38, 9 December 2017 (UTC)

User:Dicklyon, and who did actual work on the articles? None of you. You both come in, move some pages around and everywhere else the year-old naming system persists. (talk) 07:01, 9 December 2017 (UTC)
I had every intention of doing a lot more work there, but that got put on hold by your move revert request. I'll get back to it later, I expect. Dicklyon (talk) 07:18, 9 December 2017 (UTC)
User:Dicklyon, how would you ensure all occurrences visible to reader are changed? What tool is there to list all occurences to be done? (talk) 07:40, 9 December 2017 (UTC)
That would be so awesome! We do still have widespread visible linking through wongly styled redirects, with over-capitalization, missing hyphens, hyphens for dashes, etc., throughout the en.wp, and a tool that replaces those with the preferred-styling title would be great. I've recently had some luck getting bot operators to do some large-scale moves, for downcasing railway station in China and a few other places for example, so I think there's hope for such things on specific subsets, and I'm willing to give that a try in the Moscow metro case, and then see from there. Lacking such tool support, I find that getting the titles styled right first is a big help; then getting templates updated will typically fix the majority of appearances of wrongly styled titles. So a little manual work goes a long way. Want to help? Dicklyon (talk) 19:26, 9 December 2017 (UTC)
Dicklyon, it's not about templates, that's easy. "then getting templates updated will typically fix the majority of appearances of wrongly styled titles" - no, the problem is plain text. Without tool support it will take years, just look at districts and divisions of India. Several years ago five or so users decided to use "X district" where all of Wikipedia elsewhere uses "X District". And they still don't have it done fully. Why not help and create articles for the Line 11 several red links still exist.. ? I also see no consistency, some rail lines are singled out and many other things still have the type name capitalized, Mississippi River, Sixth Avenue (Manhattan). It should be done consistently for all things, only to do it for some classes (e.g. rail lines) is creating inconsistency. (talk) 23:45, 9 December 2017 (UTC)
  • User:Dicklyon claimed "So I moved a few things to conform with normal style.". But provides no evidence for his normal style. Normal style for many other subway and transport infratructure articles is to use upper case. Second Avenue Subway (Category:New York City Subway lines), Sixth Avenue (Category:Streets in Manhattan). Maybe move war there has no chance, so Moscow / Eurasia was selected? (talk) 00:28, 10 December 2017 (UTC)
    I've been doing a lot of style work (using WP:MOS to define "normal style") on railway related articles around the world, as I find them. Recently a lot in China, Philippines, Malaysia, Vietnam, Australia; before that the whole of the UK, which was more of a challenge; it's true I haven't had much luck with the NYC subway folks yet, and recently lost a multi-RM there, so bummer. I had no plan to take on Russia, but your moves showed up at WP:RMTR, just too late for me to contest. Dicklyon (talk) 04:58, 10 December 2017 (UTC)
    How else would you capitalize Sixth Avenue? In US usage the "road type" words in street names are always capitalized ("Center Street", "Main Avenue", "Park Lane", and so on). They are proper names. "Sixth avenue" would be as nonsensical as "Jimmy stewart". --Khajidha (talk) 17:02, 13 December 2017 (UTC)
    PS - this also applies to your point about rivers. In the US many (possibly most rivers) are named "________ River". The word "river" is not some sort of type marker or disambiguation, it is part of the proper name. --Khajidha (talk) 17:10, 13 December 2017 (UTC)
Collapsing a dispute which has been mooted.

Error in the question's premise

Moot: The Russian-language-related wording no longer appears in the RfC question or table.

SMcCandlish's proposed option B, described as Hyphen and uppercase "Line" to mimic the WP:OFFICIALNAME in Russian Cyrillic is supposed to represent the status quo, and it pretty much does, but with the false premise that the Russian does it this way. In all Russian sources and Russian wikipedia, line is lowercase "ли́ния" or "линия".

Furthermore, the justification for the hyphen can be found in some of the line article histories as "easier to type", when the articles were moved back from the en dash after a move "per MOS:DASH"; nothing about official, Russian, or Cyrillic in that reason.

A couple of IPs (perhaps the same person) have told me that the capped "Line" is a "year-old consensus". Not clear why or where that happened. So not clear what a vote for B would mean, but I'm sure people will explain their choices. Dicklyon (talk) 05:38, 9 December 2017 (UTC)

  • Option "B" has been framed by a person supporting Option A. Not trustworthy at all. The "mimic" stuff is nonsense. Uppercase exists due to WP:CONSISTENCY (talk) 06:12, 9 December 2017 (UTC)
  • As noted in my response to the anon, option B was drafted on the basis of the anon's own claims. Whether the underling premise is true I did not investigate, but it doesn't matter, since the idea that we'd write English to match Russian orthography is nonsensical to begin with.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:00, 9 December 2017 (UTC)
    User:SMcCandlish is saying the untrue. Nowhere was it suggested that uppercase is done in Russian Cyrillic for "line". (talk) 07:04, 9 December 2017 (UTC)
    I agree. He misinterpreted your statement "all metro lines in Russia use upper case type name ("X Line")" as being about in Russian, but you meant in en.wp titles. Still, my point, on which I agree with SMcCandlish, is that there's no logical basis for the status quo as represented in option B. It's just how it is now, which I think is what you were saying, too. Dicklyon (talk) 07:18, 9 December 2017 (UTC)
Dicklyon, you claim "there's no logical basis for the status quo". But several have been given. 1) It is all consistent, the page movers will not fix it in all articles. Or is there a tool to control that? 2) It is consistent with bridges, roads, airports, lakes, districts, towers, palaces, etc in Russia. See Wikipedia:Village_pump (policy)#Comments regarding WP:CONSISTENCY and comment there. Present your logic. 3) "-" is not used to connect end points. Comment at Wikipedia:Village pump (policy)#Comments regarding MOS:DASH. (talk) 07:36, 9 December 2017 (UTC)
This is the third time this anon has called me a liar in this discussion (here and at RM/TR). Adding that to the ANI material. I did not lie at all: Here's a direct quote of the anon's actual statement in the original RM mess: 'all metro lines in Russia use upper case type name ("X Line") and use "-" as in Russian source, these are proper names'. That's an [ungrammatical] two-part claim about Russian-language sources. If the anon meant to say "All WP articles about metro lines in Russia use upper case type name ("X Line"), for no particular reason. Our article titles also use "-" as in Russian sources.', that would be a very different statement. The anon is in fact back-pedalling from an incorrect statement; the "these are proper names" bit demonstrates that, since being proper names would be an argument for capitalization but would have nothing to do with hyphen versus en dash. So, nice try, but no.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:44, 9 December 2017 (UTC)
User:SMcCandlish is saying the untrue once again. He was not called a liar here. It was simply stated that "User:SMcCandlish is saying the untrue." (talk) 07:53, 9 December 2017 (UTC)
Don't be so quick to say he's calling you a liar, just because he says what you're saying is untrue. Consider the Russian capitalization rule, which I just looked up myself: "In compound proper names, as a rule, only the first member is capitalized: Чёрное море – Black Sea". So the lowercase линия actually gives no indication one way or the other about whether it's part of a proper name or not. I still say it's not, and maybe he is saying what you thought about the Russian, but it's not true he's claiming that that word would be capped in Russian. Anyway, no matter, things like "Xxx line" are not usually treated as a proper name in English (and Moscow oblast is only half the time, so we should probably downcase those, too), and the various things that are treated as proper names in English, like bridges and streets, are not relevant. Dicklyon (talk) 07:56, 9 December 2017 (UTC)
Dicklyon, if you want to lower case type names of territorial entities you can start with Washington County. Note that CMOS suggests upper case, and that is what English WP does - everywhere except for India. Also, if the type name is not part of the proper name, then shouldn't it go into "()"? (talk) 08:07, 9 December 2017 (UTC)
Not comparable cases, and no it wouldn't go in parentheses if natural disambiguation is available; see WP:ATDAB policy.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:21, 9 December 2017 (UTC)
Here's the anon explicitly calling me a liar, twice: [32][33]. See also WP:ASPERSIONS and WP:SANCTIONGAMING. One can't go around accusing people of dishonesty and then claim one isn't doing that simply because one used, in two instances, a different word than "liar". Changing one's IP address isn't going to fool anyone, either.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:21, 9 December 2017 (UTC)
User:SMcCandlish is claiming the untrue once again. "Here's the anon explicitly calling me a liar, twice" 1) [34] does not contain the word "liar". It makes a claim about what would be a lie (It's a lie if the opposer claims that "X Line" and use of "-" has been started by IP requests "only just over a day ago"."), and then, after the other party does not pull back from the false statement about "Line", it is sure that he sticks to the lie. But there is no claim that the whole person is a liar. 2) [35] the diff does not contain the word "lie" nor "liar". It says "is saying the untrue", but that does not constitute lying. ... Now, "explicitly calling me a liar, twice" is just a false claim. It's a libel. (talk) 05:52, 10 December 2017 (UTC)
See WP:SANCTIONGAMING and WP:No legal threats. Probably also First law of holes.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:20, 10 December 2017 (UTC)
Collapsing another dispute which has been mooted.

RfC misrepresentation

Moot: Later parties have removed the statements in question and restored the RfC to wording similar to that with which it started.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  04:50, 10 December 2017 (UTC)

At least three things the anon changed in the RfC's wording are mispresentation of the intent and meaning of this RfC, of WP policies and guidelines, and of actual practice. It's pure FUD.

  1. Third Interchange Contour would not be "Third interchange contour" in option A, because it's a proper name, not a description. This RfC is not about anything other than the word "line" in descriptive titles of WP articles on railway lines.
  2. Moscow Monorail – Ditto. These bogus examples have been inserted as straw man and argument to emotion tactics to scare editors away from option A, which would not actually result in the titles the anon claims.
  3. The entire option B "reasoning" block – inserted after removal of most of the reasoning for option A by the same editor – is not a neutral statement but just one person's pleading and "evidence" presentation, a restatement of their !vote. And none of it aligns with reality; this is the anon arguing how they wished things were. A style that a handful of people made up in a wikiproject about a year ago – either without bothering to consult the titles policy and naming and style guides, or directly conflicting with them on purpose – is not "long-standing", but a recently introduced conflict of a WP:PROJPAGE essay with much longer-established WP:P&G material (see WP:POLICYFORK). "I can find some other 'Line' cases" = WP:OTHERCRAPEXISTS; it's just stuff we've not cleaned up yet.

 — SMcCandlish ¢ >ʌⱷ҅ʌ<  09:49, 9 December 2017 (UTC)

User:SMcCandlish claims the untrue: "A style that a handful of people made up in a wikiproject about a year ago" ... See 2005 version of Arbatsko-Pokrovskaya Line (talk) 17:08, 9 December 2017 (UTC)

Again, he probably mis-interpreted your phrase "year-old" as meaning about a year ago. Probably you meant "years-old". I agree the over-capitalization is very old there. Dicklyon (talk) 19:10, 9 December 2017 (UTC)
Just for the record: If that's the case then it again is not me misinterpreting anything, it's the anon writing one thing then later claiming a different meaning. (Anon also made the same singular-year claim here.) This sort of equivocation has been happening with that editor throughout the discussion.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  04:53, 10 December 2017 (UTC)
User:SMcCandlish - you are again claiming the untrue. [36] "Hyphen and uppercase "Line" to mimic the WP:OFFICIALNAME in Russian Cyrillic" - Russian Cyrillic has no uppercase "Line". And that was never claimed to be so. Re your "A style that a handful of people made up in a wikiproject about a year ago" - it's simply not true. IP made no such claim. IP did not claim "handful" nor "about a year ago". IP didn't define the number of years. [] (talk) 05:33, 10 December 2017 (UTC)
Attempting to disprove equivocation with more equivocation is not a good tactic.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:19, 10 December 2017 (UTC)
User:Dicklyon you claim, but don't prove. There is no "over-capitalization". It is only "over-capitalization" in your mind and that of some others. It's common practice to capitalize, it is a question of style: Second Avenue Subway and all the lines in Category:New York City Subway lines. Both ways are possible. (talk) 23:33, 9 December 2017 (UTC)
It's overcapitalization according to WP:NCCAPS and MOS:CAPS. This has nothing to do with your mind versus his mind or any other such projective nonsense. Either RS consistently treat these things are proper names and write them out and capitalize them the same way from source to source, or they do not. In these kinds of cases they do not, since they're descriptive phrases not names, and are not used consistently in sources at all, style questions aside. These things have no particular common names in English.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  04:49, 10 December 2017 (UTC)
Yeah, you really shouldn't aspire to consistency with the New York subway over-capitalizers. Note that the New York Times and New Yorker magazine, to name a few, don't do that; they say Second Avenue subway, (100 years ago, the old one was called Second avenue subway, but times change); similarly for Lexington Avenue line, and New York subway, which NYC wikipedians insist on capping against the advice of their MOS; yes, WP:OTHERCRAPEXISTS. But per our MOS, if the New York Times and New Yorker and other respectably edited English-language publications can get away with lowercase, then we there's no reason we should treat these as proper names. But I can't fix everything as once; when I get pushback, I slow down and work through it. Dicklyon (talk) 05:40, 10 December 2017 (UTC)

Corresponding Requested Move discussion opened

I open a multi-RM on all the lines in the 5 metros I could find: Talk:Kalininsko-Solntsevskaya_Line#Requested move 11 December 2017. This seems like an opportunity for a more focused discussion now that we've all aired our feelings and it's clearly "A" vs the status quo. Dicklyon (talk) 03:28, 11 December 2017 (UTC)

RFC on forming possessive form of singular names, MOS advice simplification

Should we simplify the advice of the WP:Manual of Style to choose between a pronunciation-based option and a uniform "add apostophe and s" option, in favor of just the uniform approach, since the pronunciation-based approach is complicated, seems to be misunderstood, and is hard to apply? Dicklyon (talk) 02:36, 12 December 2017 (UTC)

Specifically, the proposal, based on the discussion at WT:MOS#Apostronot, is that the nearly three hundred words of the existing MOS:POSS under the heading Singular nouns be replaced with this text that paraphrases the advice in University of Oxford Style Guide:

For the possessive of singular nouns, including proper names and words ending with an s (sounded as /s/ or /z/, or silent), add 's: my niece's wedding, James's house, Cortez's men, Glass's books, Illinois's largest employer, Descartes's philosophy. If a name already ends in s or z and would be difficult to pronounce if ’s were added to the end, consider rearranging the phrase to avoid the difficulty: Jesus’s teachings or the teachings of Jesus.

Note that most modern English guides recommend an approach close to this, though often with a short list or small category of exceptions. Please comment, support, or oppose. Feel free to propose alternative simplifications if neither this proposal nor the status quo seems ideal. If you prefer exceptions, what is the list or how will it be determined? Dicklyon (talk) 02:36, 12 December 2017 (UTC)

Comments on singular possessive form

  • Support as much simpler and easier to understand and explain; would avoid the pronunciation arguments that the current MOS:POSS generates, and reflect common usage MapReader (talk) 06:10, 12 December 2017 (UTC)
  • I've always found this rule from the University of Oxford's style guide to be very clear and useful. I'd support this change. Killiondude (talk) 07:09, 12 December 2017 (UTC)
  • Support. This is the sensible "please stop fighting about this" approach, and is very clear and simple both for editors and more importantly for readers. The "sometimes just use ' alone" styles are ambiguous, inconsistent, confusing, and lead to frequent dispute, while the "consistently use 's" style is understood by everyone, and 100% clear on whether something is a singular or plural possessive. Verbal pronunciation-based ideas about how to punctuate are of no relevance on Wikipedia, which is not a broadcast medium. Such "rules" (which sharply conflict in both specifics and rationales from publisher to publisher) are found in regional style guides, but do not make any sense in an international encyclopedia, because pronunciation of things like Jones's and Texas's vary on more than one axis (both syllabification and, often, /s/ versus /z/ – varying not only by dialect but by individual word/name). Modern style guides are increasingly shifting to a simple "just use 's" rule, including The Chicago Manual of Style (with some nitpicks [some of which are not even self-consistent – even CMoS has some editing gaffes] in the 17th ed., University of Oxford Style Guide, and various others. Those that want some kind of "odd exceptions for ' only" variance are mostly either old, or are written for a fixed audience with known dominant pronunciation patterns. We have no need of the rather tortured "make a special exception for ..." stuff found very randomly and inconsistently in various off-WP style guides (when not based on regional pronunciation, they're usually based on the traditionalism of "Jesus'" and "Moses'" in the King James Version of the Bible, which is written in late Middle English, while Wikipedia obviously is not).  — SMcCandlish ¢ >ʌⱷ҅ʌ<  11:25, 12 December 2017 (UTC)
  • Support but allow occasional exceptions if contemporary English reliable sources are (mostly) consistent in using just '. Above all don't edit war about it. Thryduulf (talk) 13:43, 12 December 2017 (UTC)
    I was assuming it went without saying that the normal approach of preserving format for citations and quotations would continue to apply. Other than that, I doubt that there are any words where an alternative format is consistently used; even Jesus's is very common nowadays MapReader (talk)
  • Support This is the only sensible version. No need for a list of exceptions, just rephrase the sentence if you don't like how it sounds. --Khajidha (talk) 13:46, 12 December 2017 (UTC)
  • Support. This is great.The current MOS, with two options, one unconditional and the other depending on pronunciation, with the one to be used depending on who's edited the article first, couldn't be better designed to generate editor disputes. The new proposal is so much better. — Preceding unsigned comment added by 2a00:23c5:5a4c:c400:d093:4f95:a3d0:abdb (talk • contribs)
  • Support per University of Oxford style guide linked above. --SarekOfVulcan (talk) 15:42, 12 December 2017 (UTC)
    Just to be clear, this is the "University of Oxford Style Guide", not one of the "professional" guides published by Oxford University Press, which it states it is not trying to compete with, but does differ from a bit. Dicklyon (talk) 16:35, 12 December 2017 (UTC)
    Thanks, edited to clarify. --SarekOfVulcan (talk) 18:57, 14 December 2017 (UTC)
  • Comment - in the example, I don't understand why it's recommended to add 's for "Glass's books" while it's recommended to rewrite "Jesus's teachings". What's the difference? Both end with a hard s sound, at least how I pronounce them. And maybe it's different in different places, but wouldn't "Jesus's teachings" and "Jesus' teachings" be pronounced the same? Ivanvector (Talk/Edits) 18:55, 14 December 2017 (UTC)
  • Your last sentence is a good point. I suggest that multiple editors corner their respective priests/pastors at church on Sunday and ask them how they pronounce the possessive of "Jesus" in their sermons. And report back here afterwards. If "Jesus's" is good enough for Father Bob and his congregation, it should be good enough for Wikipedia. ―Mandruss  19:49, 14 December 2017 (UTC)
  • Jesus's is certainly good enough for a range of reputable sources including the Daily Telegraph, the Atlantic website, Newsweek magazine, and the Guardian, as well as a whole batch of Christian sites in both the U.S. and Europe. MapReader (talk) 20:59, 14 December 2017 (UTC)
  • That being the case, even if the last sentence is retained, which I will probably oppose as a cost:benefit fail, "Jesus's" is a crappy choice for an example. ―Mandruss  21:06, 14 December 2017 (UTC)
  • Nevertheless the proposal delivers 90% of what you are arguing for, and the option to re-word a phrase is always there, whether flagged by the MOS or not. WP MOS proposals are littered with examples of the good failing for want of the best, and hopefully editors will recognise that a leap forward is progress even if not perfection in a single bound? MapReader (talk) 22:55, 15 December 2017 (UTC)
  • Many guides discuss exception for names already ending with two sibilants, like Jesus and Moses; quite different from Glass. And if you would pronounce Jesus' the same as Jesus's, you are evidence for the fact that this distinction is super confusing. Dicklyon (talk) 20:24, 14 December 2017 (UTC)
  • No, that's the key point, the ' is silent (in those style rules, like ours, that are based upon pronunciation). Listen to the Velvet Underground song Heroin, the line containing Jesus' son. Pronounced the same as Jesus son. Indeed pretty much the only argument for the ', given the potential ambiguity it creates, is the supposed difficulty of pronouncing 's (in certain limited circumstances). Yet, as SMcC says above, WP is not a broadcast medium. MapReader (talk) 20:46, 14 December 2017 (UTC)
Is that a point of difficulty with the instructions? I've always read constructions like Jesus's and Jesus' as both sounding like "Jesuses", although it occurs to me that I would pronounce something like "Jesus' son" as you said in your example. I've also wondered why it became standard to use s' at all, figuring it's just one of those weird English things. Like how in Shakespearean-era English in a phrase like "all are punished!" the word "punished" is pronounced with three syllables (pun-ish-ed), where for it to be pronounced like we do these days it would be written "punish'd". That is, just something weird that evolved into (or out of) the language. This is probably way off-topic. The point is, if people don't agree on how to pronounce these things, then a standard based on pronunciation will fail. I don't know if this is a widespread case: it's what I'm used to, but it could still be a rare thing. Ivanvector (Talk/Edits) 21:37, 15 December 2017 (UTC)
  • Comment - If a name already ends in s or z and would be difficult to pronounce if ’s were added to the end, consider rearranging the phrase to avoid the difficulty: Jesus’s teachings or the teachings of Jesus. - Why does it matter whether it's difficult to pronounce (for some people)? How often do people read Wikipedia articles aloud? Are readers going to spend a significant amount of time struggling to "pronounce" "Jesus's" in their minds? ―Mandruss  19:35, 14 December 2017 (UTC)
    You're right, and the group of us that discussed it on the MOS talk page did consider going a step further and recommending simply always adding 's. The final proposal we ran with retains a small part of the existing link to pronunciation, particularly for sensitive words like Jesus - but through the option of re-ordering the phrase (which is always open to editors anyhow). MapReader (talk) 20:51, 14 December 2017 (UTC)
    To answer this would take quite awhile and involve the mechanics of how people actually perform the process of 'reading'. Short version: Internal voice can trip up reading as much as external voice. See Subvocalization. If its hard to say, it can be hard to read. Only in death does duty end (talk) 09:16, 15 December 2017 (UTC)
    That is not an argument for omitting the 's. I get "tripped up" more by Jesus' than by Jesus's—my language processing center needs the 's sound to make it a possessive.
    Regardless, even if there is some subvocalization benefit that is so minute that we need academics to tell us it exists (and that has yet to be shown, anyway), I weigh all benefit against its cost and I believe that that second sentence is a cost/benefit fail for the project. Editor time is a finite resource; there will never be enough of it to do everything, so priorities must be set and some less important things must be allowed to slide in favor of more important things. The editor time spent arguing, edit-warring, and RfCing about this (and more editor time dealing with the disputes at DRN, ANI, AN3, etc) would be editor time not spent doing things that benefit readers more. ―Mandruss  20:24, 15 December 2017 (UTC)
  • Support first sentence only per my comments above. I fully support the use of guidelines to eliminate unjustifiable battlegrounds, and the second sentence does the opposite. It will not be a good use of community time to engage in debates about the degree of difficulty in pronouncing "Hughes's"—replete with academic/pedantic references to sibilants and such—especially considering that readers are not required to pronounce it. Support as written as second choice, as that would still be a marked improvement. ―Mandruss  21:46, 14 December 2017 (UTC)
  • Oppose anything more: I am extremely unfamiliar with "'s" being added to possessives ending with an "s"; it looks really weird. In that regard, I am completely against anything that fully discourages the use of "s'". If—however—it is evidently becoming common (and I have missed it), by all means give editors a choice. Sb2001 14:19, 15 December 2017 (UTC)
  • Oppose standardising this completely. As there are still style guides that recommend checking the pronunciation [37], we don't need to force editors to write "Mephistopheles’s" against their will. Our MoS should not recommend something and then say "if it looks weird to you, rephrase it". Instead, allow non-weird possessives. —Kusma (t·c) 21:55, 15 December 2017 (UTC)
    You are of course free to write it any way you please. The MOS does not force editors to do anything. But if someone moves it toward MOS compliance, let it go, OK? That's all we ask. Dicklyon (talk) 03:58, 16 December 2017 (UTC)

Uptick in MOS-related RfCs

I notice that we have had a recent surge in discussions that pit our MOS against various project level guidelines. Is there a reason for this? (Not saying who’s right or wrong in these discussions... just wondering why we are suddenly getting so many). Blueboar (talk) 05:42, 13 December 2017 (UTC)

I suspect that it's because those who like the MOS are running up against significant opposition from those who like the individual project guidelines when the former group of editors try and change articles written/named according to the project guidelines. This is certainly the case with rail transport and so I presume it's the same in other areas too. I haven't been following all the discussions by any means, but from those I have seen I wouldn't like to say the manual of style is always or even almost always the better. Thryduulf (talk) 17:53, 13 December 2017 (UTC)
But why does this seem to be happening more often right now?--Khajidha (talk) 18:06, 13 December 2017 (UTC)
Do we have examples of what you're talking about? I've seen only very few such, like the NYC subway folks liking to cap all their stuff, but that discussion goes back a few years, nothing new. Dicklyon (talk) 18:18, 13 December 2017 (UTC)
If you're thinking of the recent China and Russia caps discussions, there was really no conflict with projects there. I was unable get much input from projects on those; they don't seen to care or have any conflicting style. There's one anon on the Russia stuff, and a one or two counter opinions on the China/Hong Kong situation, but nothing resembling project-level guidelines. In Taiwan, Philippines, and some other places the projects have been actively moving toward MOS compliance. Where is this "pit against" thing you think you've noticed? Dicklyon (talk) 18:34, 13 December 2017 (UTC)
  • If it is, it doesn't represent anything new. The standard tension at Wikipedia (which could perhaps be generalized to a sort of standard tension in across all human endeavors in the history of mankind) is the tension between uniformity and flexibility, or between "lumpers and splitters", or similar. Without taking sides (because taking sides isn't useful, or even necessary here, because neither is right, and both are wrong; and also simultaneously both are right, and neither is wrong), the issue is thus: On the one side, there is a benefit to having a clear unified rule set that everyone follows (if we all agree to do the same thing, its one less thing to fight over, so we can move along to something actually important). On the other side there is a benefit to allowing a diversity of rules to allow for the greatest diversity of ideas (rules that exclude valid ideas or their expression limits the usefulness of the project). This tension spills out in various places, under various manifestations randomly and without direct cause; it just happens to flare up somewhere or another. Whether its the "All articles should have infoboxes" vs. "It's OK if some don't" debates, the "The MOS should be applied to every article without question" vs. "Wikiprojects should manage their own affairs" debate, to any of a gajillion or so manifestations. If you really want to be helpful, just recognize the problem isn't going away, treat all of these discussions with nuance, and there is nothing to do about it because there is no reason to do anything. It always happens, will always happen, and doesn't need approval to happen. It just does. Accept that it will, and manage the fallout with nuance and grace when it does. --Jayron32 20:14, 13 December 2017 (UTC)
As you say, it's a natural consequence of having decisions taken at various levels, the latter being a better way of managing almost any complex enterprise than trying to centralise everything. In theory at least it might help to have some common definition of the things expected to be consistent across WP - grammar, punctuation, linking, content of the lead section, etc. - and those left to projects to sort out, which for me would include stuff like the use of infoboxes mentioned above. Whether such exists in WP I have no idea? If it doesn't it could be a difficult and tortuous thing to create (or, rather, on which to gain any sort of consensus!) MapReader (talk) 04:10, 14 December 2017 (UTC)

@Blueboar:, since I do a lot of MOS gnoming, I'm really wondering if your comment was related to some of my efforts. I haven't seen such a thing, so wondering what you're seeing. When an active project is out of sync with the MOS like at Wikipedia:WikiProject_New_York_City_Public_Transportation#Naming_conventions, there's not much that can be done. I tried an RM; it lost; that's life. Are there other projects relevant to what you're thinking, where things have happened recently? The big noise above about Russia should never have happened; it's about a globally banned block evader and a screwup in executing his technical requests; not a project; open RM to fix it is unopposed, last I looked. What else is behind your premise that we are "suddenly getting so many"? Dicklyon (talk) 21:05, 14 December 2017 (UTC)

My comment was inspired by the fact that at least 6 of the current discussions on this page relate to questions re MOS vs Progect guidance. I am used to seeing one or two such discussions a month, and it seemed unusual to have so many. Blueboar (talk) 22:05, 14 December 2017 (UTC)
Maybe I'm blind, but I don't see a conflict with project guidelines in any of those, with the exception of the NYC lines already noted. So if you see "discussions that pit our MOS against various project level guidelines", maybe it's just you seeing things oddly? Dicklyon (talk) 22:16, 14 December 2017 (UTC)
Oh, a little bit of the China transport discussion did involve an MOS conflict, too, I see now. There was essentially no project pushback when fixing hundreds of those titles though. Like in other countries where we worked on that, users with a China interest saw the advantage of consistency with WP style, I think. There's more to be done there, but I'm not sensing any resistance. Dicklyon (talk) 22:23, 14 December 2017 (UTC)
It's just a factor of: A) some overdue MoS cleanup and consolidation happening at the same time as B) a bunch of large-category WP:CONSISTENCY cleanup that happens (as titles discussions often to) to involved MoS questions; plus C) conscientiousness that VPPOL be notified of substantive, non-trivial MoS changes and proposals; and D) using VPPOL for its actual purpose as a non-topical, "editors of all interests and backgrounds" centralized discussion venue for WP:P&G matters, especially when individuals or topical blocs of editors make consensus determination difficult.

As to specifics: MOS:MATH is a site-wide guideline; the idea that MOS:MATH agreeing with WP:MOS (to which it is subordinate as a matter of policy) and with MOS:ACCESS, on an accessible markup question is somehow "pit[ting] our MOS against various project level guidelines"; WP:WikiProject Mathematics was canvassed to the RfC, but does not own or control that guideline, the WP community does, and accessibility and HTML and template markup questions that aren't maths-specific are outside of both MOS:MATH's and the wikiproject's scope. The Russian metro line RfC would not have been necessary if not for a disruptive and tendentious anon, who has now been positively identified as WP:SOCKing, banned editor Tobias Conradi. The earlier one on Chinese railways is not an wikiproject versus MoS dispute, but a wikiproject versus wikiproject one; the railway and stations wikiprojects have had multiple RfCs concluding (in agreement with MOS:CAPS) to stop over-capitalizing words like "line" and "station" when outside of proper nouns; a few editors from the China wikiprojects wanted to WP:POLICYFORK from that, as if there was something special and different about how to refer, in English, to train stuff in China. And so on. It's just coincidental timing.
 — SMcCandlish ¢ >ʌⱷ҅ʌ<  00:30, 15 December 2017 (UTC)

You've been around long enough to know what is and is not canvassing. But WP:APPNOTE is very clear that notifying Wikiprojects with an interest in a decision is not canvassing, and one of the best practices described at WP:RFC is to notify relevant Wikiprojects. I'll also remind everyone that Wikiprojects consist of editors who are just as much a part of "the community" as everyone else. Just to be clear, I don't claim that Wikiprojects always have the answers, or that Wikiproject Mathematics is always right, but there seems to be an implied attitude here that if you're not closely monitoring the pump and editing policies, then you aren't a member of "the community". Well I happen to think that all editors are part of the community, whether they are actively involved in policy work or not. Since not everyone monitors the pump as closely as most of the regulars here, it is very important for them to be notified of topically relevant proceedings here. Ideally all interested parties should be notified of a request for comment. While I've quite recently been accused of acting "tribally", I see more evidence that only those editors who regularly lurk on policy pages have opinions that are worthy of consideration, whilst those of us that edit more in focused content areas and articles are viewed as second-class citizens. Thus this is cast as "the community" versus "the Wikiprojects", which is a specious distinction with the sole intent of creating an artificial division of opinion. Sławomir Biały (talk) 13:09, 15 December 2017 (UTC)
Thanks for pointing out that this is largely due to using "VPPOL for its actual purpose". And for reminding me that it's not all about me. I think Blueboar just can't stand to see MOS working so well and having so much consensus in input; I'll think of him as our Ajit Pai, wanting to let the various independent factions do their own thing even if it's bad for the overall project. Dicklyon (talk) 03:08, 15 December 2017 (UTC)
Please note that I was simply asking “why?” we were getting more discussions than usual ... not passing judgment on the discussions themselves. Blueboar (talk) 21:13, 15 December 2017 (UTC)
But you presented it as "discussions that pit our MOS against various project level guidelines". No such thing is happening. Dicklyon (talk) 04:01, 16 December 2017 (UTC)

See also section(s)

I noticed that those sections have been abusing by editors to "promote" other pages they created or they like. Plus, the policy regarding "See also" sections says that "Whether a link belongs in the "See also" section is ultimately a matter of editorial judgment and common sense." Whether a link belongs in the section mostly depends on editors' POV and is often abused for promotional purposes (the same issue was the problem for ethnic gallery sections in the past and the problem has been solved, see WP:NOETHNICGALLERIES policy). We have already "Main articles", "Further information" links on articles and in addition to this, the useful articles are linked in the bodies of the articles already. Thus, due to the reasons i mentioned above, i think those sections are problematic, have been abusing and surpluss. (talk) 06:38, 14 December 2017 (UTC)

PS:I am unable to edit with my physical ip right now and sorry in advance for this. Thanks. (talk) 06:43, 14 December 2017 (UTC)

You can edit the "see also" section if you don't think the suggestion is relevant, and you don't have to follow a link that simply doesn't interest you. Read WP:ABOUT: "Wikipedia's articles provide links designed to guide the user to related pages with additional information." "See also" sections are part of that feature. Jack N. Stock (talk) 06:46, 14 December 2017 (UTC)
As i mentioned above, those sections mostly depend on the editor's judgment (that is what the policy says) and thus removing or edit-warring over this is meaningless. As for WP:ABOUT, as i mentioned above, we have already links in the bodies of the articles and "Further information", "Main article" links. In other words, see also sections are not "crucial" and unfortunately, have been abusing for POV & promotional purposes. (talk) 06:54, 14 December 2017 (UTC)
It is hard to determine if there is abuse (or not) without some specific examples to discuss. Blueboar (talk) 11:55, 14 December 2017 (UTC)
Exactly; which is why I was pressing you for examples of your complaint (or observation) in the section above. Dicklyon (talk) 22:17, 14 December 2017 (UTC)
We actually do have guidelines on see-also sections:
 — SMcCandlish ¢ >ʌⱷ҅ʌ<  00:35, 15 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 (e.g. for lacking sources or not being present in sources cited, once references had been added or the citations corrected). 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:
--Wiking (talk) 18:11, 15 December 2017 (UTC)
The copyright issue had not been addressed when I arrived at the page. Source article: []
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)


Archive-date parameter

File Upload Wizard

I was told that I should ask here for the solution to a problem I am encountering. The file upload wizard does not seem to work for me. I click on it but it just changes the bottom where it says when it was last modified and who modified it for a second then goes back to the original screen. This is a problem because I find many missing album/single covers on the Wikipedia. I know you can’t upload those to Wikimedia because I have gotten many copyright strikes for it. I would greatly appreciate help. DatBoy101 (talk) 23:23, 1 December 2017 (UTC)

What browser/OS do you use? Do you use some custom gadgets? Ruslik_Zero 15:46, 2 December 2017 (UTC)

I use Safari on my iPad Mini. DatBoy101 (talk) 16:49, 2 December 2017 (UTC)

What version of iOS? Ruslik_Zero 19:57, 3 December 2017 (UTC)
DatBoy101, I'm happy to help file a task to have the engineers look at the issue, but I need some more infomration. As Ruslik0 asks, what version of iOS are you using? Are you using the mobile web view or the desktop view? CKoerner (WMF) (talk) 21:08, 7 December 2017 (UTC)

I use IOS 11.2 I’m using the mobile view DatBoy101 (talk) 00:29, 8 December 2017 (UTC)

@CKoerner (WMF): Ruslik_Zero 13:12, 13 December 2017 (UTC)

"Clipping" of text/caret in edit summary and subject/headline

When I enter an edit summary the lower part of the text is not displayed - eg the bottom of the letter "g" and underscore characters are not visible. When the text gets long enough to reach the right-hand side of the edit summary text box (near the remaining-character count) the caret (vertical bar) disappears. This is quite annoying. The problem appears with MonoBook skin. It always seems to be a problem with articles, and sometime is also a problem with subject/headline. I'm using Pale Moon (web browser) v27.6.2 (the current version), but a similar problem occurs with FireFox v54. FF v57 fixes the descenders but not the disappearing caret. Does anyone know if this is a problem with Wikipedia, or is it a problem with the browser? If it's the browser, does anyone know if there is a specific bug (eg on Mozilla's website) covering it, which I could point the Pale Moon developers at? Or is there some other fix eg my custom CSS)? Mitch Ames (talk) 07:13, 2 December 2017 (UTC)

Opera too, and not just those: most one-line input boxes, including those in the goshawful new preferences thing (such as the custom signature). I picked MonoBook over Vector for some very good reasons, two of which were compactness and clarity. These are being thrown by the wayside and soon we will have a situation where it doesn't matter what skin we pick, it'll all look the same - unreadable. This is NOT GOOD for accessibility, and I REQUIRE some means of obtaining the former appearance. --Redrose64 🌹 (talk) 00:30, 3 December 2017 (UTC)
Nevermind that basically every accessibility guideline in existence disagrees with you when it comes to compactness. Padding is good for the eyes. But hey, maybe people will listen to your REQUIREMENTS. — Preceding unsigned comment added by (talk) 03:44, 3 December 2017 (UTC)
Listen, I have poor eyesight. The MonoBook version of the prefs was just fine. This one is not. Clipping off descenders can in no way be considered "helpful". --Redrose64 🌹 (talk) 19:55, 3 December 2017 (UTC)
I think we can safely trust users to know whether they can read things on their own computer screens. Whatamidoing (WMF) (talk) 19:41, 4 December 2017 (UTC)

Unable to reproduce on macOS. Can someone check on Windows/Linux ? —TheDJ (talkcontribs) 15:39, 4 December 2017 (UTC)

I have the problem on Windows 7. Mitch Ames (talk) 12:17, 5 December 2017 (UTC)
Could someone with this problem please check to see whether the descenders are clipped on the edit summary box while logged out/in a private window, or in &safemode=1? I'd like to see if we can rule out the possibility of broken scripts. Whatamidoing (WMF) (talk) 19:41, 4 December 2017 (UTC)
While logged out the problem does not appear (i.e. descenders and underscores are visible, caret is visible at the extreme right of the edit box) - but so far as I know you can't chose anything other than the default skin unless logged in, and even when I am logged in I see the problem with MonoBook but not Vector. (I.e the difference may not be that I am logged in/out, but that I have a different skin when logged out.)
While logged in, with MonoBook and &safemode=1 (e.g. []) I can see descenders and underscores, but the caret disappears when it is on the right side of the edit box.
Mitch Ames (talk) 14:02, 5 December 2017 (UTC)
You can try [] while logged out/in a private window. But I think that these results so far suggest that the problem with the descenders is in a gadget or script. Perhaps you and Redrose64 have a script in common? Whatamidoing (WMF) (talk) 18:00, 5 December 2017 (UTC)
I was under the impression that user scripts were disabled at Special:Preferences, so that you would still have a recovery means if you happened to lock yourself out with careless scripts. --Redrose64 🌹 (talk) 18:36, 5 December 2017 (UTC)
I don't think that user scripts (that is in one's own .js subpages) can be controlled through a preference. Jo-Jo Eumerus (talk, contributions) 19:19, 5 December 2017 (UTC)
I'm not saying that they can be controlled through a preference. I'm saying that user scripts are normally sent to your browser automatically when you visit any Wikipedia page (perhaps in a <link /> element or a <script>...</script> element), and such scripts are suppressed when you visit Special:Preferences as a safety feature. --Redrose64 🌹 (talk) 19:40, 5 December 2017 (UTC)
[] while not logged in behaves the same (other than the expected MonoBook look) as the default: descenders and underscores are visible, caret is visible at the extreme right of the edit box.
Perhaps you and Redrose64 have a script in common — How do I get a definitive list of what scripts I'm running? I know I'm using [], and my common.css has #wpTextbox1 { height: 52em; }. Mitch Ames (talk) 11:18, 6 December 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── There are at least these modifications to your account:

Are you still using WikEd? Whatamidoing (WMF) (talk) 19:08, 6 December 2017 (UTC)

The problem appears to be the syntax highlighter gadget. Clearing all of my .js and .css scripts made no difference, but the missing descenders and underscores is only a problem when the syntax highlighter is enabled. @Remember the dot: can you help us out here?
The caret still disappears at the right end of the edit box, even with the syntax highlighter disabled.
(I tried WikEd and the Beta Wikitext syntax highlighting, but for various reasons I much prefer the syntax highlighter.)
Mitch Ames (talk) 13:22, 9 December 2017 (UTC)
I can reproduce both the invisible underscore problem and the disappearing cursor problem, with or without the syntax highlighter enabled, using the MonoBook skin on Pale Moon 27.6.2 on Windows 10. I can't reproduce either problem with Pale Moon on Linux. You could try different versions of Firefox to figure out approximately when the behavior changed, and then look for people discussing similar problems online. —Remember the dot (talk) 02:21, 11 December 2017 (UTC)
I've just tested with Pale Moon on Windows 10 (in a VirtualBox virtual machine) and I get the same results - the problem appears whether or not use the syntax highlighter. Also, the problem appears with Pale Moon and not syntax highlighter on my normal Windows 7 machine if I delete my Pale Moon profile and use a default profile. It looks like some obscure combination of any number of things is triggering the problem. Mitch Ames (talk) 13:23, 11 December 2017 (UTC)
Just to make it more interesting, I tried Windows 7 in a VM, with a new Windows user (default Windows and PM profile), not logged in to Wikipedia - now in both Win 7 and 10 I can see the descenders and underscores disappear and re-appear as I scroll the up and down the page using the browser scroll bars! If nothing else, this gives me something reproducible to report to the Pale Moon developers. Mitch Ames (talk) 13:42, 11 December 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I've reported the problem on the Pale Moon bug report forum: [38]. Mitch Ames (talk) 12:32, 15 December 2017 (UTC)

Very strange spike in views in several articles

A number of low-profile articles about places in the Middle East ('Ain Ghazal, Ayn Ghazal, Al-Bassa, Al-Bassah, Al-Buwaydah, Baqa'a refugee camp, Diban) started receiving huge increase in views this year: Pageviews Analysis (Up to 50,000+ each). If you check 'Agent' parameter on the left, you'll see that until June 9 it was "Spider", and then "User". Views for some of those are almost identical day-by-day, and it stops and starts randomly. It's 100% unnatural. What can explain this? --Triggerhippie4 (talk) 23:01, 2 December 2017 (UTC)

Web crawler maybe? --Malyacko (talk) 00:10, 3 December 2017 (UTC)
But why these articles? --Triggerhippie4 (talk) 00:18, 3 December 2017 (UTC)
I have seen these sorts of pattern before, but I can see no sense to them, unless the pages are being used as a covert messaging channel. All the best: Rich Farmbrough, 14:58, 4 December 2017 (UTC).
It's possible these towns were discussed and linked in an Arabic news article or social media site. External linkage can create traffic spikes that sustain over a couple weeks. It's sometimes possible to track down the source but sometimes not. -- GreenC 15:21, 4 December 2017 (UTC)
Yes, as Onceinawhile pointed out, it is only the English version which gets these hits.[39], [40] If it had been in the Arabic news, then also ar.wp articles would have gotten hits. Huldra (talk) 21:56, 6 December 2017 (UTC)
No way. These places are not in the news, numbers are identical for different pages and they suddenly disappear and reappear. Only English wiki pages of these articles are affected. Click on Pageviews Analysis above. --Triggerhippie4 (talk) 18:14, 4 December 2017 (UTC)
In my experience, when you see a pattern like that it's generally because a celebrity has tweeted a link to the page for some reason or another (there's a particularly extreme example of the phenomenon here). ‑ Iridescent 18:21, 4 December 2017 (UTC)
That's different. Your example is a developed article about known subject of broad interest (urban legend/internet meme kind of thing). It has at least hundreds of views each day and it changes more gradually. I'm talking about stubs about unrelated non-notable villages that no one tweeted about, and that go back and forth like this simultaneously: Pageviews Analysis. --Triggerhippie4 (talk) 02:57, 5 December 2017 (UTC)
It's really difficult to tell. For example Al-Bassa is linked from this page and maybe that page is the one getting the traffic due to news etc.. with some viewers clicking through to Wikipedia. Or possibly that page has a maintenance script that has gone haywire, polling Wikipedia for existence. Do you have any theories? -- GreenC 15:14, 5 December 2017 (UTC)
I suppose it's some technical error. I decided to bring it here because it's seems too odd that articles that always averaged less than 100 views a day, now accumulated more than 10 million views in the last 8 months. --Triggerhippie4 (talk) 17:01, 5 December 2017 (UTC)
User:Onceinawhile noted the same, back in September, here. As one of the editors who have done lots of work on both articles, Ayn Ghazal and Al-Bassa, I am totally bewildered. I am quite familiar with the fact that whenever a place in the Middle East is in the news, then the page views goes through the sky on that article. But this is something different. For one thing, none of the places have been particularly in the news, lately, AFAIK. Secondly, look at the page views for both articles for the last 90 days: they follow each other closely. It would be interesting to see if the page views came from the same IP address...or if this is just some technical error. Huldra (talk) 20:49, 6 December 2017 (UTC)
My guess is machine generated because there is no collateral spike in connected articles. For example Ayn Ghazal, which gets 15k-30k hits a day, the lead section prominently mentions Ofer. But Ofer is only getting about 10 hits a day. If they were live people visiting Ayn Ghazal, some percentage would be clicking through to Ofer, but that is not happening: (PageView Ayn_Ghazal|Ofer). Ofer stays at a very low flat rate while Ayn Ghazal jumps up and down with high numbers (higher than Israel itself at times). Can't think how it would make sense unless machine generated. -- GreenC 21:24, 6 December 2017 (UTC)
I agree that this numbers are false, in one way or another. The question is: is it the Wikipedia page views counting which is wrong, or is some machine sitting somewhere viewing these articles over and over again? Huldra (talk) 21:28, 6 December 2017 (UTC)

Watchlist so big that I can't edit it

Other than manually going and removing articles, is there a solution when your watchlist is so big that you can't edit? I keep getting the "There are too many pages to display here." message when I try either of the two options to edit my watchlist. Flyer22 Reborn (talk) 00:32, 4 December 2017 (UTC)

@Flyer22 Reborn: how big is it? Are you able to access the page here: Special:EditWatchlist/raw? — xaosflux Talk 01:18, 4 December 2017 (UTC)
It currently has 8,996 pages. No, I can't edit it that way. Again, I tried both options offered. Flyer22 Reborn (talk) 01:46, 4 December 2017 (UTC)
@Flyer22 Reborn: Can you try safemode? — xaosflux Talk 02:06, 4 December 2017 (UTC)
Yeah, that works. So did the raw editing, even though it didn't work before. Some pages I tried to remove before were a lot of IP user pages. Because I don't see any IP user pages on my watchlist right now (although I probably overlooked some), I wonder if my initial attempts did work but were delayed. Flyer22 Reborn (talk) 02:57, 4 December 2017 (UTC)
@Flyer22 Reborn: Is the message "There are too many pages to display here" being displayed when you begin editing the watchlist, or when you click the "Remove titles" button at the button of the "edit watchlist" page? As a response to "Remove titles", the message seems to be short for "The software has successfully removed lots of pages from your watchlist, but it is impractical to list them in this confirmation message" -- John of Reading (talk) 07:17, 4 December 2017 (UTC)
When I get an actual problem of being too big, the error message is in a pink box. Backing out once and trying again succeeds, albeit with the "There are too many pages to display here" warning. --Redrose64 🌹 (talk) 11:30, 4 December 2017 (UTC)
John of Reading, I would get the message after I clicked the "Remove titles" button. Flyer22 Reborn (talk) 16:57, 4 December 2017 (UTC)
@Flyer22 Reborn: Then you can safely ignore it. @Everyone else: - where does this message come from? Can it be made clearer? -- John of Reading (talk) 17:40, 4 December 2017 (UTC)
It's MediaWiki:Watchlistedit-too-many. PrimeHunter (talk) 19:39, 4 December 2017 (UTC)
  • I've had the "There are too many pages to display here" message a few times after deleting a lot of entries from my watchlist, but I'm pretty sure it's only been referring to an inability to display the list of deletions - the deletions still worked. Boing! said Zebedee (talk) 13:36, 9 December 2017 (UTC)

MP3 uploading now supported on Commons

See the blog post or the announcement on Commons. Kaldari (talk) 23:19, 4 December 2017 (UTC)

  • Would've liked a heads up on the blog post since I've been chasing after it for the last year ;-). So far its only playback which we could've had then. The game changer is transcoding to MP3 so we can guarantee playback for everyone.

    The next formats going patent free are AAC-LC and MPEG 2 (the DVD codec) in February. — Dispenser 04:44, 5 December 2017 (UTC)

transcoding to MP3 so we can guarantee playback for everyone

This is already working, and there seems to be a script or something running that is starting transcode for most / all previous audio files. Oddly enough it seems to also be transcoding mp3 -> ogg , which seems rather pointless and a waste of time and space. 07:34, 7 December 2017 (UTC) — Preceding unsigned comment added by (talk)

You're thinking of OGV.js. It decodes Vorbis/Opus in JavaScript and is disabled for a sizable number of readers (iPhone users). Native MP3 decode would consume less battery and/or allow smoother video playback. — Dispenser 00:16, 9 December 2017 (UTC)
Nope, real transcodes ([] , []). 06:49, 9 December 2017 (UTC)

A note that seems important. Commons currently uses an abuse filter to block most people from uploading MP3s. So while this is "allowed" copyright wise it is not allowed for most people. The Commons right extended uploader has been created to allow certain people to upload MP3s after they have proven they know what they are doing. --Majora (talk) 00:56, 9 December 2017 (UTC)

The Intorient template does not display properly on Wikipedia Mobile Dark Mode.

A screencap demonstrating the broken nature of the Intorient symbol

I noticed that the Intorient carries a white background with it unlike most math symbols because unlike most math symbols which use the 'math' tag the Intorient is template. I was wondering if there was a way to edit how the template works or if it could be permanently replace by LaTeX's \ointclockwise (as seen here on page 2), how ever that would need to be integrated into what Wikipedia recognizes as a symbol as \ointclockwise is not currently recognized as a symbol.
What intorient looks like: \ointclockwise
The Editor's Apprentice (talk) 04:24, 5 December 2017 (UTC)

@The Editor's Apprentice: Those characters are not part of amsmath and thus not supported by our math mode. This is why a template is used to insert an image of them instead. The dark and sepia modes of the apps however do not invert colors of images (as most of the time that would be highly annoying for most images), so you get this white background. This is the downside of using dark mode unfortunately I think... —TheDJ (talkcontribs) 16:41, 5 December 2017 (UTC)
I created a ticket for this problem, but I suspect it will be rather low priority as there are several fundamental issues that will likely block it. —TheDJ (talkcontribs) 17:00, 5 December 2017 (UTC)
@TheDJ: Why does Wikipedia only support the amsmath package? — Preceding unsigned comment added by The Editor's Apprentice (talkcontribs)
@The Editor's Apprentice: Because it's a reputable, maintained and stable package, and included in almost all LaTeX distributions of all operating systems. Most additions are considerably less stable and thus riskier to introduce. Which doesn't mean we are not open to adding more, just that we are careful about doing so. —TheDJ (talkcontribs) 08:54, 7 December 2017 (UTC)
@TheDJ: That makes sense, how would one go along getting the relevant LaTeX package included? The Editor's Apprentice (talk) 00:25, 14 December 2017 (UTC)

How to add more leaders to country infobox?

In the Australia article I noticed that the infobox included the names of various government officials, so I thought that it would be appropriate to include also the names of the heads of the upper and lower houses. How can I do that? Thinker78 (talk) 22:12, 5 December 2017 (UTC)

@Thinker78: Without commenting on whether consensus is there to do this, it can be achieved by adding more |leader_title#= and |leader_name#=:
|leader_title1      = [[Monarchy of Australia|Monarch]]
|leader_name1       = [[Elizabeth II]]
|leader_title2      = {{nowrap|[[Governor-General of Australia|Governor-General]]}}
|leader_name2       = [[Peter Cosgrove|Sir Peter Cosgrove]]
|leader_title3      = [[Prime Minister of Australia|Prime Minister]]
|leader_name3       = [[Malcolm Turnbull]]
|leader_title4      = [[Chief Justice of Australia|Chief Justice]]
|leader_name4       = [[Susan Kiefel]]
|leader_title5      = 
|leader_name5       = 
|leader_title6      = 
|leader_name6       =
Let me know if you have any questions. Nihlus 08:59, 6 December 2017 (UTC)

Either Template:Sfn or some subtemplate of it appears to be broken

Either Template:Sfn or some subtemplate of it appears to be broken. See, for example, the article Dunkirk evacuation at the end of the sentence that reads "they would never return": Template:Sfn is generating a very long line of visible wikisyntax starting out "[[#cite_note-FOOTNOTEHart1948" that should not be rendered. —Lowellian (reply) 08:30, 6 December 2017 (UTC)

@Lowellian: I've moved the {{page needed}} template outside the call to {{sfn}}. -- John of Reading (talk) 08:52, 6 December 2017 (UTC)
(More) I've made the same fix at Lady-in-waiting. Perhaps something has changed behind the scenes, and {{sfn|Author|Year|p={{page needed}}}} used to work better than it does now. @Trappist the monk: might know. -- John of Reading (talk) 16:35, 7 December 2017 (UTC)

I think I found it but don't understand the fix. In {{fix}} was this line:

}}[[{{{link|Wikipedia:Cleanup}}}|<span title="{{delink|1={{{title|{{{link|Wikipedia:Cleanup}}}}}}{{#if:{{{date|}}}|<nowiki /> ({{{date}}})}}}}">{{{text|}}}</span>]]{{#if:{{{post-text|}}}

That self-closed <nowiki /> tag was (I think) the source of the strip marker in this:

[[#cite_note-FOOTNOTEHaydon1964<sup_class="noprint_Inline-Template_"_style="white-space:nowrap;">[<i>[[Wikipedia:Citing_sources|<span_title="This_citation_requires_a_reference_to_the_specific_page_or_range_of_pages_in_which_the_material_appears.?'"`UNIQ--nowiki-00000039-QINU`"'?_(February_2017)">page needed</span>]]</i>]</sup>-6|[1]]]

I replaced the <nowiki /> tag and the following space with &#32; and the 'problem' seems to have gone away. Today is Thursday so shit breaks. Did MediaWiki decide that self-closed <nowiki /> tags are no longer acceptable? (replacing <nowiki /> with <nowiki></nowiki> didn't fix the problem).

—Trappist the monk (talk) 23:12, 7 December 2017 (UTC)

Unregistered user with edits

I just came across User:Alan D, who is unregistered but has some edits from 15+ years ago - see User:Alan D~enwiki for the actual account (logged as registered 8+ years ago despite edits being 15+ years ago). The contributions are split between the two accounts, seemingly without any pattern. How do we handle this, for example, does it count as an unregistered username for WP:CSD#U2 purposes? ansh666 03:32, 7 December 2017 (UTC)

The edits at Alan D without the enwiki suffix have their [[user ID stored as 0 (as opposed to their actual user ID number) in the rev_user field of the revision table, or I (or another user) may have imported them from another Wikipedia database without remembering to change the username. The reason this happened is that the user didn't exist in the database when their edits were originally imported into the Wikipedia database in September 2002. Graham87 06:02, 7 December 2017 (UTC)
Yeah, I figured that something like that would be the problem. Is there any way to merge the contributions between the two accounts? ansh666 18:14, 7 December 2017 (UTC)
Not really, but this Phabricator ticket is kinda relevant. Graham87 05:41, 8 December 2017 (UTC)
I've just happened to delete User talk:Alan D a few moments ago. I hope that wont trigger a zombie apocalypse. Please feel free to revert if you believe it will (or I can too, if you ask). Rehman 06:34, 7 December 2017 (UTC)
Meh ... IMO it technically doesn't qualify for U2 because it's the previous name of a renamed user, but it doesn't really matter because it just contained an automated notice. Graham87 07:25, 7 December 2017 (UTC)

CSD tag fails to log

CSD tag.png

Not a major malfunction, but not much point in a log that doesn't log  :) See the image. — Preceding unsigned comment added by Serial Number 54129 (talkcontribs) 12:13, 7 December 2017 (UTC)

SVG file question

Why does clicking some versions of File:Question book-new.svg in the file history produce a page of code rather than displaying the image? To be clear, this link shows a page of code but this link shows the image. There is some related discussion at File talk:Question book-new.svg#MIME type. — Martin (MSGJ · talk) 13:15, 7 December 2017 (UTC)

@MSGJ: The servers cannot determine the mime type and thus return it as html. This is most likely because the old file version doesn't have a DOCTYPE, causing some of the services between the original upload and serving the file up again, to not be able to recognise it as an svg+xml document. This is known as issue phab:T131012. —TheDJ (talkcontribs) 16:39, 7 December 2017 (UTC)
@TheDJ: I really don't think that it's the absence of a DOCTYPE. Indeed, the SVG spec (section 1.3 SVG Namespace, Public Identifier and System Identifier) advises against adding one.
In recent weeks, I've seen the problem elsewhere; during which I've noticed that other SVG images lacking a <!DOCTYPE ...> display fine. Instead, I think it's the lack of a <?xml ... > and I've expanded on this at File talk:Question book-new.svg#MIME type. --Redrose64 🌹 (talk) 22:01, 8 December 2017 (UTC)

Does Wikipedia, its sister projects and Wikimedia in general use spreadsheets for some purposes?

I am curious whether spreadsheets (Excel, Google Sheets or others) are used for any tasks at Wikipedia/Wikimedia and related projects. If so, which tasks are those? orschiro (talk) 19:41, 7 December 2017 (UTC)

I have not seen editors use spreadsheets for behind-the-scenes work, but editors creating article content may find it convenient to create tables in their favorite spreadsheets, then import. See WP:TOOL for approaches to this. --Mark viking (talk) 20:02, 7 December 2017 (UTC)
Thanks, Mark! orschiro (talk) 06:14, 8 December 2017 (UTC)
@Orschiro: I use Excel for maintaining my book citations. One row for each book; one column for each element e.g. title, last1, first1, last2, first2, publisher, isbn etc.; the last column is a formula which puts all this together into a {{cite book|...}} template. When I acquire a new book, I add a new row. When I use any book in a Wikipedia article, I find the row for the relevant book, copy the last cell on that row, and paste it between my <ref>...</ref> tags. --Redrose64 🌹 (talk) 22:06, 8 December 2017 (UTC)
@Redrose64: thanks! That's interesting. How do you synchronize between your Excel and Wikipedia articles? Manually? Would a tool help you to do the sync automatically? orschiro (talk) 07:28, 9 December 2017 (UTC)
Why would I need to synchronise? Books, once they have been printed, don't change. So the content of the {{cite book}} has no need to change. --Redrose64 🌹 (talk) 14:18, 9 December 2017 (UTC)
Yes, you are right...Thanks! orschiro (talk) 06:31, 14 December 2017 (UTC)

Automated notice after changing email address outdated/erroneous? [SOLVED]

Hi y'all, hopefully this is a decent place to share this …

I just updated the email address associated with my user account and after entering my new address via the "(Change or remove email address)" link found under § "Email options" in "preferences" the system displayed this, as so:

Change or remove email address

A confirmation email has been sent to the specified email address. Before any other email is sent to the account, you will have to follow the instructions in the email, to confirm that the account is actually yours.

Return to Special:Preferences.

However, when I checked my email the message I received, titled Wikipedia registered email address has been changed, simply stated:

Someone, probably you, from IP address XX.XXX.XXX.XX, has changed the email address of the account "XXXXXXXXXX" to "[email protected]" on Wikipedia.

If this was not you, contact a site administrator immediately.

note: "XXX"s = redaction by me –

No confirmation link was included, nor indeed apparently necessary as my account appears to have succesfully updated without such.

I'm inclined to presume at this point that the prominent red notice I received onsite was just some sort of legacy remnant lingering in place.

Hopefully this will help someone who knows how to tinker around 'under-the-hood' bring things up-to-date and into alignment.

Thanks for your time and attention, --–A Fellow Editor– 20:52, 7 December 2017 (UTC)

Arrgh, this may not be so simple after all. Though my new email address shows in 'preferences' for me my 'user' and 'user talk' pages aren't showing an email link in the 'tools' sidebar ... However, manually clicking the "Confirm your email" link found under § "Email options" in "preferences"—above which it now states, with golden yellow background color, "Your email address is not yet confirmed. No email will be sent for any of the following features."—leads to ...
Confirm email address

You must validate your email address in order to use email features. Click the button below to send a confirmation email to your address. Then, follow the instructions in the email. To check whether you have already confirmed, please see your preferences.

A confirmation code has already been emailed to you; if you recently created your account, you may wish to wait a few minutes for it to arrive before trying to request a new code.

[Mail a confirmation code]

... Which at first seems to me to imply it's noting the sparse email message I received as if it had carried a confirmation link. However, another possibility may be that it still has retained some toggled value from when I set up my account's associated email some years ago. Meh, I'm gonna' try and 'click' the "Mail a confirmation code", regardless. --–A Fellow Editor– 21:36, 7 December 2017 (UTC)
  • AHA! My gmail acct. is sorting the confirmation emails into its 'social' tab, yet the updated address message had shown up in the primary inbox tab. I'd already checked the 'spam' folder, but had forgotten to check gmail's inbox sub-categories. I've now confirmed the new address and all's well. --–A Fellow Editor– 21:54, 7 December 2017 (UTC)

Invitation to Blocking tools consultation

Hello all,

The Wikimedia Foundation's Anti-Harassment Tools team invites all Wikimedians to discuss new blocking tools and improvements to existing blocking tools in December 2017 for development work in early 2018.

How can you help?

  1. Share your ideas on the discussion page or send an email to the Anti-Harassment Tools team.
  2. Spread the word that the consultation is happening; this is an important discussion for making decisions about improving the blocking tools.
  3. Help with translation.
  4. If you know of previous discussions about blocking tools that happened on your wiki, share the links.

We are looking forward to learning your ideas.

For the Anti-Harassment Tools team SPoore (WMF), Community Advocate, Community health initiative (talk) 23:23, 7 December 2017 (UTC)

Contributions in preferences

In my user preferences, I have the button enabled to "hide probably good edits". This has never affected my viewing of my own contributions until now. When I clicked on the link, it said "No changes were found matching these criteria" (or something like that), and the box on top (Hide probably good edits) on top had been automatically checked. I tried to uncheck it, but it would not let me. (It appeared to uncheck, but then I clicked the search button to make them appear and it rechecked it.) I had to go into my preferences and remove that setting to view them. I'm not on my normal computer (using a school Chromebook, usually use a Mac); could this be a reason why or is this just a new change with a bug? A lad insane talk 23:42, 7 December 2017 (UTC)

I am so tempted to de-red-link WP:ITSTHURSDAY. Basically, software is deployed on en.WP every Thursday. When you see something not working now where it used to work before, and the day happens to be Thursday, it's a solid bet that the software changed. This is probably a "we didn't quite think through how Special:Contributions should implement Advanced Filters" and likely deserves a task in Phabricator. --Izno (talk) 23:50, 7 December 2017 (UTC)
Okay, makes sense. Having the same problem on Mac. Would file a bug report but don't know how. A lad insane talk 04:55, 8 December 2017 (UTC)
@A lad insane: I fixed this problem (eventually) by going to Preferences→Recent changes→Revision scoring on Recent changes, Related changes, and Contributions and un-tick 'Show only likely problem edits (and hide probably good edits)' (this was so annoying). J947 (c · m) 05:47, 8 December 2017 (UTC)
Thanks. Seems to work. A lad insane talk 14:56, 8 December 2017 (UTC)


The "contributions" choice following "watchlist" suddenly produces a special page with no entries at all. What am I doing wrong? I am running Windows 7 with Mazilla Firefox 57.0.2 (64 bit) browser.--Dthomsen8 (talk) 20:04, 9 December 2017 (UTC)

I assume you mean those links in the top right of the screen.
Is the URL you visit [] ? If you click that link, do you see an empty page? I see your contribs. Can you make a screenshot? (((The Quixotic Potato))) (talk) 20:10, 9 December 2017 (UTC)
If you have enabled "Show only likely problem edits (and hide probably good edits)" at Special:Preferences#mw-prefsection-rc then try disabling it. PrimeHunter (talk) 20:17, 9 December 2017 (UTC)
@PrimeHunter: Dthomsen8 has sent me a screenshot of his contributions page. It has a tick at "Hide probably good edits", so your suggestion looks correct. -- John of Reading (talk) 08:28, 10 December 2017 (UTC)
Thank you, that was it!--Dthomsen8 (talk) 18:28, 10 December 2017 (UTC)

User contributions page not functioning

This morning my User contributions page stopped functioning. Can this be connected to the fact that I just dropped Microsoft Word and went to a shareware provider? "Hide probably good edits" keeps popping up on the User contributions page and it doesn't respond to any dates I put in. I think I'm using the latest version of Google Chrome browser. Jzsj (talk) 18:03, 10 December 2017 (UTC)

Quote from User:PrimeHunter: "If you have enabled "Show only likely problem edits (and hide probably good edits)" at Special:Preferences#mw-prefsection-rc then try disabling it.". (((The Quixotic Potato))) (talk) 18:49, 10 December 2017 (UTC)
And no, I don't think Microsoft is punishing you for dropping Microsoft Word Face-wink.svg. (((The Quixotic Potato))) (talk) 18:51, 10 December 2017 (UTC)
  • Thanks much, you got it. I hadn't made any recent changes myself and so didn't think to look under that. (Microsoft had received access to my computer yesterday, and I thought they may have made a mistake.) Thanks again! Jzsj (talk) 22:44, 10 December 2017 (UTC)

Bizarre Favicon Issue

I just noticed this really odd quirk with the Wikipedia favicon. When I click away from any Wikipedia tab on Firefox 57, two of what appear to be diaereses appear over the "W" in the favicon. I have no idea why, and thought I'd pint this out as a possible bug. These dots blink once when the tab is rolled over, and vanish when the tab is active. A screenshot of this is available at [41] Any ideas what's going on? Is this a Wikipedia issue, or should I report this to Mozilla instead? CreationFox Talk Page 02:08, 8 December 2017 (UTC)

Graphics related, hence not a Wikimedia issue. --Malyacko (talk) 13:27, 8 December 2017 (UTC)
Are you sure? I see the same in Firefox except for me it's the active tab which has the dots and the other tabs don't. When I reload a page the dots appear a little after the W. If there are enough tabs to get an arrow to display them vertically then both the active and other tabs have the dots in the vertical display. I have a similar but not identical issue in Microsoft Edge. The first Wikipedia tab I open has the W a little blurry but no dots. Additional Wikipedia tabs get a non-blurry W but a single dot in each of the upper left and right corner, farther from the W than the double dot pairs in Firefox. The favicon is from [] which has no dots when I view it directly. I haven't noticed any dots in IE or Chrome whether there is one or multiple tabs. In Firefox and Microsoft Edge I have only seen such favicon dots at Wikipedia so I wonder whether [] has an issue which could be fixed. Favicon says "a file containing one or more small icons". I don't know how to analyze ICO (file format) but that article also says "contain one or more small images". Could [] include a problematic icon which is only shown by some browsers in some situations? Zooming shows the image has rounded corners near where the dots appear. PrimeHunter (talk) 16:35, 8 December 2017 (UTC)
Hiya! Do you love Prime95 as much as I do? I use Icofx to open .ico files. (((The Quixotic Potato))) (talk) 10:22, 9 December 2017 (UTC)

Info box on watch list is obscured

As title. It looks like there was a recent change to the features added to the watch list quite a while ago as I noticed the Live Updates button is in a different position, and now the box with "List of abbreviations," etc. is obscuring text: [42]. Amaury (talk | contribs) 02:14, 8 December 2017 (UTC)

Amaury: This is phab:T182156. I personally can't reproduce this. May I ask you what browser and skin you're using? Nirmos (talk) 03:23, 8 December 2017 (UTC)
Also, does the problem go away if you're in safemode (RecentChanges with safemode, Watchlist with safemode)? Nirmos (talk) 03:45, 8 December 2017 (UTC)
Chrome. Default. No. Amaury (talk | contribs) 05:34, 8 December 2017 (UTC)
Ok. So, if you see the error in Chrome, and Legoktm's screenshot in phab:T182156 is taken in Firefox, we can rule out browser as a factor. Skin can also be ruled out as Schnark can see the error in any skin. And if you still see the problem in safemode, we can rule out all user css/js, all site css/js and gadgets, so the error has to be in MediaWiki. But because I (and many others, obviously) don't see this error, it has to be related to some kind of preference. Nirmos (talk) 06:26, 8 December 2017 (UTC)

Found it. "Group changes by page in recent changes and watchlist" at Special:Preferences#mw-prefsection-rc causes this. Nirmos (talk) 07:03, 8 December 2017 (UTC)

Thank you. I guess I'll disable that option for now until/if it's fixed. Face-smile.svg Amaury (talk | contribs) 16:44, 8 December 2017 (UTC)

is it possible to have a bug that automatically edits, adds/removes a character, and then saves a page repeatedly?

Subject says it all, really. Without introducing a custom Wikipedia tool/bot, by what technical mechanism(s) would it be possible for browser/operating system/hardware problems to cause an account -- otherwise functioning/editing normally -- to edit a page, add or remove a character, and then save, making about 30 such edits in a row in a short span of time? I can't wrap my head around it, but asking here in an attempt to AGF. — Rhododendrites talk \\ 03:13, 8 December 2017 (UTC)

@Rhododendrites: some crazy user script (which could run client side) - an interface bug, several things. Examining the edits may help - were they made with visual editor? — xaosflux Talk 03:56, 8 December 2017 (UTC)
To expand, the edits in question consisted of adding a line of white space, saving, removing the white space, and then saving again - doing that several times in the same article, and then moving on to another article to do the same thing - with affected articles in alphabetical order. And it sometimes went on for hours at a time, with multiple sessions spanning days and weeks. The editor in question denies there was any deliberate act involved, was not doing any manual editing at the time, and insists it was a computer fault. Rhododendrites has deliberately not linked to the discussion in question, which makes it harder, and I could (and will if you need it) show you some of the edits in question - but based just on this, how likely does the "computer fault" explanation sound? Boing! said Zebedee (talk) 13:09, 8 December 2017 (UTC)
PS: I don't know if the edits used Visual Editor - is there any way to tell? Boing! said Zebedee (talk) 13:10, 8 December 2017 (UTC)
@Boing! said Zebedee: That story is unlikely to be true. Check their userscripts (e.g. common.js and vector.js). Edits made while using VE are tagged, see Special:Tags and Wikipedia:Tags. (((The Quixotic Potato))) (talk) 13:13, 8 December 2017 (UTC)
I have found the edits we are talking about. On the 23rd of March the same user seems to have used software to remove a category from articles that were in said category. Note that the +1 edits are also editing articles in a specific category sequentially. The edits are not tagged with AWB. (((The Quixotic Potato))) (talk) 13:29, 8 December 2017 (UTC)
Ah, thanks. There are no tags I can see on the edits, and the user does not appear to have a common.js or vector.js (assuming I could see them as an admin). So you're saying that this was done with something automated, but which does not appear to be AWB? Interesting that the +1 edits are category-driven. Boing! said Zebedee (talk) 13:32, 8 December 2017 (UTC)
Any editor can see anyones vector.js afaik. I think it is extremely likely that the same script that made those changes on the 23rd was used to do the +1 edits. Heck, I would bet money on it. It would be a bit bizarre if there was a bug that happened to reproduce the same behaviour. (((The Quixotic Potato))) (talk) 13:35, 8 December 2017 (UTC)
I see the category driving the +1 edits at that time now, thanks. Boing! said Zebedee (talk) 13:40, 8 December 2017 (UTC)
The chances that this was caused by a computer fault are negligible to 0. Computers aren't magical, able to log on some days and make only the changes in question (review UTC April 6 and April 16 where these are the only edits which were made those days). --Izno (talk) 13:33, 8 December 2017 (UTC)
I think you folk have pretty much nailed it for us, many thanks for your help. Boing! said Zebedee (talk) 13:40, 8 December 2017 (UTC)
A couple of years ago there was a user (who may still be with us) who had installed some third-party browser add-on that would scan through a page looking for clickable links, and open each and every one in a new tab. Unfortunately, they had the rollback right, and when they went to their watchlist, the most recent edit(s) to every listed page were reverted, silently. It took some time to work out what was happening, by which time they'd picked up a block and (I think) forfeited the rollback right.
Maybe this is another case of third-party browser add-on. --Redrose64 🌹 (talk) 11:39, 9 December 2017 (UTC)
Nope, the person in question has admitted that I am correct. (((The Quixotic Potato))) (talk) 11:52, 9 December 2017 (UTC)

Anomalous wikilink color, neither red nor blue

Sorry if this is a known issue. It is new to me.

A wikilink to a nonexistent page, with "User" or "User talk" in Arabic, followed by a colon, followed by the name in Arabic, instead of displaying as a normal redlink, displays as a gray-pink link. This description is probably more specific than it needs to be. Maybe it is also true of all r-t-l languages, or whatever. I don't have time to experiment about that. Here is an example, involving redlinks to User:Anwar and User talk:Anwar in Arabic.

  • [[مستخدم:أنور |Anwar]] + [[نقاش المستخدم:أنور|talk]] : Anwar + talk

Compare this to the Devanagari symbol ॐ, which redirects to the article Om. As expected, the valid link is blue; two symbols together are invalid and display as a redlink.

  • [[ॐ]], [[ॐॐ]] : , ॐॐ

Anomalocaris (talk) 05:21, 8 December 2017 (UTC)

The examples you posted above look fine for me, are you having this problem on the English Wikipedia? I don't expect we support Arabic namespace aliases here. — xaosflux Talk 05:38, 8 December 2017 (UTC)
Xaosflux: I have just discovered that the Anomalous wikilink color is not an issue in Internet Explorer or Google Chrome. It is a problem in Mozilla Firefox. Also, there is no rule against having a user name in non-Latin letters. It is anomalous, however, to express "User" and "User talk" in a foreign language. But, this is exactly what User:أنور has in their signature, as you can see on User talk:أنور. The signature has redlinks to bogus user and user talk pages with the words "user" and "user talk" in Arabic instead of English. I have advised the user to change the links to working links to the actual user and user talk pages, but meanwhile, the redlink signature is gray-pink in Firefox, see for yourself. —Anomalocaris (talk) 06:18, 8 December 2017 (UTC)
The above links Anwar + talk are normal redlinks for me in Firefox. If you refer to the user's signature then they apply text-shadow: silver and font color="#004225" in: anwar call me. The result may depend on your browser. For me it's red with a silver/grey shadow to the bottom-right of the letters. PrimeHunter (talk) 10:39, 8 December 2017 (UTC)
The grayish/pink link is a visited red link as far as I know. Nihlus 10:41, 8 December 2017 (UTC)
Nihlus, same observation in Firefox for me - there is a slightly different shade for "visited" and "non-visited" red links. @Anomalocaris:, yes these usernames are supported, but localized aliases for namespaces are not supported on other projects - it's not a ltr/rtl specific issues (e.g. Usuario:Xaosflux doesn't work on enwiki even though it works on eswiki). The linking to a wrong namespace in their signature is also noted at User_talk:أنور#Your_signature - and should be changed by that user for use on enwiki. — xaosflux Talk 13:27, 8 December 2017 (UTC)
  • Just a note, the namespace bases are in English and will be honored on other projects just as you could call this page Project:Village pump (technical) as well as our localized namespace name "Wikipedia:"). — xaosflux Talk 13:31, 8 December 2017 (UTC)
Nihlus nailed it. Firefox and Internet Explorer display visited redlinks in the gray-pink. Chrome displays redlinks the same whether visited or not. Perhaps there are browser preferences involved also. —Anomalocaris (talk) 17:08, 8 December 2017 (UTC)
Yes, and Firefox also displays visited bluelinks in a darker blue - I'd guess it's just overlaying a grey on to the original colour, or something like that. I find it very useful for seeing which pages in lists of, say, unblock requests I haven't yet examined. Boing! said Zebedee (talk) 17:46, 8 December 2017 (UTC)

Slowness with gadgets and loading pages in general

Is anyone else having Twinkle (and sometimes, it seems, HotCat?) loading tremendously slow lately, including just about all day today? Pages load, but then sit there "still loading" for 10-15 seconds sometimes before the Twinkle tabs load in, and clicking on a link brings up the 'Could not load twinkleoptions.js" banner in the upper right. Sometimes it cleared up - and, naturally, as soon as I started typing this, it went away completely...- The Bushranger One ping only 10:23, 8 December 2017 (UTC)

Although now it seems to be doing it again. But posting this, it's not. Sigh! - The Bushranger One ping only 10:40, 8 December 2017 (UTC)
Oh it's not just me? I even switched my Internet connection earlier because the whole site was taking ages to load, but scripts (Popups and Twinkle) were being especially slow. It made clearing the AIV backlog rather difficult. HJ Mitchell | Penny for your thoughts? 10:46, 8 December 2017 (UTC)
Nope, not just you (and it's good to know it's not just me either!). I would muse on "It's-Thursday" but I've seen this happen before a few times. (Although maybe those were always Thursdays too? I dunno, let me check my notes.) - The Bushranger One ping only 11:02, 8 December 2017 (UTC)
Issues like these are usually infrastructure problems, not software stack problems, so unlikely to be connected to the thursday release schedule. Their cause can be any of the many intermediate places between your computer and the wikimedia server. It can help to gather a traceroute and report this back to the Wikimedia operations team. If the problem is close enough to them, sometimes they can cause the traffic to be rerouted to avoid the problem. Note that this might reveal your IP and/or location. —TheDJ (talkcontribs) 12:57, 8 December 2017 (UTC)
Not sure if it's related - User:RonBot1 Ran very slowly last night (1-2 pages a minute, when it usually manages 7), also noticed same issue with AWB (could not do better than 4 pages a minute and expected 50+) and user:Theo's Little Bot1 was affected as well (so not my PC at fault). Ronhjones  (Talk) 16:38, 8 December 2017 (UTC)
Same slowness here. --SarekOfVulcan (talk) 16:40, 8 December 2017 (UTC)
Me too - periods of very slow loading of pages, and frequent "Could not load twinkleoptions.js" error (though the latter not for a couple of hours). Boing! said Zebedee (talk) 17:49, 8 December 2017 (UTC)
Same here since yesterday. I also noticed that my Special:Contributions page now says "No changes were found matching these criteria," although my Preferences page gives my correct edit count. Cleared the cache. No change. JimVC3 (talk) 19:16, 8 December 2017 (UTC)
Me too, both general loading of pages and very late loading of scripts on pages (not Twinkle, which I haven't used lately, but other scripts). Makes it hard for me personally at WP:SPI.--Bbb23 (talk) 19:25, 8 December 2017 (UTC)
@JimVC3: Your issue with contributions is described at #Contributions in preferences. --Izno (talk) 20:20, 8 December 2017 (UTC)
@Izno: Thank you! I'll take a look. — Preceding unsigned comment added by JimVC3 (talkcontribs) 22:36, 8 December 2017 (UTC)
I can confirm the speed of pages loading, etc, has gone down from terrible to dogshit. Please fix. Thanks. Lugnuts Fire Walk with Me 19:38, 8 December 2017 (UTC)
I asked on IRC and apparently phab:T182322 is likely the cause. They are working on it MusikAnimal talk 20:03, 8 December 2017 (UTC)
I'm relieved that it's not just me! Natureium (talk) 20:08, 8 December 2017 (UTC)
Was also wondering what happened. Kante4 (talk) 20:26, 8 December 2017 (UTC)
My speeds suddenly speeded up, no wait after pressing "save" on AWB - fingers crossed it's a fix Ronhjones  (Talk) 20:30, 8 December 2017‎
Yep, looking good. For now! Lugnuts Fire Walk with Me 10:39, 9 December 2017 (UTC)

Special:Undelete OOUI idiocy

To pre-empt the inevitable complaints about the latest round of OOUI whitespace stupidity, this time afftecting Special:Undelete, I have created phab:T182398. MER-C 10:51, 8 December 2017 (UTC)

MER-C: If I understand correctly, what you don't like is that the container for the textarea has a max-width. You can remove it by adding
.oo-ui-textInputWidget {
	max-width: none;
to Special:MyPage/common.css. Nirmos (talk) 12:07, 8 December 2017 (UTC)
@Nirmos: I 100% agree with @MER-C: here - this goes beyond a WP:IDONTLIKEIT issue and shoudn't require a hack, especially not a per-user hack. max-width abuse has been rearing its ugly head in multiple OOUI updates lately, and need to continue to be called out to the programmers. In this case, it appears it has already been accepted that this should not have been released as-is and will be fixed. — xaosflux Talk 13:41, 8 December 2017 (UTC)
Hi folks. Sorry about this, my bad, I should have caught this during review of the change. We're going to revert back to the old textbox (but keep the buttons OOUI) on Special:Undelete, on monday. Bawolff (talk) 17:43, 8 December 2017 (UTC)
Shit happens, thanks for fixing it ASAP. (((The Quixotic Potato))) (talk) 17:45, 8 December 2017 (UTC)
Thank you. I hope the changes to the text box stay reverted. Having monospaced font is often useful for me, especially when I need to copy some text or when I need to count the number of characters. It's easier to click between any pair of monospaced characters than to click between two narrow ones, like a pair of apostrophes, and with monospaced you can just count a specific number of characters and divide up your paragraph into equal-sized lines. Totally impossible with a proportional font, superior though it is for the publicly viewable side of things. Nyttend (talk) 02:45, 10 December 2017 (UTC)
Wait, there are font changes ? That would be unexpected AND not what this discussion was about, so please file separate tickets about that. —TheDJ (talkcontribs) 08:59, 11 December 2017 (UTC)
The font changes are awful. I've tried a few browser work-arounds and I still hate it. Natureium (talk) 16:44, 11 December 2017 (UTC)

This is reverted now (The textbox anyways, the buttons are staying OOUI). Bawolff (talk) 14:52, 11 December 2017 (UTC)

Orange box on move dialog

(split from above section)

Is the appearance of an orange background around the pink "You will need to delete the page you're attempting to move to" box related to this somehow? - The Bushranger One ping only 02:48, 9 December 2017 (UTC)

@The Bushranger: this is not present on the test sites, appears to be enwiki localization related to the template wrappings called from: MediaWiki:Delete and move text. — xaosflux Talk 16:33, 9 December 2017 (UTC)
Gotcha. It's not annoying, it's just something I never noticed before, so I thought I'd ask. - The Bushranger One ping only 22:49, 9 December 2017 (UTC)

History display

Ordinary editors see a display like this:

00:01 1 January 2017 Wikipedia editor (talk) | (contribs)..(10,000 bytes) (+100)..(Add references) (undo)

However, it appears that administrators see a display like this:

2017-01-01T00:01:00 Wikipedia editor (talk) | (block)..(10,000 bytes) (+100)..(Add references) (undo)

Is the display really set up so that the administrator can block virtually instantly without checking the editor's contribution record? When the blocking dialogue box comes up is it prepopulated with the editor's account details to make blocking that much faster? (talk) 14:45, 9 December 2017 (UTC)

Yes it's everywhere - it's not quite like that because (for logged in users) we also see a contribs link - and it's very handy. I use it a lot, for example I recently used it on User:ExtraLongJucySchlong. Though most relevant admins will have popups enabled so you can see contribs, edit count, and other details without wandering too far. And yes, the form contains the username to block, but the reason and other details need to be filled in. -- zzuuzz (talk) 14:55, 9 December 2017 (UTC)
Thanks. I was just about to ask, given that for IPs the username is the contributions link, would there be a contributions link in the example, and you've clarified that. (talk) 15:00, 9 December 2017 (UTC)

Two quick questions

  1. Is there a way to thank directly from my Watchlist?
  2. Is there a quick or one-click way to watchlist all articles in a list (say, the contribs of a sock puppet) or a category?

Thanks, Justlettersandnumbers (talk) 22:31, 9 December 2017 (UTC)

1. Without seeing the actual edit? I am not sure why you would want that. "Thank" links are not part of watchlists or recent-changes. They are only in page histories and edit-diff pages. To be honest I think it would be better to remove those links from the page histories.
2. Not as far as I know. (((The Quixotic Potato))) (talk) 22:38, 9 December 2017 (UTC)
I use them from page histories regularly. I usually go "view diff - view history to see if anything else changed - thank". - The Bushranger One ping only 22:51, 9 December 2017 (UTC)
You don't have to; when viewing a diff you can see if there are newer revisions than the diff you are currently viewing (if so then a "Next edit →"-link appears). If that link is absent then nothing else has changed and you are looking at the latest revision. (((The Quixotic Potato))) (talk) 23:14, 9 December 2017 (UTC)
  1. phab:T51541 is the task for this. I would guess someone has a Javascript lying around which can do this.
  2. phab:T3710 is the task to be able to do this with the software directly with a category. There is a comment a little bit down the page with a Javascript you can install. Special:Recentchangeslinked is also a pretty good alternative.
--Izno (talk) 00:39, 10 December 2017 (UTC)
@Justlettersandnumbers: If you are checking the diff with popups without leaving the watchlist, you can choose "actions > send thanks" from the popups menu. -- John of Reading (talk) 08:32, 10 December 2017 (UTC)
Thanks, John of Reading, but I'm used to the way this excellent script works; and no, The Quixotic Potato, I've no wish to thank anyone if I don't know what I'm thanking them for (and removing the thank link from page histories wouldn't really make it easier to express thanks). Thank you, Izno, will look. Justlettersandnumbers (talk) 09:54, 10 December 2017 (UTC) (Re-ping Izno, not enough coffee. Justlettersandnumbers (talk) 09:56, 10 December 2017 (UTC)
The second one didn't work either. --Izno (talk) 13:38, 10 December 2017 (UTC)

Regex intitle searches

It seems that intitle:/U\.S\.A/ doesn't work – it's ignoring the punctuation just like doing a search on intitle:U.S.A would. This doesn't happen with insource:/U\.S\.A/. Is there some trick that works for getting intitle: searches to stop ignoring punctuation when you're explicitly telling them to stop?  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:14, 10 December 2017 (UTC)

Our search box cannot do it as far as I know. [] can but it's slow and cannot be combined with other searches. PrimeHunter (talk) 10:16, 10 December 2017 (UTC)
It looks to me as though you are getting results, and they all have titles that involve "U.S.A." -- they're all redirects though! Since that's the case, the primary listing will be the target of the redirect, with original title listed as (redirect from ...). I think it just looks odd because it's not immediately visual that your results are correct. I've uploaded a screenshot of my first few results, including sister projects. By the way, syntax variations I used for escaping which all gave basically the same results were: intitle:U.S.A., intitle:"U.S.A.", intitle:U\.S\.A\., intitle:U\\.S\\.A\\., intitle:U\\\\.S\\\\.A\\\\. (implies to me we're doing a good job of stripping overly zealous escape sequences, heh). FACE WITH TEARS OF JOY [u+1F602] 10:43, 10 December 2017 (UTC)
PS: the first suggestion, intitle:/fooooo/ wouldn't work as you intended here. Intitle does not support regular expressions and so the slashes would be stripped. FACE WITH TEARS OF JOY [u+1F602] 10:46, 10 December 2017 (UTC)
intitle does not support regular expressions; T156474 is the task. T156510 is the task for better punctuation support, barring support for regular expressions. --Izno (talk) 13:41, 10 December 2017 (UTC)
The Article List tool associated with Release Version Tools can handle regex title searches with a period. Try this search for WikiProject United States articles with U.S.A. in the title (the search chokes for me if I don't limit it in some way, such as by WikiProject). Plantdrew (talk) 20:31, 11 December 2017 (UTC)

Filtering page list based on source content

Is there any reasonable way to remove from User:Od Mishehu/hd cat any pages which, ignoring spaces, contain "nocat=y"? עוד מישהו Od Mishehu 14:11, 10 December 2017 (UTC)

You seem to have AWB permission (on the account Od Mishehu AWB). You can also ask another AWB user to do it, see Wikipedia:AutoWikiBrowser/Tasks. (((The Quixotic Potato))) (talk) 14:55, 10 December 2017 (UTC)
How would I do the filtering using AWB, other than through trying to edit each article which has this? עוד מישהו Od Mishehu 15:05, 10 December 2017 (UTC)
AWB can pre-parse lists, without making any edits. You can import the list, preparse it to remove pages that contain the stuff you do not want, and export the list. If you post an AWB task you can ask them to describe how they did it. I am currently on my phone so I cannot give detailed instructions at the moment. (((The Quixotic Potato))) (talk) 15:22, 10 December 2017 (UTC)
I think you need to enable preparse mode (in the Options menu). In the "Skip" tab you can say that if the text contains "nocat\s=\sy" then the article must be skipped and removed from the list. In regex \s means whitespace. Remember to check the regex checkbox. (((The Quixotic Potato))) (talk) 15:34, 10 December 2017 (UTC)
My AWB is running. It will take a while (roughly two hours I believe). I am not sure if the instructions I gave above are clear enough, if not then please let me know. Screenshots are probably easier. (((The Quixotic Potato))) (talk) 16:52, 10 December 2017 (UTC)
I have posted the results over at User_talk:Od_Mishehu/hd_cat. (((The Quixotic Potato))) (talk) 19:06, 10 December 2017 (UTC)
Thanks. עוד מישהו Od Mishehu 07:17, 11 December 2017 (UTC)

Template: Infobox civilian attack - missing parameters

G'day from downunder! {{Infobox civilian attack}} shows that |coroner= is an unknown parameter type. Can anyone help or explain to me why this occurs? Many thanks and seasons greetings, etc. Rangasyd (talk) 15:15, 10 December 2017 (UTC)

I've traced it back to this edit which capitalised the parameter name incorrectly. --Redrose64 🌹 (talk) 15:38, 10 December 2017 (UTC)

Error in Tuckingmill article

Hiya. Not sure where to post this. I'm seeking an editor to correct a formatting error in the Leed of Tuckingmill, Camborne, Cornwall article. Thx in advance, Trafford09 (talk) 17:47, 10 December 2017 (UTC)

@Trafford09: See this edit. (((The Quixotic Potato))) (talk) 17:51, 10 December 2017 (UTC)

Many thx TQP - I saw how you fixed it. Trafford09 (talk) 18:32, 10 December 2017 (UTC)

CSS to prevent list items wrapping in a hlist?

Is there any CSS class to prevent list items wrapping in a hlist?

I would like to do that in Template:United Kingdom MP categories header, where YYYY–YY links get wrapped on the endash ... but don't want to clutter the markup by enclosing each list item in a {{nowrap}}. It would be easy to do in raw CSS, but wikimarkup doesn't give access to that.

Similar issues at {{Teachtaí Dála category navigation header}} and {{Members of Seanad Éireann category navigation header}}. In each case the by-term entries get wrapped on the endash. (Slight difference to the UK MPs, in that entries here are of the form nth (YYYY–YY) ... but only the "nth" is linked.

Any pointers or suggestions? --BrownHairedGirl (talk) • (contribs) 20:21, 10 December 2017 (UTC)

I can only propose defining a new class, which should be like 'hlist' but prevent contents of <li> elements from wrapping. Ruslik_Zero 20:45, 10 December 2017 (UTC)
That's what I'd like. I hoped that it might exist already, ready to meet me. --BrownHairedGirl (talk) • (contribs) 20:56, 10 December 2017 (UTC)
Surely you can already do this in {{hlist}}, by putting a suitable CSS declaration into an appropriate style parameter? For instance, |item_style=white-space:nowrap; --Redrose64 🌹 (talk) 21:26, 10 December 2017 (UTC)
Thanks, @Redrose64. In these cases, I am not using {{hlist}} directly; the templates use {{infobox}} or {{navbox}}, and I don't see any item_style param in either case.
Have I missed something? --BrownHairedGirl (talk) • (contribs) 22:42, 10 December 2017 (UTC)
Hmmm, I tried it - seems that it just prevents wrapping between an item and the following bullet, wrapping can still occur between a bullet and the following item, also between the en-dash and the following figure. At least, that's what happens in Opera 36 - other browsers may vary. --Redrose64 🌹 (talk) 23:21, 10 December 2017 (UTC)
@BrownHairedGirl: You can use {{wj}} or {{zwj}} (or &zwj;) on either side of the endashes to prevent it from breaking at those points. --Ahecht (TALK
) 20:07, 12 December 2017 (UTC)
Thanks, @Ahecht. That sounds like the most elegant solution so far. Not as pretty as CSS, but better than wrapping the whole thing in a template. --BrownHairedGirl (talk) • (contribs) 20:22, 12 December 2017 (UTC)
This is an ugly solution. Ruslik_Zero 20:23, 12 December 2017 (UTC)
I added an appropriate css to User:Ruslik0/common.css. It works. So, a class can be defined I think. Ruslik_Zero 20:34, 12 December 2017 (UTC)

Tool for highlighting links that point to redirect pages?

Hi all, is there a tool/gadget that I can activate that will indicate (say with a color) that a link points to a redirect page? There's a gadget under Preferences > Appearance that will display links to disambiguation pages in orange. Looking for something like that. Context: List of former child actors from the United States has a lot of blue links, but how many of those point to redirect pages, implying that the individuals may not be notable? Thanks, Cyphoidbomb (talk) 22:10, 10 December 2017 (UTC)

Links that point to redirects have the CSS class mw-redirect. So if you want to you can add a line to Special:MyPage/common.css.
For example:
.mw-redirect { color:green;}
If you also want to control the color of links that you've visited already:
.mw-redirect:visited { color:darkgreen;}
You can find a list of colors over at Web_colors. For example, you can replace "green" with #000 (which is black).
(((The Quixotic Potato))) (talk) 22:20, 10 December 2017 (UTC)
I put the following in my Special:MyPage/common.css, which puts the Insert redirect.png icon after the link (similar to how external links are presented):
.mw-redirect {
        background: url([]) center right no-repeat;
        padding-right: 13px;
--Ahecht (TALK
) 23:28, 11 December 2017 (UTC)
A simple solution for occasional use in cases like the mentioned article, that works very well in Google Chrome, is to view the HTML code ("View source") of the page and do a text search for "mw-redirect". The hrefs in the HTML are linked to the corresponding web pages for easy access.
I think this works better in Chrome, where "View source" uses a regular browser tab, than in Safari, which shows the HTML in a Web Inspector tab. It doesn't work at all in Firefox, where hrefs on the HTML source page are linked to other pages of HTML code. --Pipetricker (talk) 12:08, 12 December 2017 (UTC)
@The Quixotic Potato, Ahecht, and Pipetricker: Thanks for the ideas, guys. Appreciated. Cyphoidbomb (talk) 16:24, 13 December 2017 (UTC)

Someone (probably you) recently logged in to your account from a new device

Hi! I received the following email:

«Someone (probably you) recently logged in to your account from a new device. If this was you, then you can disregard this message. If it wasn't you, then it's recommended that you change your password, and check your account activity.»

I did logged out and back in recently. So it is probably that. But... I used the same computer, and the same browser - maybe a newer version, I upgraded days ago. My contributions are OK, I changed the password just in case (though a bad faith intruder would have changed it too).

The point is: could the message be more useful? *Why* was it triggered? *which* new device? This way I can not know for sure if it was me. And it is the second or third time I write here because of vague security messages... maybe it is within industries best standards, I suppose they are, but then the standards are quite poor, aren't they? Or maybe I expect the impossible? - Nabla (talk) 02:42, 11 December 2017 (UTC)

Imagine that someone has hacked your email, and has reset your Wikipedia password that way. The attacker would also get information about which device you (last) used, when, from which IP etc. I think the vagueness of these messages is protecting us. (((The Quixotic Potato))) (talk) 07:36, 11 December 2017 (UTC)
There is this ticket phab:T174388, which suggests adding IP/geolocation to the message. —TheDJ (talkcontribs) 09:08, 11 December 2017 (UTC)
Bad idea. Maxmind's free database is complete shit (except on country-level) and their paid stuff isn't much better. Including geolocation information will only cause more confusion and problems. I expect an endless stream of messages like: "Oh no, someone logged in from another city in the same country, but I haven't been in that city lately. Help!". Confusing noobs with misinformation can be fun, but not in this case. (((The Quixotic Potato))) (talk) 09:43, 11 December 2017 (UTC)
The last idea for that was to only use country level information (also because that is translatable). But currently, no one is working on it, nor planning to work on it. —TheDJ (talkcontribs) 10:12, 11 December 2017 (UTC)
Thank you. On country-level it is do-able, and the quality of the database is good enough. (((The Quixotic Potato))) (talk) 10:26, 11 December 2017 (UTC)
Yes, being more specific than a country is fraught with problems, see User:Redrose64#Where am I? It's why I (occasionally) advise people at WP:Geonotice not to be too specific in the coordinates. --Redrose64 🌹 (talk) 21:26, 11 December 2017 (UTC)
For what it's worth, I agree with adding country level info. While that info may not help in the event someone else in the same country gets into your account.. The information presented would be reliable and helpful in all other situations. My IP regularly shows up as belonging to a city/town up to 600 kilometres (370 mi) away (but always within the same country)... this is simply due to the nature of dynamic IPs within your local telco. - Vanstrat ((🗼)) 15:06, 12 December 2017 (UTC)
  • From an unrelated web site, I recently got a message telling me that someone had successfully logged in to my account from somewhere in South Korea. That was very valuable, and it led me to immediately log in and change my password. Had it not been country specific, I might not have done that, as my ISP in the UK tends to provide varying nonsense locations for IP lookups (though always in the UK) and I would have assumed that's all that had happened. I therefore strongly support adding the country information to the message. Boing! said Zebedee (talk) 15:12, 12 December 2017 (UTC)

Tech News: 2017-50

17:57, 11 December 2017 (UTC)

New-page curation toolbar: issue/potential bug with AFD

Please see [48], which happened when I used the new-page curation toolbar to create an AFD for an article that, unbeknownst to me, had already been deleted prior to a deletion discussion. (I have resubmitted the AfD via Twinkle, which did its thing correctly.) Thanks! - Julietdeltalima (talk) 21:38, 11 December 2017 (UTC)

@Kaldari: - can you take a peek at this? Let us know if a new phab ticket should be opened. — xaosflux Talk 22:19, 11 December 2017 (UTC)
Disregard, GeoffreyT2000 found it! — xaosflux Talk 23:56, 11 December 2017 (UTC)
@Julietdeltalima: This is phab:T169441. GeoffreyT2000 (talk) 22:37, 11 December 2017 (UTC)

Misleading rollback links

It seems that for users with the rollbacker right, when at the watchlist page, the most recent edit to every page is given a "[rollback]" link even when page protection would prevent that user from editing said page. Is this a recent software change? See Wikipedia talk:Rollback#Rollback allowing non-admins to rollback edits on fully protected pages? --Redrose64 🌹 (talk) 12:05, 12 December 2017 (UTC)

I'm glad that the system inherently checks permission level and clicking those links doesn't work. Since the rollback link doesn't show up in the page history itself, It seems like whatever check is being made there that decides not to show the link simply isn't being made in the watchlist. If it's possible to correct it to remove confusion I recommend it. - Vanstrat ((🗼)) 14:53, 12 December 2017 (UTC)
Redrose64, would this be worth creating something in Phabricator about? Or is this outside of that system's scope? - Vanstrat ((🗼)) 18:20, 12 December 2017 (UTC)
I've created a task in phabricator. - Vanstrat ((🗼)) 22:40, 15 December 2017 (UTC)

Prior version environment?

So I know we have testwiki and test2wiki where releases get pushed slightly early (mw:MediaWiki 1.31/Roadmap) - is there anywhere where they are pushed purposefully LATE? Whenever we get a "Must be Thursday" troubles - we always get a "was it like this before?" problem - but nowhere to actually go check. Is it time for test3wiki? — xaosflux Talk 12:33, 12 December 2017 (UTC)

I support this idea. Natureium (talk) 18:44, 12 December 2017 (UTC)
This came up on the wikitech-l mailing list a while back, and basically everyone said you should report anything that seems like a bug, regardless of whether you think it's a regression. I'm mostly in support of a test3 wiki too, so we can easily compare/contrast, but I'm not smart enough with infrastructure things to really make a case. I recommend creating a phab ticket proposing this, and tag it with "Release-Engineering-Team". MusikAnimal talk 23:09, 12 December 2017 (UTC)

Annoying search for "CAT:"

When I type "CAT:PROD" in the search bar, it automatically converts it to "Category:CAT:PROD", which doesn't ecist. The same happens with "CAT:CSD", which brings me to Category:CAT:CSD. Basically, every search for "CAT" expands to "Category:CAT", instead of to "Category:" or to "CAT:". Is this a new problem or a known bug? Fram (talk) 13:58, 12 December 2017 (UTC)

What is your setting at Preferences → Search? There are four choices. --Redrose64 🌹 (talk) 14:20, 12 December 2017 (UTC)
Completion suggester: "default (recommended)". Prefix search: not selected. Fram (talk) 14:28, 12 December 2017 (UTC)
There you are: "Corrects up to two typos. Resolves close redirects." In short, a PITA. I suggest you switch to "Classic prefix search", as this has "No typo correction. Matches the beginning of titles." in short, it won't attempt to second-guess you. --Redrose64 🌹 (talk) 14:33, 12 December 2017 (UTC)
Thanks, I'll change my preference, but if someone from the WMF (or whoever developed this "completion suggester") reads this, perhaps they should take a look and change the code for this specific issue? Fram (talk) 14:58, 12 December 2017 (UTC)
The bug does not depend on that preference. It occurs after you have included "Category" at Advanced search and chosen "Remember selection for future searches" (only possible when logged in). mw:Extension:CirrusSearch/CompletionSuggester is only supposed to suggest existing pages. Suggesting non-existing pages like Category:CAT:CSD when you type CAT: is a clear bug and not just poor typo correction. I assume the bug is triggered by CAT:CSD redirecting to the category namespace. Any tested search starting with CAT: only gives non-existing pages starting with "Category:CAT:". Typing Category:CAT: gives the same false results when it should have given no results. PrimeHunter (talk) 15:14, 12 December 2017 (UTC)
It sounds like phab:T115756 from 2015: "Search suggests non-existent title due to namespace/redirect mixup". The same can happen for redirects to other namespaces. I selected "Wikipedia" at Advanced search and chose "Remember selection for future searches". Then MOS: suggests red links like Wikipedia:MOS:NUM instead of MOS:NUM. It's not limited to names with colons. Expanded a suggests Wikipedia:Expanded article instead of Expanded article. PrimeHunter (talk) 19:03, 13 December 2017 (UTC)
Thanks. Let's hope that after more than two years they can fix this! Fram (talk) 13:57, 14 December 2017 (UTC)

Edits (rather than the text of edits) being imported into Wikipedias of other languages

(Before the heading title above raises false alarms that my account's login credentials have been somehow compromised, they have not. This issue appears to involve some sort of (new?) MediaWiki importation tool.)

I've been editing Wikipedia for a long, long time, around a decade and a half, during which many articles I wrote or contributed to have been copied and pasted and translated into Wikipedias of other languages. That's fine/great; no problem! I'm happy/delighted to share the results or work product of my edits in other languages! But I just encountered something new and different.

I was just given a welcome message to the Bihari Wikipedia by another user, thanking me for my edits there. This surprised me as I don't speak or understand the Bihari languages, so why would I ever have edited there? So, I checked bh:Special:Contributions/Lowellian. And I recognize those edits: I did make those edits, but I made those edits to the English Wikipedia, not the Bihari Wikipedia!

After poking around the page histories some more (and navigation is difficult due to the aforementioned fact that I don't understand Bihari, so I have to do some informed guesswork clicking on links), for example [], I can see that my edits have been somehow "copied" from the English Wikipedia to the Bihari Wikipedia, and in a way different from a normal page move: normally, when a page is moved, the edits are also moved with it so that each edit still only appears in one page history (unless it was a copy-and-paste move, in which case the text of the edits but not the edits themselves get copied/moved). But this situation appears to be something different, in which my edits are now duplicated so that the same edit history appears on both the English and Bihari Wikipedias, accredited to me.

This is fundamentally different from normal copying-and-translation of articles into other languages since that copies the prose/text (the work product of edits) rather than the actual edit history (the edits themselves). This concerns me because those page histories make it look like I have been editing the Bihari Wikipedia when I have never done so. I don't want, for instance, people complaining to me about edits I made on another-language Wikipedia that I had no knowledge of and did not make. (This is different from normal copying/translation of articles into other-language editions, since normal copying/translation doesn't make it look like I directly edited those other-language editions.)

This all appears to be done by some sort of (new?) MediaWiki importation tool? Can someone in the know provide background for what all is happening here?

Lowellian (reply) 22:42, 12 December 2017 (UTC)

@Lowellian: from bhwiki's log I can see that @SM7: has imported these using the normal transwiki import process. This part is OK and normal. phab:T179832 describes some of the intricicies of imported usernames and how it is being dealt with. — xaosflux Talk 23:32, 12 December 2017 (UTC)
Okay, I don't really understand the issues described in phab:T179832 or whether they apply to this specific case, but maybe someone can at least clear this up for me: if you look at [], some edits are marked "imported>" followed by the username. My problem is that my edits, at least, seem to have been imported without even that "imported>" designation, as if I made the edits directly to the Bihari Wikipedia, when I did not. My edits should be marked "imported>" if they were imported. Is this something that has been looked at and fixed so that it won't happen in the future? —Lowellian (reply) 23:41, 12 December 2017 (UTC)
See meta:Help:Import for the feature. It's from 2003.[49] You can select English as interface language at Special:Preferences at a foreign wiki. This may make it easier: []. I don't know when an edit will say "imported>". I haven't seen that before so the anomaly may not be that it's "missing" from you but that it's shown for some of the others. PrimeHunter (talk) 00:02, 13 December 2017 (UTC)
The import process recently got a few enhancements, which is what phab:T179832 was talking about.
When importing edits, the importer must specify the source of the import, and can choose whether imported edits by users who exist in SUL are attributed to the local account for the user or in a fashion like "en>Example" that links to the source wiki from the edit history.
Of course, we also have over a decade of imports that were done under the previous system, where edits were attributed to a local user even if that user didn't exist. A cleanup script is being run on the servers to update the attribution to the SUL user where possible and with a "imported>" prefix otherwise. Since Lowellian's account is in SUL, they were attributed to that SUL account. BJorsch (WMF) (talk) 02:00, 13 December 2017 (UTC)
Thanks for the explanation. In that case, I would like to strongly make the following suggestion: in all cases when edits are imported, including for SUL accounts, there should always be some sort of marker/designation in the page history that the edit is an import in order to avoid the incorrect implication that the editor made that edit directly to that particular language-edition Wikipedia. It is inconsistent and misleading that only some users' imported edits are marked as imported while other users' imported edits are not marked as such, and unfair to make users look like they were spamming English edits onto Wikipedia editions in other languages when they did not do so. —Lowellian (reply) 02:38, 13 December 2017 (UTC)
The best place to make suggestions is in Phabricator. The best indication would probably be a tag. But note there's no way to reliably identify all past imported edits. Anomie 14:07, 13 December 2017 (UTC)
See also Wikipedia:Requests for page importation where we handle requests to copy histories TO enwiki from elsewhere for reference. — xaosflux Talk 23:36, 12 December 2017 (UTC)

Local accounts attached without a visit (and welcomed without an edit)

Today I have been getting Welcomed on both the Latvian and Kazakh wikis. I have never edited over there. I checked my contribs over there, but nothing shows. Could this be part of the same issue [ the previous topic about imported contributions ]? Bit of a coincidence that they both happened today and it has never happened before. — Insertcleverphrasehere (or here) 07:26, 13 December 2017 (UTC)

This is exactly what the previous topic is about. These welcome messages are being triggered by your edits being imported over to other-language-edition Wikipedias without your knowledge, making you look like a new editor to welcomebots, so they start leaving you welcome messages. Everyone complaining here, please add your voice to that topic if you have complaints about how this process is happening. It is wrong that edits from the English Wikipedia are being imported over to other-language Wikipedias without any indication that those edits are imported. —Lowellian (reply) 21:16, 13 December 2017 (UTC)
It happened on the Punjabi Wiki as well... What is going on here? — Insertcleverphrasehere (or here) 10:38, 13 December 2017 (UTC)
Insertcleverphrasehere, local wiki accounts get attached to your global account the first time you visit that wiki while logged-in. All three of lv:, kk: and pa: were attached to your account this morning. On some wikis you automatically get a welcome message the first time you log in. So I don't think this has any relation to the topic of imported edits (and have therefore separated this topic from that section). --Pipetricker (talk) 11:41, 13 December 2017 (UTC)
I wonder why all three happened today though? Must be the rollout of some kind of welcome bot. — Insertcleverphrasehere (or here) 11:47, 13 December 2017 (UTC)
As Pipetricker said: "local wiki accounts get attached to your global account the first time you visit that wiki while logged-in. All three of lv, kk and pa were attached to your account this morning." According to Special:CentralAuth/Insertcleverphrasehere you visited a large number of wikis for the first time today. Many users have been confused by such welcome messages in foreign languages. I have thought about suggesting at meta to ban welcome messages to users who have no edits at a wiki and didn't create the account there but just had it created automatically by viewing a page. PrimeHunter (talk) 11:55, 13 December 2017 (UTC)
Well, I definitely didn't visit all of those wikis today. I did however submit a SQL Query on Quarry for the first time, which required me to authorise it on Mediawiki, which is probably related? Still strange though. — Insertcleverphrasehere (or here) 12:04, 13 December 2017 (UTC)
That's unrelated. I have done no such thing recently and was welcomed on three wikis also. :) --Izno (talk) 12:23, 13 December 2017 (UTC)
Izno, are you saying the SQL query is unrelated to the attachment of a number of local accounts at about the same time, despite Insertcleverphrasehere not having visited those wikis? --Pipetricker (talk) 14:04, 13 December 2017 (UTC)
Yes. --Izno (talk) 15:41, 13 December 2017 (UTC)
Actually, it probably is related. The process of attributing those old imported edits to the SUL account includes creating the local account for the attribution to belong to, which would trigger the welcome message on wikis that do automated welcome messages on account creation. Anomie 14:10, 13 December 2017 (UTC)
Probably related to the topic of imported contributions, that is. --Pipetricker (talk) 16:46, 13 December 2017 (UTC)
I'm seeing this too. Of the 32-and-still-rising wikis that Special:CentralAuth/Cryptic says I attached in December 2017, I've only ever been to two - Gujarati Wikiquote and Persian Wikivoyage, and those only afterward, because I can'tcouldn't get the notifications for the welcomebot messages to go away no matter what I try. —Cryptic 14:50, 13 December 2017 (UTC)
(In case that crops up for anyone else - what finally worked was logging in directly on those wikis and checking off the notification at Special:Notifications, not just the dropdown on the sidebar.) —Cryptic 15:21, 13 December 2017 (UTC)
I also got two or three notifications. Emir of Wikipedia (talk) 14:55, 13 December 2017 (UTC)
CentralAuth shows many accounts being added. Emir of Wikipedia (talk) 15:01, 13 December 2017 (UTC)
I notice now that was attached to my account tonight, when I was asleep and my computers were turned off. It's not in my browser history previous to that, and I have no contributions there (and have received no welcome). --Pipetricker (talk) 15:10, 13 December 2017 (UTC)
My wuu.wikipedia account was created 45 minutes ago when my computer was turned off. There is clearly some current process creating accounts at other wikis without user action, maybe releated to work on phab:T179832: "Handling of imported usernames". I don't currently have edits registered at wuu:Special:Contributions/PrimeHunter but maybe there are old imported edits somewhere which have not been added to my contributions. PrimeHunter (talk) 16:05, 13 December 2017 (UTC)
Yes, there is some current process, as I stated in the section above. See phab:T181731 for the task about it. I note that the script is already done with all the "small" wikis. The wikis still in progress or pending are dewiki, enwiki, eswiki, fawiki, frwiktionary, hewiki, huwiki, itwiki, jawiki, kowiki, metawiki, nlwiki, nowiki, plwiki, ptwiki, rowiki, ruwiki, svwiki, thwiki, trwiki, ukwiki, viwiki, wikidatawiki, and zhwiki. BJorsch (WMF) (talk) 00:40, 14 December 2017 (UTC)
If the script is still pending for larger wikis, then those future runs should be stopped and held off until the problems people are complaining about are fixed. As a starting point, per User:Anomie's suggestion above, it should tag imported edits of SULs as imports instead of misleadingly implying that they were normal edits to Wikipedias of that particular language-edition. —Lowellian (reply) 06:33, 14 December 2017 (UTC)
Something should be done. See Wikipedia:Village pump (miscellaneous)#Rogue bot or what on other language wikipedias where I raised this. Andrewa (talk) 10:18, 14 December 2017 (UTC)
I see those things as honestly unnecessary. It causes a one-time notification on a per-wiki basis where any of your edits have been imported. Given that there are only 20 wikis left, spending time now would only prevent finishing the task while waiting for the extra work that is already planned-for down the road. --Izno (talk) 12:26, 14 December 2017 (UTC)
The problem is not really the welcome notifications. That's just a side effect / symptom of the ultimate cause and real problem, that we are being attributed, without our permission, to edits that we did not make. —Lowellian (reply) 20:58, 14 December 2017 (UTC)
We made our edits to articles which according to the licences we agreed to can be copied provided they are attributed. So it seems to me we agreed to the copies being attributed to us. (Maybe I misunderstood what you mean, but any way if it isn't a technical issue the tech Village pump isn't really the place to discuss that.) --Pipetricker (talk) 23:26, 14 December 2017 (UTC)
Attribution has multiple components: who wrote something, what was written, when it was written, and where it was written. The problem is that imports without tagging misrepresent one of those components: where it was written. These attributions aren't accurate because they are edits made to a specific wiki that are now being attributed as edits to a different wiki. And this is certainly a technical issue: it started out as a technical question asking why certain unusual behavior was being noticed, and it has continued as a technical discussion that includes how to, on a technical level, get those edits properly attributed; see the comments below where Xaosflux works out a technical solution to add tagging. —Lowellian (reply) 23:40, 14 December 2017 (UTC)
When you make an edit, above the edit box there is a notice containing the sentence "Work submitted to Wikipedia can be edited, used, and redistributed—by anyone—subject to certain terms and conditions." So by making the edit, you implicitly gave permission for reuse. Checking those T&Cs, I see that attribution allows several alternatives; one of them is "or c) a list of all authors". By crediting each individual edit to the person who made that edit, even if that edit was on another wiki, sufficient attribution is given. --Redrose64 🌹 (talk) 11:21, 15 December 2017 (UTC)
There's no way to reliably identify old imports to tag the edits, so that's not going to happen. The unexpected creation of accounts should be mostly done since most of the wikis are done. Anomie 13:56, 14 December 2017 (UTC)
But I'm not asking to identify old imports to tag the edits. I'm asking that future imports should tag imported edits as they are being imported. —Lowellian (reply) 20:56, 14 December 2017 (UTC)
@Lowellian: See the history of User:Xaosflux/Sandbox3z (for enwiki) and test2wiki:Male user:Xaosflux/Sandbox3z (for a remote wiki) for how NEWLY imported pages will appear in histories. Does the > identifier satisfy what you are looking for? — xaosflux Talk 22:18, 14 December 2017 (UTC)
@Xaosflux: Yes, that's great, thank you so much, that's pretty much exactly what I'm looking for! :) I don't know how involved you are in the process of these Wikipedia imports; are you in position to actually get that change done immediately for all future imports? —Lowellian (reply) 22:41, 14 December 2017 (UTC)
@Lowellian: I'm not working on the ticket, so here's the situation: any newly imported revisions will follow that already - its already live. The problem that you are seeing is that pages that were imported to projects previously have no information stored to change them in to this new style. — xaosflux Talk 23:20, 14 December 2017 (UTC)
@Xaosflux: Given the lack of stored information on previous imports, I see the difficulty there and am satisfied as long as these identifiers apply to all future imports. But I want to ask for clarification on something: these identifiers will apply to ALL future imports, including imports of edits from SUL accounts, right? Because that was the previous issue: imports of edits of non-SUL accounts were already being marked with an "imported>" identifier before the username, but edits of SUL accounts were not marked/identified in any manner. —Lowellian (reply) 23:52, 14 December 2017 (UTC)
@Lowellian: unless the software changes again in the future, then yes that is the plan for all imports going forward as far as I know, I think it is a good thing. The problem with the other edits is they USED to say your name on them, but in the database they didn't reference your userid, some of these appear to be resolvable, but many were not - in the database cleanup they are now saying "import>NAME" instead of just "NAME", because there is no way for them to know if it should be en:NAME, or es:NAME, or fr:wikisource:NAME, etc. For edits that did match a SUL account from the point of view of the destination wiki they already did match your SUL ID and there is nothing to do. — xaosflux Talk 03:56, 15 December 2017 (UTC)
  • I can see how the welcome notification when you haven't visited the wiki is annoying. There is no moral or legal obligation to "fix" anything in regards to attribution of your edit. Lowellian: Please see Wikipedia:Copying within Wikipedia. — Preceding unsigned comment added by Killiondude (talkcontribs) 00:05, 15 December 2017 (UTC)
    • It's annoying, confusing, unnecessary and just plain bad design. As is using a lonely bullet point for emphasis. Bullet points belong in bulleted lists. Andrewa (talk) 00:21, 15 December 2017 (UTC)
      • Thank you for your input. Killiondude (talk) 00:50, 15 December 2017 (UTC)
The normal process of copying within Wikipedia attributes that copying, within edit history, to the editor who was actually doing the copying. These imports are copying while attributing the copying to someone who didn't do the copying, to a wiki that they didn't edit. To repeat part of what I wrote above, attribution has multiple components: who wrote something, what was written, when it was written, and where it was written. The problem is that imports without tagging misrepresent at these components: who wrote it (since it is really the import script copying over what someone else wrote rather than that person writing it directly) and where it was written. These attributions aren't accurate because they are edits made to a specific wiki that are now being attributed as edits to a different wiki. —Lowellian (reply) 01:03, 15 December 2017 (UTC)
Regardless, the way it's happening is a confusing and annoying mess. The "welcomes" in unintelligible tongues of men and angels (for all the good they do) are just a symptom.
The problem appears to be, these so-called attributions are undecipherable. If this were not the case, the scripts would not have such problems. And since attribution is required, this is serious. Andrewa (talk) 01:46, 15 December 2017 (UTC)

Here's what I haven't yet understood about this:
So, on wikis where articles previously have been imported, in order to attribute the contributors to those articles, local accounts are created for the contributing users. But: most or at least some of the newly created accounts that have been reported here have no contributions! Are those accounts just a side effect with no significance (other than causing annoying welcomes and uncertainty)? Or do they mean that contributions by that user have been imported, but the details have somehow been lost and won't therefore appear in the contributions list? --Pipetricker (talk) 10:09, 15 December 2017 (UTC)

This recent comment by jhsoby at phab:T181731 seems to say it's basically an insignificant side effect, connected to Wikidata. (@Anomie) --Pipetricker (talk) 10:38, 15 December 2017 (UTC)

Information vs text

The issues raised at Wikipedia:Village pump (miscellaneous)#Rogue bot or what on other language wikipedias seem better discussed here. Perhaps I should in hindsight have come here first.

One of the possible problems that occurs to me is really a restatement of the initial problem raised here by Lowellian. Somehow, we've lost sight of the difference between information, which can't be copyrighted but must be sourced by references, and text, which can be copyrighted and so must be attributed.

Accurate translation preserves the information but not the text. So when going from one language wiki to another, the references should be kept, but the attributions should not be.

In English Wikipedia, other language Wikipedias are not acceptable references, so translation into English should not be a problem: The sources are kept, the attributions discarded. Other language Wikipedias may have different policies on this, in which case it may be acceptable to add a reference to English Wikipedia if translating from here. But regardless, the attributions belong only in English Wikipedia.

Am I missing something? Andrewa (talk) 05:55, 16 December 2017 (UTC)

It seems you would be interested in reading derivative work. Killiondude (talk) 06:13, 16 December 2017 (UTC)
Good point but not quite so simple. While translation of a literary work certainly preserves the creative element of the original, the translation of an encyclopedia article does not. The creative aspect of the text of an encyclopedia article is purely in the phrasing (we prohibit original research, for example), and is lost in the translation. Andrewa (talk) 06:57, 16 December 2017 (UTC)

Mutilated and vanishing text, history and edit screens, green on black gadget

I use the green on black gadget when using Wikipedia, as I fid it more comfortable. For the last few weeks I have noticed a couple of oddities on the edit screen, and on history pages. On the edit screen, most of the text below the edit summary box and the save button is now illegible (apparently it is in black, or nearly black). On the history screen the external tools are apparently overprinted with gibberish. I've made some screenshots on Imgur, I hope they make sense. this and this are the links. At first I just thought "Oh, they're buggering about as usual, it'll pass in a day or two", but it hasn't. Anyone know what has caused this and how to fix it? Thanks, DuncanHill (talk) 23:45, 12 December 2017 (UTC)

It's called "Use a black background with green text" at Special:Preferences#mw-prefsection-gadgets. The talk page is MediaWiki talk:Gadget-Blackskin.css. I see the same issues with Vector and Firefox. The text around the edit summary is black on grey background without the gadget. I guess the gadget doesn't know how to handle that properly. The gibberish is a series of external link icons as background of the link text instead of a single icon after the text. I don't know why that happens. The links are made with code in MediaWiki:Histlegend. Some of the styling apparently misbehaves when used with the gadget and displayed outside the normal wikitext area. It works fine for me when rendered below with the gadget. PrimeHunter (talk) 00:18, 13 December 2017 (UTC)
For any version listed below, click on its date to view it. For more help, see Help:Page history and Help:Edit summary.

(cur) = difference from current version, (prev) = difference from preceding version,  m = minor edit, → = section edit, ← = automatic edit summary

The problem here is a combination of two things.

  1. MediaWiki:Gadget-Blackskin.css defines a background-image for external links, but does not specify how this image should behave with regard to position and repetition.
  2. MediaWiki does specify how background-images should behave with regard to position and repetition, but the rule is scoped to .mw-parser-output, which is the part of the page that comes from the wikitext.

This means that there are three ways to solve the problem:

  1. You can remove
    html .mw-body-content .external {
    entirely from MediaWiki:Gadget-Blackskin.css.
  2. You can specify how this background-image should behave with regard to position and repetition in MediaWiki:Gadget-Blackskin.css, using background-position and background-repeat.
  3. The selector .mw-parser-output .external could be changed to .external in MediaWiki.

Nirmos (talk) 04:24, 14 December 2017 (UTC)

Monobook formatting

I am currently working on quite a large table that appears pretty disjointed and squashed in Vector skin, yet perfectly fine in Monobook skin. I was just wondering whether there might be an option to have the table appear as it did in Monobook in Vector, perhaps by the creation of a new template such as {{Monobook begin}} or by adding |style="monobook" in the table. I know that the obvious solution would be to decrease the overall font size down to 90%, but sadly that would in turn affect how the table looks in Monobook. I am not quite sure what to do.--Nevéselbert 00:05, 13 December 2017 (UTC)

Can you point to the table? Is it a different font that you can just use? — xaosflux Talk 02:28, 13 December 2017 (UTC)
Once again: you will get better help if you provide a link to the thing you are working on. Being vague in your problem reports does not help you get your problems solved. – Jonesey95 (talk) 05:44, 13 December 2017 (UTC)
Sorry Jonesey95, I will try and be more specific. @Xaosflux: The page I am working on is the list of British prime ministers, and my point is that the table formatting in Monobook skin is vastly superior than that in Vector skin. I don't believe a different font will help, per MOS:FONTFAMILY. I would like to find a way of reducing the font size as it appears in Vector without affecting the size in Monobook. I don't know whether that is possible, or whether there might be an easier way to solve this.--Nevéselbert 10:37, 13 December 2017 (UTC)
The table appears to be functional in both skins, I think it looks more "squashed" in monobook (which is my normal skin), the biggest side by side difference is just that the entire body shifts because the article space is more to the right in vector. Please keep in mind that readers could be at any resolution or zoom level, so the layout will be mostly browser (and browser setting) dependent to them. — xaosflux Talk 12:16, 13 December 2017 (UTC)
You can, but you shouldn't, per xaosflux. --Izno (talk) 12:25, 13 December 2017 (UTC)
Thanks for the link. It helps. I looked at the two links you provided, and the pages look essentially the same to me. The only thing that looks not quite right to me is the text for the "Ministerial portfolios held during tenure" column; the leading of the rows is too tight. It appears that someone has set "line-height:90%" in the cells of that column, even though there is room for the text. I removed that line-height setting and previewed the result, and the table looks better to me.
If you are still seeing problems, perhaps a screen shot would help us understand what you are seeing. I know that it is harder to provide a screen shot than a link, so I will understand if you find it difficult to provide one. – Jonesey95 (talk) 15:41, 13 December 2017 (UTC)
Thanks for the reply Jonesey95. I have changed the line-height setting to 100%, from 90%, which might work better. You're right that the skin doesn't really make that much of a difference, and I guess the real issue is browser width. On the subject of screenshots, the issue of misaligned table lines persists. See here, "1802" is not aligned correctly.--Nevéselbert 00:46, 14 December 2017 (UTC)
I don't see misaligned tables in three up-to-date browsers on Mac OS. I did clean up some mismatched brackets and braces, along with one set of italics, but I don't think that would change anything. I suspect a rowspan/colspan error, but diagnosing it on that table is a major endeavor. – Jonesey95 (talk) 03:45, 14 December 2017 (UTC)
@Jonesey95: Where do you think the best place would be to ask about the misaligned lines? This might be an Internet Explorer bug.--Nevéselbert 11:20, 14 December 2017 (UTC)
See Wikipedia:Screenshots of Wikipedia for instructions. Alternatively, sometimes e-mailing it to one or two people is just as useful. Whatamidoing (WMF) (talk) 20:07, 13 December 2017 (UTC)

Sandbox returns to User page

I’ve noticed an irritating problem recently when using my sandbox, if I click on an article link from my sandbox and then press the back button, it returns to my User page and not my sandbox, using this odd url-link The same thing happens if you refresh the sandbox. It doesn’t happen with other users sandboxes, only my own. Occurs with both Android and Win 8.1 on IE11, and when logged in and out. TonyTheTiger reported something similar on the help desk.

Does anyone else have the same annoying problem as this...Jokulhlaup (talk) 11:16, 13 December 2017 (UTC)

@Jokulhlaup: I'm in a bit of a hurry this morning, but I can let you know that this is the section of the page that is triggering it:
{{scrolling window|link=Special:RecentChangesLinked/User:Jokulhlaup/Smite|height=200px|title=Lighthouses}}
xaosflux Talk 12:27, 13 December 2017 (UTC)
I can reproduce in Fx 57.0.2 on Windows 8. It's probably related to the fact that you are transcluding Special:Recentchanges (based on the ?hidebots=1&hidecategorization=1&hideWikibase=1&limit=50&days=7&target=sandbox&urlversion=2 part of the string, which is part of the filters work done) and probably worth a Phabricator report as such. --Izno (talk) 12:28, 13 December 2017 (UTC)
Phab task already filed: phab:T181032. --Izno (talk) 12:40, 13 December 2017 (UTC)
Thanks for the quick replies, now I know what is causing the problem. Thanks to Izno for completing the Phab report, much appreciated...Jokulhlaup (talk) 14:59, 13 December 2017 (UTC)
  • When is this problem going to be solved so that I can refresh the related changes to User:TonyTheTiger/creations?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 04:10, 14 December 2017 (UTC)
    In the future, you should subscribe to the task (it's really easy--the system uses OAuth to log you in with your MediaWiki user name and password). In the present, it appears Catrope has already uploaded a fix; I expect review will be made in time for next Thursday's deployment, if not an earlier SWAP deployment. --Izno (talk) 12:24, 14 December 2017 (UTC)
    But Catrope's fix appears to only be for pages which transclude related changes with code like {{Special:RecentChangesLinked/User:TonyTheTiger/creations}}. If you actually click a Related changes link to a page like Special:RecentChangesLinked/User:TonyTheTiger/creations then you get the similar but not identical problem reported in the following section. The page name User:TonyTheTiger/creations is for some reason (bug?) split into User:TonyTheTiger and creation when the url is rewritten to something like []. When you reload (or just click the above url directly) the url is rewritten to []. Here creation is discarded and User:TonyTheTiger moves to the target parameter. I don't know how those url's are supposed to look but something goes wrong when they are rewritten. Catrope's fix is simply to not rewrite them at all when Special:RecentChangesLinked is only transcluded. PrimeHunter (talk) 15:03, 14 December 2017 (UTC)
    PrimeHunter, thanks for clarifying the technical aspects of my newfound problem. Is there anything that I need to do to encourage reversion of the technology to allow for normal refreshing of this related changes page or is the issue understood and being addressed already.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 13:51, 15 December 2017 (UTC)
    It is finally refreshing correctly.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 16:01, 15 December 2017 (UTC)
    Your issue also works for me now. Special:RecentChangesLinked/User:TonyTheTiger/creations rewrites the url to []. It no longer splits the page name, and the url remains unchanged when the page is reloaded. The problem reported by Jokulhlaup is still there but Catrope's patch has not been deployed. PrimeHunter (talk) 17:35, 15 December 2017 (UTC)

Recent changes changes


When using the Recent changes / Related changes page as of late, the basic URL to which I usually use now automatically gets appended with filter information (for example "?hidebots=1&hidecategorization=1&hideWikibase=1&limit=500&days=30&target=Watchlist&urlversion=2" ) ever since the more specialized filter options app started being used. I've also noticed that if I click a link in the RC page (simple click rather than open a new tab) but then try to return to the RC page by using my browser's back button, I only get on the RC page "No changes during the given period match these criteria." Is this a bug or is there a a setting in my preferences to get the simple RC page back? Thanks in advance. —Mr. Matté (Talk/Contrib) 16:47, 13 December 2017 (UTC)

@Mr. Matté: I moved your post to an existing section about the issue. PrimeHunter (talk) 18:40, 13 December 2017 (UTC)
@PrimeHunter: It doesn't seem like my issue is related to the parent issue. Mine is related to clicking the back button (Firefox 53 BTW at least at this computer) and having information not appear on the related changes page while the parent issue seems to deal with a user sandbox redirect. —Mr. Matté (Talk/Contrib) 21:25, 13 December 2017 (UTC)
OK, maybe there are just similarities. I have returned it to a level 2 heading. I cannot reproduce your result in Firefox 57.0.2. Try posting the full url at each step, including before you click Recent changes / Related changes. PrimeHunter (talk) 23:02, 13 December 2017 (UTC)
At home using FF 47, it seems as though the issue is if there's a / in the article title. Starting with this, clicking on any link and then using the back button, no issues found. Trying out User:Mr. Matté/sandbox, doing a recent changes click like this, going to another link and returning via back brings me to giving the recent changes for User:Mr. Matté. Next trying out the RC page for User:Mr. Matté/sandbox/test here, doing the same procedure ends up giving me the RC for User:Mr. Matté/sandbox. Even non user pages like Wikipedia:WikiProject U.S. Roads/Maps task force/Requests, doing the same procedure for this brings me up one level to RC for Wikipedia:WikiProject U.S. Roads/Maps task force, repeating the iterations from this then gives me the RC for Wikipedia:WikiProject U.S. Roads. I guess it was similar to the previous issue, I only assumed it was different as I got the "No changes..." message (probably because the previous RC page I was using had no links in the next level up). —Mr. Matté (Talk/Contrib) 01:48, 14 December 2017 (UTC)

Like the section above, my issue is resolved. —Mr. Matté (Talk/Contrib) 16:09, 15 December 2017 (UTC)

Title blacklist


Is there a tool to show which row(s) of the title blacklist a proposed title violates? (It wouldn't be hard to write one, but it feels like a wheel that someone wil already have invented.) I'm trying to move {{S-line/MINSKMETRO left/Avtozavodskaya}} to {{S-line/MINSKMETRO left/Aŭtazavodskaja}} but getting a generic "on the title blacklist" message. Knowing the exact problem would tell me whether I'm trying to do something that's been banned for good reason, or just caught by an overzealous regex. Thanks, Certes (talk) 11:44, 13 December 2017 (UTC)

You can look at mw:Extension:TitleBlacklist#Testing_for_matches. Ruslik_Zero 12:41, 13 December 2017 (UTC)
@Ruslik0: Thanks, that's exactly what I needed. The new title is deemed too shouty, as it has more than 9 consecutive capital letters (the same 10 as the old title). Certes (talk) 16:41, 13 December 2017 (UTC)

Structured Commons newsletter, December 13, 2017

Welcome to the newsletter for Structured Data on Wikimedia Commons! You can update your subscription to the newsletter. Do inform others who you think will want to be involved in the project!

Community updates
Things to do / input and feedback requests
A multi-licensed image on Wikimedia Commons, with a custom {{EthnologyItemMHNT}} Information template. Do you also know media files on Commons that will be interesting or challenging to model with structured data? Add them to the Interesting Commons files page.
Presentations / Press / Events
Presentation about Structured Commons and Wikidata, at WikimediaCon in Berlin.
  • Sandra presented the plans for Structured Commons during WikidataCon in Berlin, on October 29. The presentation focused on collaboration between the Wikidata and Commons communities. You can see the full video here.
Partners and allies
  • We are still welcoming (more) staff from GLAMs (Galleries, Libraries, Archives and Museums) to become part of our long-term focus group (phabricator task T174134). You will be kept in the loop of the project, and receive regular small surveys and requests for feedback. Get in touch with Sandra if you're interested - your input in helping to shape this project is highly valued!
  • Research findings from interviews and surveys of GLAM project participants are being published to the research page. Check back over the next few weeks as additional details (notes, quotes, charts, blog posts, and slide decks) will be added to or linked from that page.
  • The Structured Commons team has written and submitted a report about the first nine months of work on the project to its funders, the Alfred P. Sloan Foundation. The 53-page report, published on November 1, is available on Wikimedia Commons.
  • The team has started working on designs for changes to the upload wizard (T182019).
  • We started preliminary work to prototype changes for file info pages.
  • Work on the MediaInfo extension is ongoing (T176012).
  • The team is continuing its work on baseline metrics on Commons, in order to be able to measure the effectiveness of structured data on Commons. (T174519)
  • Upcoming: in the first half of 2018, the first prototypes and design sketches for file pages, the UploadWizard, and for search will be published for discussion and feedback!
Stay up to date!

Warmly, your community liaison, SandraF (WMF) (talk)

Message sent by MediaWiki message delivery - 16:32, 13 December 2017 (UTC)

File usage problem

Afternoon, all. File:SarekOfVulcan with Bag Balm.jpg, under File Usage, states "No pages on the English Wikipedia link to this file." What Links Here, on the other hand, shows that it was linked from at least two discussions, using the :-syntax used above. This has caused it to be tagged twice (and deleted once) as an orphan file. Should the File Usage be fixed, or should the bot use different criteria, or what? --SarekOfVulcan (talk) 21:09, 13 December 2017 (UTC)

A link is not a file usage and thus the image is indeed an {{orphan image}}. However that is not an automatic reason for deletion, but I guess stuff easily slips through. I would either move it to Commons, or mark it with {{keep local}}. —TheDJ (talkcontribs) 21:23, 13 December 2017 (UTC)
How about {{Esoteric file}}? --SarekOfVulcan (talk) 21:30, 13 December 2017 (UTC)
I can see how the text written under "file usage" can be confusing. Might it be better to use the word "transclude"? Or more simply, "display"? Killiondude (talk) 21:28, 13 December 2017 (UTC)
Display would be clearer, yes. --SarekOfVulcan (talk) 21:30, 13 December 2017 (UTC)
I have long wondered why it says "link to" this file instead of display or use. The message is MediaWiki:Nolinkstoimage. We have customized it but the MediaWiki default at MediaWiki:Nolinkstoimage/qqx also says "link to", and the message name hints it's supposed to say that. PrimeHunter (talk) 23:13, 13 December 2017 (UTC)
That message is also displayed for audio and video files, so it seems something like MediaWiki:Nouseoffile or Notusedfile would be a better name. --Pipetricker (talk) 13:23, 14 December 2017 (UTC)
"Display" may seem to be the wrong word for audio files, but all used media files have a visual representation on the page, so I think "No pages on the English Wikipedia display this file" would be a good wording. --Pipetricker (talk) 13:23, 14 December 2017 (UTC)

Editing templates

When editing a template like "Template:Jesuits", does it take time for the edits to take effect in articles where it is used, or must something else be done to make the edits take effect? I find the template wasn't affected in articles, like Society of Jesus. Jzsj (talk) 22:23, 14 December 2017 (UTC)

@Jzsj: yes, you can WP:PURGE the pages to get it to update right away. — xaosflux Talk 22:24, 14 December 2017 (UTC)
Purging updates the display of the page on your computer only. If you made a change that involves categorization or something similar, you need to WP:NULLEDIT the page in question (click edit and then save without changing anything). – Jonesey95 (talk) 23:00, 14 December 2017 (UTC)
Jonesey95 you linked to the same page I did :p — xaosflux Talk 23:16, 14 December 2017 (UTC)
Purging updates the display of the page on everyone's computer (except for categories and "What links here"), since it clears the cache on the server. --Pipetricker (talk) 08:49, 15 December 2017 (UTC)

Thank you all. I think this did it. Jzsj (talk) 00:42, 15 December 2017 (UTC)

@Jzsj: The other way is to simply wait, see Help:Job queue. --Redrose64 🌹 (talk) 20:36, 15 December 2017 (UTC)

Impossible lifespans

I just now almost assigned someone to an impossible lifespan: the person lived 1871-1948, but thanks to a typo I almost put him in Category:1871 births and Category:1848 deaths. I vaguely remember there being something on the Toolserver that tracked articles of people who died years before they were born, but (a) was there such a tool, (b) if so, is it still around, and (c) if so, where is it? Nyttend (talk) 16:00, 15 December 2017 (UTC)

@Nyttend: Wikipedia:Database reports/Unbelievable life spans might be what you are remembering, but it hasn't been updated recently. -- John of Reading (talk) 17:25, 15 December 2017 (UTC)
Thank you. The updating bot is still active, so I've asked the operator to start handling this task again. Nyttend (talk) 01:30, 16 December 2017 (UTC)

Error with italicized Cyrillic names

Resolved: Answered, thank you. Jip Orlando (talk) 17:16, 15 December 2017 (UTC)

In looking through random articles, I've noticed that many Cyrillic names are displaying the following error: (error: {{lang-xx}}: text has italic markup (help). Here is an older revision of an article that has this error: [] And a diff displaying what I did: []

Did something happen in the with the markup that now displays this problem? There appear to be many articles that now display this error flag. I'd be happy to fix on sight but if they don't need to be modified it would be easier. Thank you! Jip Orlando (talk) 16:10, 15 December 2017 (UTC)

There is a lot of change happening with the {{lang}} template. See Template talk:Lang. – Jonesey95 (talk) 16:20, 15 December 2017 (UTC)
The error message has a (help) link, which takes you to the tracking category page Category:Lang and lang-xx template errors, which is informational, in particular: § italic markup errors. --Pipetricker (talk) 16:39, 15 December 2017 (UTC)

Obscure problem with Template:Cite certification and asterisk in a parameter

I appear to be having a problem with Template:Cite certification that I am unable to figure out. When I put "*NSYNC" into the |artist= parameter and the region is Germany, the template appears to replace the asterisk with a line feed and an asterisk, which causes an undesirable white space in the title parameter along with a red error message. When I replace the asterisk with its corresponding HTML entity number, it works fine. Can anyone explain what is going on here, and if there is a way to fix the template?

Region Certification Certified units/Sales
Germany (BVMI)[1] Gold 250,000^
Germany (BVMI)[2] Gold 250,000^

*sales figures based on certification alone
^shipments figures based on certification alone


  1. ^ "Gold-/Platin-Datenbank ( *NSYNC; '*NSYNC')" (in German). Bundesverband Musikindustrie. Retrieved 25 July 2012.  line feed character in |title= at position 25 (help)
  2. ^ "Gold-/Platin-Datenbank (*NSYNC; '*NSYNC')" (in German). Bundesverband Musikindustrie. Retrieved 25 July 2012. 

Thanks for any help you can provide. – Jonesey95 (talk) 22:14, 15 December 2017 (UTC)

It's the issue at Help:Template#Problems and workarounds. You found the right fix in the call. A possible fix in templates is mentioned at Wikipedia:Village pump (technical)/Archive 158#Template:la and wikisyntax but it's not ideal and hasn't been used in practice as far as I know. PrimeHunter (talk) 22:31, 15 December 2017 (UTC)
Thanks. I figured it was something like that, since the asterisk is treated specially by WP. I don't think that description fully described the effect here, since the asterisk was not the first character of the template or of a parser function. I have amended the text to describe it more fully (and possibly incorrectly; correct it if I got something wrong) and to add words that describe these characters so that searching within WP might turn up this paragraph as a result. – Jonesey95 (talk) 22:53, 15 December 2017 (UTC)
Help:Template#Problems and workarounds is talking about the first character produced by a template or parser function. I have clarified this and added: "The problem often occurs when a parameter value in a template call starts with one of the four characters."[50] The caller of the template does not know how the template processes the parameter so it's unpredictable for the caller whether the problem happens. PrimeHunter (talk) 23:39, 15 December 2017 (UTC)

Clicking "Show preview" publishes the edit

About a half dozen times or so over the past few weeks, when I click "preview" to review changes I've made, the page saved (or "published") instead. If it was only once or twice, I could see it possibly being my error, (as in, I thought I clicked 'preview' but actually clicked 'save'), but I am now certain that this issue is with the site, that clicking 'preview' did result in the page saving my changes. Anyone got any advice on what I should do about this? (if there's anything I can do, that is). Thanks - theWOLFchild 23:58, 15 December 2017 (UTC)

It doesn't happen for me and I don't know what causes it for you but you could try to separate the buttons more with code like this in your CSS:
#wpPreview {margin-left: 10em;}
PrimeHunter (talk) 00:11, 16 December 2017 (UTC)
Hi, I appreciate the reply, but I am certain that some of the pages I've edited have saved when I clicked the 'preview' button, so while your suggestion may be helpful (and I will try it), it doesn't address the problem. I'm just wondering if there is anything else I can or should be doing? I'm also curious if anyone else has experienced this issue. Thanks - theWOLFchild 00:31, 16 December 2017 (UTC)


Proposal for a better article assessment process

The wikipedia ratings for articles go (from highest to lowest): FA, Good, A, B, C. Start, and Stub. Seven ratings in all. I've created more than 120 articles which have been rated B, C, or Start -- and all of those 120 articles are of similar quality, covering in my opinion the subject as thoroughly as it need be covered in an encyclopedia and being comprehensible to the average reader. In other words the assessment of the articles I have written has been arbitrary depending more upon the reviewer than the quality of the work. Yeah, I know you can claim that the rating system is objective....but it isn't. Different people come to different conclusions about what they see and read.

Rather than expend the time of reviewers trying to decide whether an article is A, B, C, or Start, rather than undergoing the water-torture of trying to determine what is "Good" and what is "FA", the whole system should be imploded. I suggest there be only one rating for an article: "Good", a rating achieved only after a careful and continuing review of the article by experienced Wikipedians. All articles not judged as "Good" would be unrated. For inaccurate or misleading articles, the article could be tagged as they are at present as dubious or lacking references or whatever.

I would guess that 95 percent of wikipedia readers never go to the talk page to see how an article is rated, and thus the rating system is not very important. Why, therefore, complicate it with a plethora of ratings which nobody cares about -- except the article creator who is more likely to be insulted than complimented by the rating his beloved article receives (I speak from experience).

Moreover, I would propose that a "Good" article have a note to that effect at the top of the article -- and that the "Good" rating not be relegated to the talk page that nobody looks at. That would give credit and prominence to editors for their work and a "Good" rating would give confidence to the readers that what they are reading is accurate, neutral in tone, and complete.

Another reason for simplifying the rating system is that articles change in quality over time -- going from poor to good and from good to poor as different edits are added. Yet, articles are rarely reassessed -- or only after years. Thus, even if you are the rare reader who looks at the talk page to see how an article is rated, the rating is likely out of date.

Let's expend our efforts to try to increase the number of "Good" articles on wikipedia -- and keep them "Good", rather than worry about whether an article is an A or B or C or Start or Good or FA.

"Out of clutter find simplicity": Einstein. Smallchief (talk) 19:21, 30 November 2017 (UTC)

Wikipedia:WikiProject Council/Assessment FAQ. Article assessments aren't for readers, they're for helping Wikiprojects prioritize which articles are most in need of work. ("[T]hese ratings are meant primarily for the internal use of the project, and usually do not imply any official standing within Wikipedia as a whole.") "Good articles", however, do have their status shown at the top of the page, to the right of the title. --Yair rand (talk) 19:37, 30 November 2017 (UTC)
A minor point, but A-class is a higher rating that GA.
More significantly for your proposal, GA and FA ratings are already indicated on the main page of an article: you can see the little bronze star/green plus mark at the top right-hand corner of a Featured or Good article. (See Sappho or Emily Davison for examples of GA and FA respectively).
Start/B/C ratings are at best inconsistently applied, and I can see very little downside to scrapping them (in theory, they are useful for editors knowing which articles they are interested in are most in need of improvement; in practice they are inconsistently enough applied that they aren't actually that useful).
Any proposed system of ratings which scraps all of the current ratings and sets up a new standard for what is a "Good article", though, must propose a set of criteria for it to be judged by. Are we going to keep the current GA system? Because while not as fundamentally broken as the start/C/B rankings, that has its own problems. Caeciliusinhorto (talk) 19:50, 30 November 2017 (UTC)
Well, thanks for telling me. I've done 26,000 edits on Wikipedia and I never noticed that little star that tells you it's a Good or Fine article. I doubt that anybody else has either. Let's put a notice at the top of the article that everyone can see and read saying that Wikipedia considers this a "Good" article.
Maybe the first step in the simplification process would be to combine B, C, and Start reviews into a single category as they are arbitrary -- and it's not really very useful to distinguish among them. Smallchief (talk) 20:02, 30 November 2017 (UTC)
I've said this variously before, but I would totally be in favor of switching to something like Stub, Article, Good Article, Featured Article. GMGtalk 20:07, 30 November 2017 (UTC)
That sounds good to me. Smallchief (talk) 20:09, 30 November 2017 (UTC)
Having said that, even if this could get consensus, I have no idea how much work it would take to piece together a bot that could change the current rating conventions on 5.5 million article talk pages and lord only knows how many associated template. Ping... uh... User:Primefac. GMGtalk 20:18, 30 November 2017 (UTC)
Writing the bot is easy. Getting consensus for having that much spam in people's watchlists would be difficult. power~enwiki (π, ν) 20:20, 30 November 2017 (UTC)
Bots on a watchlist? Eww. GMGtalk 20:23, 30 November 2017 (UTC)
I'm sure you could just point the B and C parameters of those templates to point to a different categorization without needing to edit every talk page. Nihlus 20:25, 30 November 2017 (UTC)
  • I'd support something like this. B and C class ratings mean absolutely nothing. In my mind there are four classes: Stub, Start, GA (writing roughly equivalent of a B+ on a Grade 8 book report), and FA. Also, pinging Iridescent, who has said sensible things on this in the past. TonyBallioni (talk) 20:22, 30 November 2017 (UTC)
    • The existing assessment scale is the result of long-abandoned WMF schemes to release print and CD-ROM versions of Wikipedia, and consequently the need to syphon off "only the best" and "only the adequate". I'd quite happily see it deprecated altogether with the exception of "stub" (which is a de facto maintenance template rather than an assessment as such) and some "this has been through a full review" equivalent of FA. (WP:GA is a complete trainwreck and I'd vehemently oppose any attempt to broaden its scope; it's second only to WP:DYK as the haunt of obsessives and cranks.) I find it extremely unlikely that you'll ever get consensus for such a change, as so many people have so much of their on-wiki identity invested in conducting this kind of "this article is currently listed as B class, I reclassify it as C class" timewasting that they'll fight any proposal; likewise, those projects like WP:MILHIST that still operate A-class reviews will turn up en masse to oppose, and consequently even with a couple of hundred people supporting deprecation you'll still end up with "no consensus". Incidentally, all GAs and FAs already note this fact at the top of the article—not relegated to the talk page that nobody looks at—and have done so for years. ‑ Iridescent 20:37, 30 November 2017 (UTC)
  • I've long harboured a suspicion that most people who do WikiProject assessments haven't actually read the criteria. I've gotten used to my perfectly adequate B-classes being cruelly slandered as a "Start", but I've come across several new editors who have genuinely found it galling, and if you read how the quality scale describes start you can see why. A scale of Stub->Article->Good Article->Featured Article would be a better reflection of how assessments really work for all but a few very active WikiProjects (looking at you, WP:MILHIST). And I think you could achieve it without a bot: simply change the templates so that setting |quality= to B, C, or Start displays as the same thing and sets the same category. – Joe (talk) 21:33, 30 November 2017 (UTC)
  • The great majority of graders do so entirely based on length, and perhaps basic English proficiency, often taking only a few seconds. Stub and start are useful to the tiny number of people who look at the top-views-per project lists (Category:Lists of popular pages by WikiProject) for poor but highly-viewed articles to improve. Of course C & B are pretty variable, but then so are GAs. Most grades are much too cautious, if the supposed standards are taken seriously. I'm not sure it's worth the effort of changing anything. I'm entirely unabashed in self-assessing up to B, though I say so in the edit summary. Johnbod (talk) 03:48, 1 December 2017 (UTC)
  • Support some kind of compression. A 4-step rating as proposed by Tony and GMG is much more useful and cuts down on arbitrary ratings. B vs C is particularly pointless. ♠PMC(talk) 04:40, 1 December 2017 (UTC)
  • Support a scale of Stub→Medium→Good→Excellent with 'Excellent' replacing GA, A, and FA, Good replacing B, B+, and Cs without maintenance templates, Medium replacing Start, Non-stubby futures and currents, and Cs with templates, Stub stays the same. List stays the same and FL replaced with GL... That is a lot of changes that I want. J947 (c · m) 05:02, 1 December 2017 (UTC)
  • Support the proposal by TonyBallioni and others to streamline the ratings by eliminating B and C. I disagree with Tony, though, about the difficulty of writing a GA as opposed to writing a school book report. I have spent vastly more time and effort writing my handful of GAs than on any routine school paper, most of which received A grades half a century ago. I also believe that the stub rating, though useful if used properly, is way over-used. I frequently see articles that are far beyond stubs in quality with stub ratings. Thanks to Smallchief for raising this issue. Cullen328 Let's discuss it 05:15, 1 December 2017 (UTC)
    • Some GAs are quite good and much higher quality writing than that, but the process as currently designed is meant to be a lightweight process that makes sure that the article has basic grammar and style down and covers the major aspects of a topic, without requiring it to be comprehensive. It really depends on who the reviewer is and who the primary author is. My remarks weren’t meant to be snarky, just trying to find an example of around what the low end of the GA standard was. TonyBallioni (talk) 05:26, 1 December 2017 (UTC)
  • Support some kind of change. Personally I'd like to see A (for current FAs to remove the idea that it must be featured on the main page), B for current GAs (meaning there has been some kind of review), and start- or stub-class for everything else. But I'll go along with any proposal to streamline. SarahSV (talk) 05:27, 1 December 2017 (UTC)
    • Personally, I find the "B" rating useless (I still don't really know what makes a "B"-article a "B", and I've been here for years!) But I think we need a rating between "Start" and "GA" – something akin to the current "C"-grade... So I guess I'd support a 5-rating system: "Stub", "Start", some kind of "mid"/"C"-quality rating, and then GA and FA (the latter two of which I tend to be somewhat skeptical about, but that's me...). --IJBall (contribstalk) 01:12, 2 December 2017 (UTC)
      What makes a B article a B is that it is fully referenced; covers the topic; has a defined structure, including a lead section and one or more sections of content; the grammar and spelling is acceptable; and has appropriate supporting materials, such as an infobox, images, or diagrams. Failure in any of these criteria results in a C rating. Failure of more than one will result in a Start rating. The GA rating is on the very same criteria, and is nominally slightly higher on each; but in practice the difference is the degree of detail the reviewer is being asked to check. For most purposes, B and GA are interchangeable. Similarly, starts and stubs are normally considered unacceptable at DYK and ITN. Hawkeye7 (discuss) 22:25, 2 December 2017 (UTC)
      My point was is that I find the distinction between "B" and "C" to effectively be negligible or meaningless – what you seems to be calling a "B" article I consider a "C"-class article. (Basically, as far as I can tell, "C" articles just tend to be "B" articles that are a little shorter in length...) However, the problem with "B" is that there is a fair amount of editor disagreement as to what constitutes "grammar and spelling is acceptable" (esp. the former). If we're going to simplify the ratings system, merging the "B" and "C" ratings would be a very good first step IMO... --IJBall (contribstalk) 16:16, 3 December 2017 (UTC)
  • Support So how do we move forward on a formal proposal to simplify the rating system? I don't have the technical ability nor the knowledge of Wikipedia procedures to advance a proposal. Smallchief (talk) 10:12, 1 December 2017 (UTC)
  • Support a change to a three or four step system for articles (Stub, one or two "mid-quality", and "Excellent"). (Note that there are classes for redirects, SIAs, categories, templates, portals, etc. in at least some wikiprojects. I don't support changing these, which are simply descriptive.) However, I think it's a massive change to make: it's not only all the articles, but also the information about assessment at every wikiproject. Peter coxhead (talk) 10:35, 1 December 2017 (UTC)
  • Comment--That the spirit of the changes have got broad local support from the VPP frequents, it's time that this disc. be converted into a RFC and widely advertised as the prelim. steps to gauge the gen. consensus.But, some fine-tuning of the options to be floated etc. may be necessary. Regards:)Winged Blades Godric 10:41, 1 December 2017 (UTC)
  • I don't think the start/C distinction is useful to anyone. "B", however, at least (in theory) checks the article against a list of criteria that should be satisfied, and some assessment templates (I am aware of WP:MILHIST and WP:GER) contain the checklist in the template. But the main question is what we use the assessments for. I think many WikiProjects don't have the manpower to do anything useful with them whatsoever, and for them fine assessment levels are useless. It may be worth inviting someone from WP:MILHIST. A couple of years ago, when I last cared about assessments, they were the people with the best-run assessment program. —Kusma (t·c) 11:19, 1 December 2017 (UTC)
  • Extended comments - First, it's probably better to discuss here rather than !vote, since as Godric points out above, this would need to be redone with probably a good deal more structure and likely totally restarted as an RfC. Second, I think messing fundamentally with the GA and FA processes is just a sure fire way to sink any kind of proposal. Those more or less "belong" to the users who are investing in keeping them going, and changes there, to be successful, need to come from the stake holders, and not from the sidelines.
On a more opinionated note, I don't really see a compelling reason to keep start class around. There are, I expect, a great many subjects for which a few paragraphs long article, what many would call a start class, can cover the topic comprehensively in a way that wouldn't stick out at all in Britannica or World Book, and there's nothing wrong with that. It doesn't necessarily need the de facto maintenance template that is a start class rating. C and B on the other hand can be positively counter productive, and anyone who's hung out enough at the Teahouse has come across a new user trying to get their article "promoted" into one of them only to find out that they're nearly totally disregarded by the community.
The up side of combining these three into an uncontroversial "article" class in my mind is that it would make users more likely to accurately rate their own articles for tracking purposes. "Article class" would mean simply that this one can stand on its own without the need for immediate attention, and would hopefully avoid it being more or less a type of badge of honor of any kind. Looking back at my own history, I would be perfectly comfortable rating something like this as "article class" rather than have it sit unassessed until the point where it passes GA, or have something like this, this, or this sit indefinitely as a start class, when I have no intention of further serious work on them in the near future, because they've reached a point where they can well stand on their own two feet, and be beneficial for readers without major attention.
As an added benefit, it may actually help make GA and FA more active in the long run, by emphasizing the point that the assessments aren't terribly useful until you get to the point where you meet some kind of structured peer review. GMGtalk 11:49, 1 December 2017 (UTC)
OTOH, I like your idea of a simple "article" class (which I like as a "non-judgemental" simple descriptor, like "template" or "redirect" class), that would combine "Start"/"C"/"B" – I could easily get behind that kind of idea. --IJBall (contribstalk) 01:16, 2 December 2017 (UTC)
Oppose anything that overules any WikiProject's preferences If you don't like them, don't use them. I find the categorization in WP:PHYS/WP:JOURNALS/WP:ELEMENTS and elsewhere to be perfectly adequate. While individual assessments can always be called into question, there's quite a bit of a difference between a B-class article and a Start-class article. If you object to a rating, simply change it. It may simply have been given a while ago, and no longer reflect the current state of the article, or both you and the original assesser may not have seen the same qualities/deficiencies at the time of assessment. A discussion will resolve those differences, and identify those issues that need to be solves before going to the higher class, leading to article improvement. If projects decide they don't want the fine-tuning of Start/C/B classes, then they can customize their own Wikiproject banners accordingly.Headbomb {t · c · p · b} 13:25, 1 December 2017 (UTC)
  • Strong oppose, even if this were an actual RFC, largely per Headbomb. If you have better things to do, go do them. Some people do use ratings for article improvement drives, and GA/FA are not the pinnacle for all Wikipedians (nor is B the same as C, nor start the same as stub). It's funny though, how C and start were added--they were added to address concerns by users who were not part of the original WP1.0 crew so that there was some fidelity in the lower-quality articles. GA/FA are additionally entirely distinct processes from the letter grades assigned, which are per-WikiProject (though in reality most WikiProjects do not differ much in the grade they assign). --Izno (talk) 13:37, 1 December 2017 (UTC)
  • Did anyone experience the same complaint about the ratings that is mentioned here? Jo-Jo Eumerus (talk, contributions) 13:48, 1 December 2017 (UTC)
    That is great reading. Actually many WikiProjects were founded as part of the WP:1.0 assessment drive. (I was there when WikiProject Germany was founded by someone interested mainly in getting articles assessed, which meant that it quickly grew beyond what anyone could handle, and we have never had the manpower to do very much with the data we created). For the mostly dead WikiProjects, having their own ratings/rating systems is overkill, and instead having project-independent "universal" rating would work better. However, the active WikiProjects don't want anyone messing with their internal structure. In any case, the proposed simplification would mean re-assessing millions of articles, and it is not completely clear to me whether this will achieve anything at all unless we know what we actually want from this data. —Kusma (t·c) 14:29, 1 December 2017 (UTC)
    Something like User:GreenMeansGo's proposal could easily be done by a bot – any article with a "Start"/"C"/"B" rating would be replaced by an "article"-class rating. --IJBall (contribstalk) 01:20, 2 December 2017 (UTC)
  • Oppose: Not only does the proposal get the assessment hierarchy wrong (A-class is above Good), it also suggests things that are already implemented (Good articles do have "a note to that effect at the top of the article"). Sure, article assessment gets it wrong sometime, particularly because initial ratings are not promptly revisited even if the article undergoes substantial change. But the proposed process does not remedy this inherent flaw; we do have FA and GA delisting processes that indeed make reassessment even slower because they involve a mandatory discussion. Ratings are there primarily for us editors to keep track of our priorities, not so much for the readers. For the editor's purposes we need a scheme that is more nuanced than just Good and "bad" articles. No one wants to specifically read a half-finished C-class article (in comparison to a full-fledged FA or a miserable Stub). But many editorial tasks are ideal for that middle ground; most of our editing is neither complete rewrite of Stubs or extremely conservative tweaking of FAs that have consensus for each word in the article. – Finnusertop (talk