Wikipedia:Village pump (policy)/Archive 138

Add links
From Wikipedia, the free encyclopedia
Village pump (policy) archive  

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

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

Medical advice on user / user talk pages

We have both WP:MEDICAL/WP:RD/G/M which covers basically mainspace/Wikipedia space, but how do we go about users giving each other medical advice on user talk page, e.g. stuff like this? Headbomb {t · c · p · b} 21:46, 21 October 2017 (UTC)

The disclaimer warns users not to believe stuff like this; it doesn't prohibit posting it. And obviously the Refdesk guidelines, if they apply anywhere, don't apply to talk pages. And nobody is going to spot this stuff often anyway. Best thing to do is stay out of it, unless there is a pattern that supports an allegation of commercial spam. Of course, nothing prohibits you from saying "don't believe any of this" on a talk page yourself. Wnt (talk) 21:55, 21 October 2017 (UTC)
Maybe that disclaimer should be quoted in full, anytime an OP asks for medical advice. ←Baseball Bugs What's up, Doc? carrots→ 21:58, 21 October 2017 (UTC)
Those two linked disclaimers are about articles and refdesk. You'd need something a little different. Maybe a big red flag saying something like "Warning: only listen to doctors about health issues, because everyone else might have a conflict of interest", posted on every talk page where someone offers health or medicine advice, would draw attention away from these dangerous discussions. Dicklyon (talk) 22:03, 21 October 2017 (UTC)
Speaking of which, Conflict of interest in the healthcare industry is barely more than a stub, and there's nothing in there about, e.g., overuse of tests that involve newly purchased expensive equipment, referrals to facilities owned by the prescribing physician or that pay kickbacks, or the ethical problems of recruiting patients into clinical trials run by the physician. There are other under-developed articles as well. For example, Thought leader unaccountably doesn't mention physicians targeted by pharmaceutical companies to promote high-priced drugs (e.g., in local medical association meetings), even though "you're a local thought leader" is the excuse that the targeted physicians are fed to explain why the pharma company is giving them so much personal attention. We are missing quite a lot of information about medical ethics. WhatamIdoing (talk) 01:34, 22 October 2017 (UTC)
Oh, and we need Conflicts of interest in dentistry. I had, but can no longer lay my hands on, an in-depth news source on the difficulties of getting dental care to poor American children. One of the problems? In some US states, it is illegal for a non-profit organization(!) to provide dental services unless the CEO/Executive Director is a licensed dentist. Why? Well, the dental association says that people get better care when the treatment recommendation is being made by someone whose mortgage payment depends upon upselling you on cosmetic procedures, rather than by a dentist on a fixed salary who can work full time with patients instead of spending most of his time running a business and fretting about making ends meet.
This source: Jordan, Mary (2017-07-01). "The unexpected political power of dentists". Washington Post. ISSN 0190-8286. might also be useful for building such an article. The widespread practice of making (mostly female) dental hygienists in the US work only in dentists' offices (and frequently making them cobble together several part-time jobs around town, because no dentist wants to pay benefits like sick leave and health insurance when he could have five part-time hygienists instead of two full-time ones) and prohibiting them from doing things like sealing teeth is another sign of how COI in that industry isn't being managed appropriately. Basically, if anything happens to your teeth, the local business owner with a dental license expects to get a share of the profits. WhatamIdoing (talk) 22:16, 22 October 2017 (UTC)
Just googling for the phrase medical advice gave me "WebMD does not provide medical advice, diagnosis or treatment"[1]. Our own article says Medical advice is the provision of a formal professional opinion regarding what a specific individual should or should not do to restore or preserve health. It's not some random stranger on the Intertubes saying "Take lemon juice with hot water". I'd say the panic about possibly giving "medical advice" is mostly due to a cultural meme that does not reflect any real legal (or moral) problem. The disclaimer makes it clear that whatever you find on Wikipedia is not "medical advice" (in the legal sense) and should not be mistaken for it. --Stephan Schulz (talk) 22:09, 21 October 2017 (UTC)
  • I checked to see if that link is being spammed and it isn't. I think that person was just being funny. Or maybe they thought they were being helpful. Or maybe it was a weird form of gravedancing... hard to say without understaning the interaction. But i don't think it is particularly something to be concerned about with respect to medical advice. Jytdog (talk) 22:23, 21 October 2017 (UTC)
  • My own POV (subject to change without warning, etc.): I think we should stay out of it. It's not hateful or vandalism or something obviously destructive like that, so if someone posted something like that on my talk page, then I would want you to let me handle it. I assume that if it were your talk page, then each of you would also want the right to respond, or not, in the way that you thought best. So I suggest leaving it alone. WhatamIdoing (talk) 01:21, 22 October 2017 (UTC)
  • There is one bit of medical advice that is never wrong, and that we SHOULD give: “Consult a doctor”. Blueboar (talk) 02:09, 22 October 2017 (UTC)
    • At the ref desk, it has been generally agreed in past that the best phrasing is, "If you're concerned, consult a doctor." ←Baseball Bugs What's up, Doc? carrots→ 02:20, 22 October 2017 (UTC)
  • We can't regulate everything. If you get medical advice on a user talk page, don't follow it if it contradicts what your doctor says. If you do follow it anyway, maybe that's just Darwinian selection. --Tryptofish (talk) 22:06, 3 November 2017 (UTC)

Rename the Notability guideline

  • The dictionary definition (according to Google Define - based on the Oxford Dictionary):
notability
nəʊtəˈbɪlɪti/
noun
noun: notability

    the fact or quality of being notable.
    "the village enjoys a notability out of all relation to its size"
    synonyms:	noteworthiness, momentousness, memorability, impressiveness, extraordinariness;
    prominence, importance, significance, eminence;
    fame, publicity, renown, notoriety, stature, media attention/interest
    "the village has always enjoyed a notability out of all relation to its size"

dated
        a famous or important person.
        plural noun: notabilities
        "a Fleet Street notability"
        synonyms:	celebrity, public figure, important person, VIP, personality, personage, notable, dignitary, leading light, star, superstar, name,
        big name, famous name, household name; lion, worthy, grandee, luminary, panjandrum;
        informal: celeb, somebody, bigwig, big shot, big noise, big cheese, big gun, big fish, biggie, heavy, megastar;
        informal: nob;
        informal: kahuna, macher, high muckamuck, high muckety-muck
        "the enterprise enjoyed the patronage of notabilities and aristocrats"
        antonyms:	nonentity
  • Our definition (simplest definition - WP:GNG):
"If a topic has received significant coverage in reliable sources that are independent of the subject, it is presumed to be suitable for a stand-alone article or list."
  • Issue: Any word we could use would cause a similar issue, as all words have a established meaning already, notability is sort of close to our usage, so nothing seems better.
  • Possible Solution: Invent a new neologism specifically for this purpose. Or, change an existing word to show it is not being used with its normal use - example: Wikinotability, or Wikirelevance (adding Wiki to the word makes it clear we are using it for a specific purpose. Like how we are an encyclopedia called Wiki - pedia. showing how we are better than a normal encyclopedia. This could be taken further to: Wikiability, or Wikivance, these are clearly created to be diffrent, rather than just adding Wiki. We have alreaady done this with words such as 'Wikilinks'.
The only disadvantage is that people would need to read the policy to know what it means, so it would require editors to use more Wikilinks to allow easy reference, this could be solved by a template (like {{WPN}} which would subst: a wikilink in place without having to type it out in full.
Dysklyver 08:31, 1 October 2017 (UTC)

Discuss

  • Oppose any change, obviously; as clear a solution to a non-existent problem as ever I've seen. The actual definition of "notability" used at WP:N (worthy of notice) tallies with the actual definition in the OED as opposed to "Google Define - based on the Oxford Dictionary" (Noteworthiness, distinction, prominence; an instance of this). There are justifiable discussions to be had over some of the terminology used by Wikipedia, such as "reliable", but "notability" is clearly the best word to use to describe "de we consider something notable?". ‑ Iridescent 08:58, 1 October 2017 (UTC)
I assume you are aware that the notability policy is stated as being the requirement for sources, rather than the subject being 'worthy of notice', for example: My granddad was a highly prominent judge, community leader of distinction etc, definitely 'worthy of notice', yet there are no surviving reliable sources that mention him at all. According to your definition, he would pass WP:N.
My argument is primarily based on WP:WHYN, which is relevant reading and explains how the WP:N policy is based on WP:V, the requirement for WP:N does not include the requirement for something to be notable (which is an exact synonym of 'eminence & fame'). This is a separate consensus often used at the same time.
Your assertion here is based primarily on a relented consensus based on WP:NOT (don't include everything that is verifiable as Wikipedia is not a indiscriminate collection of information), this is not part of the notability guideline itself, although it could become so given it's widespread use.
Your comment only reinforces the point that the notability guideline is often confused with the actual definition, and that it needs to be dealt with, I would not put this forward if it were a non-issue. Obviously you can easily understand the guidelines, as most people posting on this board do, but this is not clear to newcomers. Dysklyver 09:31, 1 October 2017 (UTC)
WHYN is not part of the guideline as such.  Historically, people had the idea to make WP:N a content guideline, but the idea doesn't work.  The idea is circular reasoning, that a topic is notable if there is an article for it on Wikipedia.  The idea also competes with our core content policies, including DEL7 within deletion policy.  Unscintillating (talk) 10:46, 2 October 2017 (UTC)
How is WHYN not part of the guideline? It certainly is part of the guideline, since it is included in the guideline page, and is there by consensus. There is nothing on that page that says - "this is not part of the guideline" or "this is only FYi". This is the kind of stuff that confuses new Wikipedians, not the word "notability". --Steve Quinn (talk) 02:59, 3 October 2017 (UTC)
  • Oppose, I don't see how/why another word, or a neologism would be clearer than a particular reading of an existing term. I know there is sometimes confusion when something is borderline notable, but I don't believe this would help, since the 'confusion' is often caused by editors preferring their own definition to WP's. Pincrete (talk) 11:45, 1 October 2017 (UTC)
  • see [2]. Dysklyver 13:08, 1 October 2017 (UTC)
  • Oppose. Attempts to rename "notability" basically are perennial proposals that have never gone through because of how ingrained the term is here. --MASEM (t) 13:13, 1 October 2017 (UTC)
  • Do I wish we had come up with a different title back when we created the guideline... yup. WP:Notedness (for example) would have more accurately described the concept that we were trying to express - that a topic needs to have been already noted by sources, as opposed to the topic being "worthy of notice"). However, that is water long under the bridge. It is too late to change the title now. A rename would cause more confusion than it would resolve. Blueboar (talk) 13:57, 1 October 2017 (UTC)
I suggest seppuku.[FBDB] EEng 22:06, 1 October 2017 (UTC)
Dying for change....ClubOranjeT 01:09, 2 October 2017 (UTC)
  • Support - are you all blind? this is fooling new Wikipedians, I was fooled until recently. Suggestion, change to "Sourceability" - ZLEA (Talk,Contribs) 20:08, 1 October 2017 (UTC)
  • I'm blatantly canvassing for contributions to my stub essay WP:Noted not notable. EEng 22:44, 1 October 2017 (UTC)
  • Noted is still "crap", its literally meaning is well known; famous. noted define, I prefer basic Wiki-Notability. Dysklyver 22:48, 1 October 2017 (UTC)
  • "Wikinotability" might work.  I tried using lower case "wp:notability" for a while, but more recently I've been using "Wikipedia notability".  That would be another proposal to rename the guideline, too, WP:Wikipedia notability.  Unscintillating (talk) 10:59, 2 October 2017 (UTC)
  • We could spell it backwards, ytilibaton (ybaton for short), and maybe then every sportsperson who walks onto a professional field will have to do just a little more to earn their ytilibaton. Randy Kryn (talk) 12:03, 2 October 2017 (UTC)
    • On a side note, sports-specific guidelines for league-based sports do not presume that all professional players meet English Wikipedia's standards for having an article. Only players from specific leagues (either by name or by their level of competition) qualify for this presumption. Additionally, sports-specific guidelines explicitly defer to the general notability guideline, and so the existence of an article can be challenged on the basis that the general notability guideline is not met. Admittedly it is a difficult matter to prove, given English Wikipedia's lack of a deadline to complete articles. isaacl (talk) 03:30, 5 October 2017 (UTC)
  • Oppose - Notability is already part of the culture and seems adequate. —PaleoNeonate – 02:00, 3 October 2017 (UTC)
  • Oppose - I agree that "notability" serves our purpose. A change to a neologism is a good idea, but it is no better than "notability". Too bad this idea for a neologism didn't win the day when the content policies and WP:N were morphing and flexing many years ago. "Notability" is ingrained in our culture. If in practice we were drifting away from what we do now then this would be grounds for a change.
And has been pointed out, "notability" is no better or worse than any other word - because they all have common definitions. New Wikipedians should not have a problem with this if they take the time to read WP:N all the way through and even study it for more than five minutes, and click on some of the wikilinks there. And I like the fact that we are in agreement with the OED definition. Steve Quinn (talk) 02:38, 3 October 2017 (UTC)
  • As coincidence may have, I just received a query on my talk page asking if a topic was now "noticeable enough" and had "significant attention" to have the article restored I deleted a while ago. That plus comments I regularly see at AfD indicate that "notability" may indeed be ambiguous enough for people less familiar to mistake it for "famous" or the like (fame often implies to coverage by non-reliable sources, so it isn't exactly synonymous). I don't know is "sourceable" is necessarily better though. Jo-Jo Eumerus (talk, contributions) 15:03, 3 October 2017 (UTC)
  • Oppose - A lot is going on right now in terms of policy change discussions here, this shouldn't take priority. - Knowledgekid87 (talk) 15:17, 3 October 2017 (UTC)
  • Comment The OED definition of "notable" has been mentioned above "Worthy of attention or notice; remarkable." [3]. Dictionary.com defines "notable" as:
  1. "worthy of note or notice; noteworthy"
  2. "prominent, important, or distinguished"
  3. "a prominent, distinguished, or important person"

[4]

It seems to me this is what we strive for while editing on Wikipedia. It does not seem to be a mistake that "notability" was selected. ---Steve Quinn (talk) 04:06, 4 October 2017 (UTC)
  • Support - "Inclusion criteria" would be a much better way of describing what we currently call notability. -- Ajraddatz (talk) 00:02, 11 October 2017 (UTC)
    @Ajraddatz: being notable isn't our only "inclusion criteria" (e.g. WP:V is also an inclusion criterion), perhaps something else? — xaosflux Talk 00:36, 11 October 2017 (UTC)
    It might make sense then to merge the two into a page entitled "inclusion criteria", i.e. to meet a certain standard of importance and to have reliable sources confirming that standard. Now, I have no expectation of the community wanting this to happen. But "notability" is one of those words we love to use here (along with "need" at RfXs, as if anyone needed any advanced permissions) that I don't think accurately reflects to the public what we want it to. When we say the subject of an article should be notable, we mean that the subject should meet a certain guideline of importance that we have established in order to be included. Notability as an idea is heavily subjective, and using a word or phrase that better reflects the fact that we have established a guideline by consensus would seem ideal to me. -- Ajraddatz (talk) 05:03, 11 October 2017 (UTC)
    How about "Importance" - sort of the same problem as notability, it is not easily "measured" though. — xaosflux Talk 02:35, 14 October 2017 (UTC)
    Xaosflux, this feels like the appropriate spot to insert my standard complaint that people misunderstand that the GNG is not about importance, it is about verifiability (WP:V). The SNGs are about importance (WP:NOTINDISCRIMINATE), and any real notability reform will be in a direction that leads us towards a more robust system of subject-specific criteria that help us determine notability/importance, with the GNG serving really as a test of WP:V. TonyBallioni (talk) 03:00, 14 October 2017 (UTC)
  • Oppose I understand the intent behind this proposal. There are frequent conversations where editors have to explain the difference between wiki notions of notability and wider understanding of that term. That said, wiki-notability is merely a subset of general notability with a tighter and (slightly) more-objective definition. This is a common feature of the English language and creating a neologism to bridge the gap won't solve it. We'll still be explaining what "Wikiability" or whatever means to others. Eggishorn (talk) (contrib) 02:53, 14 October 2017 (UTC)
  • Oppose pointless as of now because we are still working out the tensions within WP:N between the GNG and the SNGs. Until we have a system like I described in my reply to Xaosflux above, the notability guideline will continue to be in tension with itself because it is a guideline trying to explain how we apply two independent policies. Notability is a trade term within Wikipedia, and there is no need to change it until we further refine our guidelines for inclusion. TonyBallioni (talk) 03:00, 14 October 2017 (UTC)
  • Oppose. If it ain't broke... -- Necrothesp (talk) 13:30, 17 October 2017 (UTC)
  • Oppose. It took a long time to arrive at "notability" and a WP contextual definition of it, and it's working well enough for our purposes. Its ingrained into WP lingo and process today, and changing it would start way more fires than doing so would put out. See Wikipedia:Notability/Historical (which I compiled; you're welcome. :-)  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  01:21, 21 October 2017 (UTC)
  • Its amazing how many "notable" people for whom there are Wikipedia pages apparently don't care for having their picture taken given how many "BLP" articles exist without a single "image" of the "notable" subject. Then again, it's interesting how many articles are lousy with images to the point where they make infomercials look "encyclopedic" too. Equally amazing is how a "non-notable" subject is important enough to justify anywhere from paragraphs to pages of arguments against the "notability" of that subject. Kinda hard to understand how so many exalted encyclopedia-building editors consider themselves the authorities on "notability" but need to spend vast amounts of time telling "noobs" why the subject of their new article isn't "notable" to them. Of course those exalted "editors" rarely EDIT anything. They'd be more accurately referred to as "deleters" or maybe "censors". — Preceding unsigned comment added by 68.234.100.169 (talk) 09:29, 23 October 2017‎ (UTC)
    See Wikipedia:Non-free content criteria policy. That lack of images is because they have to be available under a open, free-use license, which the vast majority of celebrity and politician and whatever images are not. Basically, someone who is a Wikipedian needs to take one, or someone who isn't has to release one they've taken, under a very permissive license (which often happens at Flickr, thus the large number of Flickr-sourced images here).  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  16:26, 6 November 2017 (UTC)
  • moral support I really want to change away from the word "Notability", but until we get a better word, there is no point. Hobit (talk) 02:07, 27 October 2017 (UTC)

RfC: Should the Reference Desks be closed?

 – Hi everybody. Because this discussion has become so lengthy (300,000+ bytes), I have moved it to a subpage of the village pump so that the village pump is more accessible. I apologize if any confusion has been caused by this. Mz7 (talk) 00:39, 8 November 2017 (UTC)

WP:NOTNEWS (Part II)

Based on the advice given above by Jayron32, I am refining my proposal for WP:NOTNEWS. My proposal again reflects on this sentence: For example, routine news reporting on things like announcements, sports, or celebrities is not a sufficient basis for inclusion in the encyclopedia. Too many editors seem to believe this brief listing is exhaustive when, in reality, it is not. Of course, if it was it would read like "This applies only to...". I recommend adding the sentence This list is not exhaustive so there is no confusion, at least over that issue with the policy. I do not see why this call for clarification would be opposed but I've seen more surprising things from parts of the community.TheGracefulSlick (talk) 00:30, 24 October 2017 (UTC)

  • Oppose. Unnecessary. "For example" does the job. I respectfully disagree with the assertion that there are scads of editors out there trying to write about routine news events like christenings and Sewer Board meetings because they don't understand what "for example" means and it has to be explained to them. What I do see are significant news events minimized by editors who take an extreme view of NOTNEWS. Coretheapple (talk) 13:15, 24 October 2017 (UTC)
  • It would be helpful to point to examples where events were kept that would have fallen under this, where editors arguing to keep said 'This event is not the type listed in NOTNEWS therefore NOTNEWS does not apply" to know if this is a severe problem. --MASEM (t) 13:18, 24 October 2017 (UTC)
  • I could suggest that we tweak the rule to address abuse of NOTNEWS, but I won't, That's because there is no consensus to change this rule. We had an RfC above and a straw vote at Village Pump, both of which reached that same conclusion. Time to let this rest a while rather than keep trying to nibble at it. Coretheapple (talk) 13:33, 24 October 2017 (UTC)
  • Support Clearly more clarity is needed, since people believe the list to be both exhaustive and final. If it isn't, we need to explicitly tell them that. --Jayron32 15:57, 24 October 2017 (UTC)
i've seen that asserted. Where is the evidence that editors view that as an exhaustive list? If this is not a real problem then we have a WP:CREEP issue. Coretheapple (talk) 16:46, 24 October 2017 (UTC)
Coretheapple clarifying a policy isn't WP:CREEP. I can find many more instances but here is a recent example of an editor of 11 years asserting NOTNEWS doesn't apply to crimes because it isn't one of the examples provided.TheGracefulSlick (talk) 17:13, 24 October 2017 (UTC)
Sorry but I'm not seeing Shrike making that assertion. (Pinging, so they can correct me if I'm wrong.) They said " WP:NOTNEWS doesn't apply "its not routine news reporting on things like announcements, sports, or celebrities" . They're saying it's not routine, not that it's not one of the examples listed. And yes, CREEP does apply to so-called clarifications of policy. Coretheapple (talk) 17:20, 24 October 2017 (UTC)
Seriously Coretheapple? He quoted (incorrectly, I might add) that part of NOTNEWS to say crime wasn't one of the items listed. What possible harm can you reasonably find from adding this small sentence for "so-called" clarity? You are just fighting a small change for absolutely no rationale reason.TheGracefulSlick (talk) 17:34, 24 October 2017 (UTC)
A segment from CREEP: "WP:CREEP" is not a substitute for actual arguments. Instruction can be helpful, even if long – when clearly and accurately representing community consensus. Hmm, so how does it apply again?TheGracefulSlick (talk) 17:41, 24 October 2017 (UTC)
I think you're totally misinterpreting Shrike's comment in a very unfair way---but hey, if they think you're being fair and correct it's a different story. As for CREEP, it seems to me that assuming that people don't know what "for example" means, on the basis of such slim evidence, is the epitome of instruction creep. Coretheapple (talk) 18:02, 24 October 2017 (UTC)
  • I have read User:Shrike's comment and I do think that GrecefulSlick is misrepresenting it.E.M.Gregory (talk) 20:45, 24 October 2017 (UTC)
  • Oppose To me, "its not routine news reporting on things like announcements, sports, or celebrities" seems like a perfectly clear statement; attempting to list all types of "routine" news would be futile and might, as editors have argued above, lead to more problems than it solves; and, I see no evidence that NOTNEWS is being misunderstood. What I do see is is a sort of WP:FORUMSHOP by TheGracefulSlick. Abut 6 months ago, GracefulSlick began a campaign to delete pages that she regards as non-notable terrorist attacks. Some were deleted, others were kept, still others closed as "no consensus." She rapidly brought some kept and "no consensus" pages to AfD for a second go, started discussions on the talk pages of pages that closed as no consensus to merge to lists, and filed ANI complaints on editors who opposed her deletions of terrorist attacks (including me). I suggest that we give it a rest, on the grounds that there is no community consensus on what is, in essence, a difference of opinion about the notability of low casualty terrorist attacks.E.M.Gregory (talk) 20:45, 24 October 2017 (UTC)
  • Where to start with this comment? First off, "its not routine news reporting on things like announcements, sports, or celebrities" isn't even how the sentence is read in NOTNEWS. As I mentioned quite clearly in my opening statement, this proposal is not trying to list anything but rather take the advice that was given to me by a neutral admin from the previous thread; I revised my proposal thanks to a community discussion. Yes, I nominated articles for deletion but with thorough nom statements reflecting entirely on notability guidelines. Most of the 2nd nominations were months or even years after the originals so editors could reflect on any long-term impact. One, I admitted already was a bad nomination and I think it would be unfair to still hold it against me. Also true, I did start an ANI thread on you and you were warned about your behavior at AFDs. I sincerely apologize, but I do not think your !vote here was done in good-faith, considering you could not even be bothered with quoting the sentence correctly; then you felt compelled to bring a misrepresented take of my editing history into the conversation which could taint the discussion on a simple clarity statement for NOTNEWS.TheGracefulSlick (talk) 01:57, 25 October 2017 (UTC)
  • Support per Jayron and nominator. I can easily see how some might complain based on an improperly exclusive reading of the list. CREEP is not a concern for me here. The proposal entails just a few words, and not everyone has English as a mother tongue. And CREEP is not a substituted for a grounded argument for opposing, as per WP:CREEP. (P.S. if E.M. Gregory is even a tiny bit right about TheGracefulSlick's motives, I would TROUT them for that, but still support this minor addition of extra clarification. It's nice when guidelines are clear and admit less bickering. ). SemanticMantis (talk) 21:51, 24 October 2017 (UTC)
  • Support My suggestion would be to add this new note as a note/reference rather than in the main text. Shouldn't be such an issue. Lourdes 02:51, 25 October 2017 (UTC)
  • Oppose for the same general reasons as before. This is especially true if the proposal is somehow related to an attempt to delete "minor" terrorist attacks. A terrorist attack by nature is notable -- it can scarcely induce terror without being known to sufficient reliable sources to be worth having an article about. Wnt (talk) 23:08, 25 October 2017 (UTC)
  • Support, with strong caveats Notwithstanding the fact that GracefulSlick's comments end with non-neutral analysis and an unnecesary pre-emptory broadside at anybody who is about to disagree with them, neither of which is appropriate to an RfC opening, the actual substantive suggestion is a reasonable one, it seems to me. That said, I'd propose that if we are going to go out of our way to point out that the list is not-exhuastive, we should also take pains to note that the class is also not an open one. The backstory here about GracefulSlick's perspective on this (whether true or not) underscores the uncountable number of issues that can arise from people wanting to keep significant events off the project just because they are recent. Most all terrorist attacks (to take the present example, though there are countless other areas that apply) are going to qualify under our notability guidelines and WP:NOTNEWS should never work at cross purposes to WP:N, but rather inform upon it in a way that is not conclusive in itself. The list "announcements, sports, and celebrity" may not be the only areas we are concerned about, but they do have a common character which is the meaning we need to preserve here: they are all routine, and thus can be expected to be the focus of media designed to promulgate them, whether they are particularly noteworthy or not--and this needs to be taken into account when considering the weight we give to sources in judging notability. This will not be the case in the majority of instances where WP:NOTNEWS is invoked, I suspect. Snow let's rap 08:42, 27 October 2017 (UTC)
This may be the way to go, as a change to the wording that clarified what we consider "routine" without expanding it may be acceptable to all sides.
Adding "This list is not exhaustive" as suggested above won't help much; what we need are some more-or-less objective inclusion criteria for what is likely "routine" and what is "suitable for inclusion", encoded in the guideline as guidance. I'd point here to the relevant essays WP:MILL ("do not rely on news which are reported merely to fill a placeholder") and WP:SNOWFLAKE ("do report on what is unique to each routine news coverage, if the sources highlight something as remarkable about that item or event"). These opposing essays illustrate the tension inherent in the choice, and can provide some ideas on how to tweak WP:NOTNEWS to make it easier to follow, without changing its scope. Diego (talk) 09:44, 27 October 2017 (UTC)

Change suicide references to remove criminal allusion

While there is no policy against using a different phrase in any given article, there is insufficient support to modify policy so it prohibits the phrase "commit/ted/ting suicide". Dennis Brown - 2¢ 19:03, 17 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.

The woman who wrote the article below makes a good case for not using 'committed/committing suicide'. I suggest changing all references to suicide to something that no longer relates it to a crime.

themighty.com/2015/07/why-you-shouldnt-say-committed-suicide/ — Preceding unsigned comment added by ServelanBlake (talk • contribs) 15:50, 5 October 2017 (UTC)

No objection. "Completed suicide" is an odd-sounding neologism, but "died by suicide" is neutral and understandable. I expect the change could be implemented in existing articles by AutoWikiBot: Noyster (talk), 18:59, 5 October 2017 (UTC)
I'm afraid I don't see why the use of "committed" matters. Which transitive verb we use doesn't change what implications, legal or otherwise, are raised in a given context by the fact of suicide. postdlf (talk) 19:13, 5 October 2017 (UTC)
Agreed. I've seen this language before several times and while it's nice if it helps her understand her brother's death, it's not like anyone else has some preconceived notion that "committing" suicide makes it a crime anymore than "committing" to a football team or a spouse is a crime. There are all kinds of scenarios where we say "committing" outside of crimes. Plus, someone may well think that suicide should be a crime and there are plenty of places where it is. ―Justin (koavf)❤T☮C☺M☯ 19:37, 5 October 2017 (UTC)
I'm opposed to using Wikipedia for language reform, however well-intentioned. As long as the sources keep saying "committed", there should be no general proscription against it in Wikipedia. --Trovatore (talk) 19:41, 5 October 2017 (UTC)
English sources tend to avoid the word committed. See for example BBC Editorial Guidelines, the National Union of Journalists guidance or the Samaritans reporting guidance. Because of these kinds of strong guidance (from organisations that are keen to protect freedom of speech) UK sources tends to avoid the committed word. DanBCDanBC (talk) 18:22, 17 November 2017 (UTC)
Strong oppose as per Trovatore. power~enwiki (π, ν) 21:33, 5 October 2017 (UTC)
Strong oppose. I don't object to editors using or encouraging this, but I do object to mandating specific usage project-wide. –dlthewave ☎ 22:03, 5 October 2017 (UTC)
Oppose... I don't think the phrase "committed suicide" implies a crime. One can also "commit an act of heroism". Blueboar (talk) 22:15, 5 October 2017 (UTC)
Not finding these arguments persuasive.
You may find the odd counter-example but to "commit" an act mostly has a negative connotation. My Concise Oxford says "Be doer of, perpetrate (crime, sin, blunder)..." so in saying "commit suicide" we are employing a non-neutral description. Whether or not we ourselves take this negative view of a deed, it's still non-neutral.
And as for (reliable) sources, we draw on these for our facts, not necessarily for our precise wording.
I didn't read the OP as asking to make any specific usage mandatory, but politely suggesting a change to one specific non-neutral usage: Noyster (talk), 07:49, 6 October 2017 (UTC)
@Noyster: "Commit" a sin/crime is no doubt one of several connotations of the word but when someone "commits" code to a repository, I don't think of it as criminal. Again, I don't think any of us in common speech think that since someone "committed" suicide, he "committed" a crime but conversely, there are places where suicide is a crime. Whether we are claiming some criminal intent or not, it's a quirk of the language that this is still by far the most common way in English to say that someone killed himself (other than possibly "he killed himself" but that is also ambiguous to accidental deaths) and I think simply does not have the connotations the author of the above piece claims, even if they actually did have that basis etymologically. ―Justin (koavf)❤T☮C☺M☯ 08:07, 6 October 2017 (UTC)
In England the coroner returns a verdict of suicide only if they are satisfied he person killed themselves and had the intent to do so, and the coroner has to be satisfied beyond all reasonable doubt. So it's usually more correct (following the sources) to say that someone killed themselves rather than they died by suicide. DanBCDanBC (talk) 18:22, 17 November 2017 (UTC)
Wholly agree with you, Justin. Also, just to clarify, if the death occurred at a time and in a place when suicide was a crime, would normal procedure not be to preserve that wording anyway, as being historically more accurate? Martinevans123 (talk) 08:56, 6 October 2017 (UTC)
I also agree. "Committed suicide" is a normal English formulation, and "commit" does not always have criminal connotations. One can commit to making a delivery by a deadline, for example, or be committed to a psychiatric institution, neither of which carries any connotation of anything criminal at all. Someone also brought up committing source code, another common use that implies no crime or wrongdoing. Seraphimblade Talk to me 21:01, 6 October 2017 (UTC)
I agree that we don't need to follow RSs for precise wording. That's not the point. The point is we shouldn't use WP for language reform. Let's assume for the sake of argument that it would be better for the language to change to avoid the word "commit" here. That's not Wikipedia's role. We follow general (high status) usage; we don't promote it, no matter how high-minded the reasons. --Trovatore (talk) 07:32, 7 October 2017 (UTC)
Wikipedia should follow common usage, and common use in the UK is to avoid the committed word. DanBCDanBC (talk) 18:22, 17 November 2017 (UTC)
How do you reconcile that with Wikipedia:Manual of Style/Words to watch? ―Mandruss ☎ 09:02, 7 October 2017 (UTC)
I don't see any attempts at language reform being promoted in that guideline. --Trovatore (talk) 10:11, 7 October 2017 (UTC)
Well I fail to see the distinction. That guideline says we should avoid the use of certain words regardless of what reliable sources say. How that is somehow not under your language reform umbrella is lost on me. Is the difference that "commit suicide" is such a common phrase? ―Mandruss ☎ 10:24, 7 October 2017 (UTC)
WP:WORDS clearly says that there are no forbidden words or terms on Wikipedia. Yes, the words and phrases outlined in that guideline should be used with caution, but they can still be used when appropriate. Blueboar (talk) 10:40, 7 October 2017 (UTC)
@Mandruss, yes. A simple web news search for commits suicide shows it to be common usage. While some words have specific connotations in some contexts, this only has those connotations when used in the context of sin or crime. In this context it's context only suggest that they completed the act of suicide. I'm going to commit this thread to memory before it gets committed to the archive where I'll never find it again. ClubOranjeT 10:55, 7 October 2017 (UTC)
It's not in common use in UK. DanBCDanBC (talk) 18:22, 17 November 2017 (UTC)

Mandruss, the difference here is that the motivation appears to be to change the English language at large. Some people don't want Wikipedia to say "commits suicide" because really they don't want anyone to say it. That's not style, that's political correctness. Wikipedia should not be used to promote that. --Trovatore (talk) 20:07, 7 October 2017 (UTC)
No, I want wikipedia to reflect language the sources use, and it currently doesn't in the UK. DanBCDanBC (talk) 18:22, 17 November 2017 (UTC)
Several commenters here don't seem to perceive a difference between "committing an act" and "committing something to a place or object". And I don't see the proposal as trying to right some great linguistic wrong, like mandating "xe/xir" or something that isn't already an accepted usage. I see it as raising the question "are we using a neutral description in our articles?": Noyster (talk), 15:11, 8 October 2017 (UTC)
We are not here to WP:RIGHTGREATWRONGS, not that I think the phrase "commit suicide" constitutes a "wrong", and we are not expected to WP:ADVOCATE for anything, not even the Right to die. Bus stop (talk) 16:07, 11 October 2017 (UTC)
  • *Oppose. Not only is this rehash of in-depth WT:MOSWTW discussion from just a few weeks ago (with no consensus that "committed suicide" implies a crime), this same discussion has now forked to WT:MOS, and Talk:David Reimer, and who knows where else. The phrase "committed suicide" is the normal, everyday, idiomatic expression in English. Many alternatives are awkward, or dwell overmuch on the exact cause of death (which can also trigger WP:NOR problems). I'll just copy-paste what I said at the article talk page:

    "Committed suicide" is normal English and does not imply criminality ("commit" has multiple meanings in English - one should commit to committing them to memory). It is by far the most common construction, which is easily provable [5]. "Died by suicide" is actually quite rare (surely owning to its archaic awkwardness, shades of "died by [his/her] own hand", "died by misadventure", etc.). "Killed [him|her]self" (combined) have a bit less than 50% the usage rate in modern works as "committed suicide". There are other ways to write this sort of thing, like "death was ruled a suicide" (if we have official reports that say so), and rearranging the sentence: "His/her suicide ...". There are others (see Suicide terminology), but most of them are awkward. We've spent too many cycles on too many pages arguing about this. People who think that "commit suicide" auto-implies a crime are just flat-out wrong as a matter of English language usage, but in the end do we really care? It's easier and faster to re-word than to keep arguing about this on page after page for the next decade. But "died by suicide" is pretty much the last option; virtually no reliable sources use it other than a few newspapers who've jumped onto the oversensitivity pandering bandwagon. This "died by suicide" stuff is the advocacy position of a particular organization [6]; pushing it here is a WP:NPOV policy problem. While we should not revert rewordings of "committed suicide" that are actual improvements (and "died by suicide" is not, or way more than around 1% of sources would use it), programmatic editwarring against "committed suicide" has to stop. This is rapidly approaching disruptive editing levels, and is a major drain on editorial productivity. It's consumed probably several hundred editorial person-hours just in the last couple of months. [End copied post.]
     — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  22:02, 8 October 2017 (UTC); revised and expanded: 02:08, 1 November 2017 (UTC)

  • Oppose as "commit" is the most common way to say it. It may or may not be a crime, but commit does not imply either way, it means that the choice has been made and cannot be reversed. Graeme Bartlett (talk) 09:22, 11 October 2017 (UTC)
  • Oppose - following the OP's logic, every edit to Wikipedia would be seen as a criminal act... COMMIT (SQL). Cabayi (talk) 09:46, 11 October 2017 (UTC)
  • Comment A commitment can be seen as a deed which is not necessarily criminal. A marriage is an example of a commitment is it not, even if it is not mentioned, it's still a deed. A commitment to suicide doesn't imply criminal, simply a deed weather good or bad.--NadirAli نادر علی (talk) 20:37, 11 October 2017 (UTC)
  • Oppose commit is a perfectly normal word which in no way implies criminality. --Jayron32 20:41, 11 October 2017 (UTC)
  • Oppose. Clear widely used phrase which is normally accepted as neutral. Alsee (talk) 09:52, 13 October 2017 (UTC)
  • Comment. What bothers me at times is not the phrase but when it is written as if it were a certainty. Often the actual documents are more circumspect, and so at times I think it is better to say presumptive suicide, ruled a suicide, etc. The reason why this seems important to me is that I tend to believe that dumb people commit murders, smart people commit suicides... Wnt (talk) 17:09, 15 October 2017 (UTC)
    • @Wnt: To be sure, there will definitely be times where it is ambiguous and in such cases, it's fair to write that something was ruled or considered a suicide but discuss why/how others disagree--that's what NPOV is all about, really. In many cases, this is not a matter of dispute and in those cases,, easily the most common phrasing is "[x] committed suicide". ―Justin (koavf)❤T☮C☺M☯ 06:06, 1 November 2017 (UTC)
  • Oppose. On Wikipedia, we use the English language as it is used, not as we might want it to be used. There is nothing wrong with saying "committed suicide". -- Necrothesp (talk) 13:28, 17 October 2017 (UTC)
  • Oppose Wikipedia is not here for language reform, and the underlying motivation for this attempt is based on faulty reasoning anyway. oknazevad (talk) 22:39, 31 October 2017 (UTC)
  • Oppose per common usage, and per Trovatore (corollary: using WP for language reform is a sub-branch of WP:RIGHTGREATWRONGS), and per Graeme Bartlett ("commit" merely implies an irreversible choice in the past, not a crime). Mathglot (talk) 06:21, 1 November 2017 (UTC)

Note: This voting section was started following a discussion at Wikipedia_talk:Manual_of_Style#Use_of_.22died_by_suicide.22_at_the_David_Reimer_article, where arguments for an against various aspects of terminology where being discussion. Please refer to that discussion for in-depth points from both sides of the argument, and less of a strawman. Also note that the preceding vote section is potentially WP:FORUMSHOPPING as voting had begun at WT:MOS. Carl Fredrik talk 20:45, 1 November 2017 (UTC)

No, it WASN'T. This discussion started on OCTOBER 5. The first formal vote was given on OCTOBER 8. It's right above us. I can read the date myself, as can you. Your discussion started OCTOBER 30. Under no reasonable definition can you say your discussion started before this vote. Just quit it. The discussion here is older, and covers substantively the same issue as the later discussion. Protocol says we don't split discussions up. It this discussion cannot have been FORUMSHOPPING if it predated the other one by 25/22 days! Just stop embarassing yourself. It's simply awful. --Jayron32 10:36, 2 November 2017 (UTC)
I read the timestamp in the comment, which explicitly reads Nov 1, so this is an issue arising through an idiosyncractic timestamp. However I still don't think this thread is going anywhere, and is simply a bunch of oppose votes piling up against what is essentially a strawman argument. See the WT:MOS discussion for a more thorough discussion of the issues, and which terminology professional organizations suggest using. Carl Fredrik talk 15:30, 2 November 2017 (UTC)
I'm afraid you're using the word "strawman" incorrectly. It is not a synonym for "people who disagree with me". --Jayron32 12:28, 3 November 2017 (UTC)
I can't see that it matters. It's being discussed in multiple places, but in all of them it's clear that there is not going to be any consensus to impose the "died by suicide" formulation. --Trovatore (talk) 21:11, 1 November 2017 (UTC)
  • Oppose per WP:RGW. If the language usage changes, we can follow that, but we are not in the business of leading change: we simply report it. --Tryptofish (talk) 21:50, 3 November 2017 (UTC)
  • Oppose per above, esp. Graeme Bartlett and Tryptofish. Happy days, LindsayHello 13:19, 4 November 2017 (UTC)
  • Oppose because I'm not willing to "commit" to such a proposal. Huggums537 (talk) 19:48, 15 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.

WP:PUBLISH rewording proposal.

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
I think it's fairly obvious that an RfC is unnessecary.

At WP:PUBLISH we have:

  • "A film, video, CD, or DVD distributed to theatres or video stores; a radio program including its contents actually broadcast; a television broadcast; a streaming video or audio source on the Internet; a song recording distributed to a public;
  • A transcript or recording of a live event, including: plays, television programs, documentaries, court trials, speeches or lectures, demonstrations, panel discussions, or meetings, a song sheet;" [Emphasis added]

The first part is talking about media which has been preserved in some way, then distributed to theatres or stores, and it goes on to strangely refer to a "television broadcast" as one of those types of media.

The second part is talking about live events, and then it goes on to oddly refer to "television programs" as live events?

I think they have it backwards. If you swap the two terms you can see it does make sense when you realize a "television program" is media that has been preserved in some way, then distributed to stores, and "television broadcasts" are live events. So, I propose a simple switch that should read as follows:

  • A film, video, CD, or DVD distributed to theatres or video stores; a radio program including its contents actually broadcast; a television program; a streaming video or audio source on the Internet; a song recording distributed to a public;
  • A transcript or recording of a live event, including: plays, television broadcasts, documentaries, court trials, speeches or lectures, demonstrations, panel discussions, or meetings, a song sheet; [Changes in bold] Huggums537 (talk) 16:31, 7 November 2017 (UTC)

Rfc on term swapping at WP:PUBLISH

Seeking comments on the proposal listed above to swap the terms used at WP:PUBLISH. Thanks. Huggums537 (talk) 19:11, 8 November 2017 (UTC)

Poll

Support

  1. Support, I suppose. To be honest, this is really all semantics and I'm not really sure an RfC is completely necessary. It's not like editors really follow policy to the letter — it's more about the spirit of them anyway. My advice is that if there was no major objections on the talk page, be bold and change it. ProgrammingGeek talktome 20:19, 8 November 2017 (UTC)
Thanks. I would have normally been bold except that I was recently involved in a friendly(?) discussion not directly related to this proposal, but close enough that I felt it would be more appropriate to open the RfC. I feel confident it's an uncontroversial edit, but one can never be too sure... Huggums537 (talk) 01:15, 9 November 2017 (UTC)

Oppose

Neutral

Threaded Discussion

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

Suggested policy: No hard reverts

You're asking us to abolish the undo function, which is probably the single most-used function on Wikipedia after "save changes" itself, and one on which whole swathes of Wikipedia's maintenance rely. There is no possibility that this is ever going to happen, and keeping this discussion open serves no useful purpose. ‑ Iridescent 12:15, 13 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.

Basically, a hard revert, or a hard undo, is when one user completely undoes another edit. This is a problem when one user puts both good and bad changes (for example, fixing the grammar in one section and adding non-sourced content in another section) in the same revision. By undoing the good changes along with the bad ones, the undoer undoes helpful changes, risks starting an edit war, and more. Therefore, editors should avoid doing this. — Preceding unsigned comment added by 98.197.198.46 (talk) 06:00, 13 November 2017 (UTC)

Not going to happen. If you are worried about this, then make your edits separately. If anything, we should not be encouraging large edits where editors have to sift through a whole ton of changes at once.--Jasper Deng (talk) 06:01, 13 November 2017 (UTC)
Never going to happen, smaller separate edits are the right way to avoid this problem. Roger (Dodger67) (talk) 07:36, 13 November 2017 (UTC)
Patrollers don't necessarily need to waste time rewriting improper edits, but may as a courtesy. I agree with carefully separating edits in suitable units. —PaleoNeonate – 07:42, 13 November 2017 (UTC)
  • Oppose this policy proposal. Editors need to make high quality, well referenced edits, and need to know that they will be reverted if they don't. I agree with Dodger67. Massive exits are a bad idea. A series of discrete edits is much better. Cullen328 Let's discuss it 08:06, 13 November 2017 (UTC)
  • Oppose per above. ―Mandruss ☎ 10:35, 13 November 2017 (UTC)
  • Oppose for the reasons given above and also because this appears to be an attempt to try and estabish a new policy simply to gain the upperhand in content dispute at 2017 Atlantic hurricane season. If as you posted here that making edits to improve Wikipedia is just a pastime for me, and I'm probably not going to make as many edits as soon as this hurricane season is up is truly the case, then it's hard not to view this proposal as being nothing more than an attempt to try and get your way in a local content dispute. You should discuss any disagreements you are having with other editors about content or wording on the article's talk page because collaborative editing also means being able to work together with others to try and resolve differences. It's OK to be bold, but sometimes when making large wholesale changes it's better to be cautious instead. -- Marchjuly (talk) 11:59, 13 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.

Change WP:G5

WP:SNOW. Banned means banned is a long standing Wikipedia policy. It would take an enormous consensus to change that. Something that just isn't going to happen. Entertaining this for any longer isn't going to change that. (non-admin closure) --Majora (talk) 05:59, 22 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.

Add this paragraph "content created and edited solely by a banned user after they were banned, where there is possibility of bad faith. Good contributions by a banned user should be accepted, but where bad faith is possible it should be assumed.". examples of use: meta:Banned user - meta:WM:CSD, wikisource:WS:CSD--Persian-iran (talk) 07:49, 21 November 2017 (UTC)— Persian-iran (talk • contribs) has made few or no other edits outside this topic.

There is a huge difference between bad faith edits and bad edits; users generally get banned as a result of doing edits which are in this gap. עוד מישהו Od Mishehu 07:54, 21 November 2017 (UTC)
  • Strong oppose "after they were banned" is implied by "in violation of block or ban". And also, it has been a long-held principle that accepting edits from (sockpuppets of) banned or blocked users defeats the purpose of the original block or ban.--Jasper Deng (talk) 07:55, 21 November 2017 (UTC)
WP:NOTPENAL :)--Persian-iran (talk) 08:06, 21 November 2017 (UTC)
Doesn't refute or change my argument.--Jasper Deng (talk) 08:25, 21 November 2017 (UTC)
  • For goodness sakes, this is ridiculous. "Good contributions by a banned user should be accepted" is... how to say this... not a good idea. First of all, banned users should not be editing at all. This is what banned means. Second of all, if you let banned users continue to contribute, banning means nothing. It has no teeth at all,and there's no reason to fear it or care if you are banned, which is permission to be an egregious jerk. Enough egregious jerks and we have a chaos problem.
Even if all that wasn't true, it's just asking for trouble in many particular cases -- the person was banned for a reason, probably for causing a lot of trouble and headaches that took time, effort, and patience to deal with. Let him contribute again and he'll likely sooner or later cause a lot of trouble and headaches that would take time, effort, and patience to deal with. Herostratus (talk) 08:30, 21 November 2017 (UTC)
Block-evading harasser.
The following discussion has been closed. Please do not modify it.
@The Bushranger:?! --Persian-iran (talk) 17:52, 21 November 2017 (UTC)
The IP comment above belongs to a multiple-times-over-blocked sockpuppeteer who is WP:HOUNDING an editor, and their !vote is solely in the service of said campaign of hounding. The comment was hatted both because it's purely disruptive and in the name of WP:DENY. - The Bushranger One ping only 18:52, 21 November 2017 (UTC)
  • This perennial proposal, which should be opposed, basically means that we should not ban editors. Also, it belongs on WT:CSD, where it has been defeated time and again. —Kusma (t·c) 10:53, 21 November 2017 (UTC)
  • Oppose Banning does not happen easily. It is a community decision that takes place after much discussion. Once it occurs a banned editor and their socks edits are not welcome on the 'pedia. If they want to edit again the standard offer is always available. MarnetteD|Talk 17:58, 21 November 2017 (UTC)
  • Oppose per WP:BMB. TonyBallioni (talk) 18:04, 21 November 2017 (UTC)
  • Snow - There is literally zero chance of this gaining consensus. GMGtalk 18:12, 21 November 2017 (UTC)
  • Strong oppose The point of a block is to prevent someone from editing Wikipedia. EMachine03 (talk) 18:21, 21 November 2017 (UTC)
  • I won't formally !vote due to taking an administrative action in this section (above) but will note that rewarding people for violating sanctions is an idea that has...problems, and G5 is one of the most important tools available for ban enforcement. Furthermore, when a brand-new editor appears and immediately proposes something like this, it makes it difficult to AGF that they aren't asking on their own behalf... - The Bushranger One ping only 18:52, 21 November 2017 (UTC)
Thank you. but I think G5 violates the WP:5P3.--Persian-iran (talk) 19:25, 21 November 2017 (UTC)
Wikipedia's social policies are not a suicide pact, and as it is there is nothing that says G5 is utterly mandatory (WP:IAR, WP:COMMONSENSE). And along the lines of PACT, I'm going to flatly ask: what prior account names have you edited under? - The Bushranger One ping only 22:50, 21 November 2017 (UTC)
This question is really controversial. and unfortunately, you're talking only about essays.--Persian-iran (talk) 05:55, 22 November 2017 (UTC)
  • Oppose - while I don't like reverting good content, banning has to actually mean something, or there's no point in doing it. --SarekOfVulcan (talk) 19:36, 21 November 2017 (UTC)
  • Oppose for two reasons. As TonyBallioni mentioned, WP:BMB is the current policy for just cause, and banned editors must suffer the consequences. Also, if a banned editor truly has something good to contribute, then another editor can just as easily add the content without allowing the banned editor to do it. Huggums537 (talk) 23:37, 21 November 2017 (UTC)
On your view that "banned is banned", I can also understand that view but that's not how judicial processes normally work. The WP:BMB even violates WP:BANEX, Because most administrators do not like the WP:ADMINACCT]]--Persian-iran (talk) 05:55, 22 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.

WP: COMPETENCE should be elevated to one of the four core policies

WP:DENY
The following discussion has been closed. Please do not modify it.
OP is a block-evading, forum-shopping, harassing editor. - The Bushranger One ping only 11:13, 21 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.

WP: Competence is required must become our core, central, highest policy, and no longer sneered at as "merely an essay" or "optional." An editor who lacks competence is far worse than 1,000 vandals. We must conduct a Stalinist purge of incompetent editors without delay. An encyclopedia without competence is likely to result in our readers knowing facts which aren't true.

  • Support, as nom. We have forgotten the importance of WP: Competence is required, which must be the guiding principle in all that we do. Editors lacking in competence must be purged.209.140.43.55 (talk) 09:41, 21 November 2017 (UTC)
  • Oppose in the strongest possible terms. Don't be so ridiculous—where are you expecting these new editors who magically understand Wikipedia's rules and regulations to come from? Wikipedia is a learning experience for everyone—even I, who at one point or another have been a admin, checkuser, oversighter, arbitrator, and author of the most-viewed TFA of the year two years in succession, wouldn't remotely claim to be familiar with all Wikipedia's labyrinthine and ever-changing policies. The spirit and intent behind WP:CIR is that people who aren't willing or able to follow Wikipedia policy once it's explained to them can sometimes—although not always—be unwelcome here, not that we block people simply because they don't bother to check whether Stalinist purge actually exists as a link before linking to it. ‑ Iridescent 10:05, 21 November 2017 (UTC)
The interpretation of WP:CIR which I was operating with is that it requires the user to be competent in the sense of having adequate knowledge about the topic on which they are editing and the requisite linguistic competence for writing in the language of the given Wiki, not that it requires an advanced degree in Wikilawyering. If WP:COMPETENCE strictly refers to competence in internal Wikipedia arcana, then there should be a new core policy such as WP:Know what you're talking about. 209.140.43.55 (talk) 10:19, 21 November 2017 (UTC)
As a matter of interest, why do you spend your time messing around like this on Wikipedia? Dmcq (talk) 10:47, 21 November 2017 (UTC)
Because we do not allow original research, it is unnecessary for editors to be experts on the topics they edit, they should summarize sources. I agree that experts are valuable, but this is not a requirement. —PaleoNeonate – 11:02, 21 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.

Articles on bi-lateral relations

Context: Wikipedia:Articles for deletion/Qatar–San Marino relations and Wikipedia:Articles for deletion/Canada-Cambodia Relations

I don't believe there's a clear guideline as for when articles on bi-lateral relations between countries should exist. I do feel that one is necessary.

The exchanging of ambassadors is a good starting point, as its presence or absence should not be controversial. While it clearly isn't a requirement for relations to be notable (Iran–Israel relations, for example), it generally is correlated with significant relations between countries.

This leads to several possible outcomes, at a minimum:

  1. All country-pairs should have a bi-lateral relations page. Having an ambassador isn't at all relevant.
  2. All country-pairs that partially exchange ambassadors (for example, one country has a resident ambassador and the other does not) should have a bi-lateral relations page.
  3. All country-pairs that exchange ambassadors should have a bi-lateral relations page.
  4. Some country-pairs that exchange ambassadors should have a bi-lateral relations page.
  5. Some country-pairs should have a bi-lateral relations page, but the presence or absence of ambassadors isn't a useful test; other factors (such as a long-standing history or significant bi-lateral trade) are more relevant.

Thoughts? power~enwiki (π, ν) 17:58, 22 October 2017 (UTC)

FWIW, Several years ago I took a stab at a guideline here. Yilloslime TC 18:25, 22 October 2017 (UTC)
Option 6: Any country-pair that can be reliably sourced as the subject of significant reliable source coverage about the relationship. Diplomatic relationships don't necessarily require an exchange of ambassadors to be notable (as you note, Israel-Iran is a clearly notable topic regardless of their lack of an ambassadorial relationship), but the exchange of ambassadors also can't be an automatic inclusion freebie that exempts the topic from actually having to be sourced to much more than just a primary source press release from the diplomatic corps itself.
Far too many of these pages get created as boilerplate placeholders which say little more than "Canada-Cambodia relations are a diplomatic relationship that exists, the end", which isn't a useful article at all. And even if something more substantial can be written and sourced about Canada-Cambodia relations, it's not necessary to keep the boilerplate page as the base from which to start it — there's so little substance to the existing version that starting over from scratch does not represent any significant increase in the workload involved in redoing it right.
There's no value in comprehensively boilerplating tens of thousands of placeholder articles about every possible combination of two countries, if all the editor can be arsed to actually do is write a stub which just says that the diplomatic relationship exists — if a person really cares about the topic enough to want to start the article, then by definition they should care enough about the topic to put enough work into the article to make it worth existing. Bearcat (talk) 18:30, 22 October 2017 (UTC)
    • There's something like 200 sovereign nations on Earth, so if we're going to have an article for every possible permutation, that would be almost 20,000 articles. Most of which will not be notable. I think we can all agree that this is excessive stamp collecting. The metric is as it's always been: showing enough independent, significant coverage to demonstrate notability. Reyk YO! 19:00, 22 October 2017 (UTC)
  • I think the standard has to remain GNG. Either journalists and academics are writing about these relationships enough to pass GNG or the bilateral relationship isn't going to have enough material upon which for us to write. Chris Troutman (talk) 19:58, 22 October 2017 (UTC)
  • Stick with the GNG, plus the tendency of editors to be slow to create boring articles (especially if they actually have to look up some sources for them). If we get 20,000 articles -- great! But we won't, at least not until we're at tens of millions overall. Wnt (talk) 21:17, 22 October 2017 (UTC)
The problem with "just use GNG" is that, in practice, it's not at all clear when coverage counts. Do WP:MILL coverage in newspapers of attending multi-national events count? power~enwiki (π, ν) 00:10, 30 October 2017 (UTC)
@Power~enwiki: I'll admit, when I look at the picture of the cookie-cutter homes in WP:MILL and read the legend, my gut reaction is "but wouldn't it be cool if we did?" However, in this case, I don't think that principle applies at all. I hope no one would argue that there is such a thing as a "run-of-the-mill war" -- every war deserves a separate article. They are all different. But the exact same thing is true of peace. Countries don't just stay at peace because nothing happens; they have to work at it, figure out ways to settle their differences over fugitives, border surveys, maritime collisions, radio spectrum, a hundred thousand different little things. And so you have to ask, what is the framework they do this in? To say that peaceful relations aren't notable is to impose an unhealthy and all too common bias for conflict over peace. Wnt (talk) 20:25, 7 November 2017 (UTC)
  •  #2 is the most practical, because if there is even one embassy, there is always something to say in an article.  Requiring GNG is setting us up for voluminous meaningless AfDs, and potentially a resulting crosspatch of country pairs that do and don't have articles.  This is also a special case because the normal concepts for redirecting non-notable topics to a larger topic don't work well.  There is another subtle issue here that complicates AfD, that in terms of our concepts of secondary and independent, a press release or article from a government is not the same as a press release from a private company.  Unscintillating (talk) 02:18, 23 October 2017 (UTC)

I definitely agree with Bearcat's comments above. There is no need to define relations solely by the exchange of ambassadors, although it is likely a representative factor. What is important is to include information that supports the fact that there is a relationship between these two countries/states/entities. Examples issues to include would be:

  • Treaties, pacts and international agreements (eg. information sharing agreements, tax treaties, resource extraction, defence sharing)
  • Unresolved issues and negotiations to resolve conflicts/disagreements
  • Significant economic relationships (major foreign investments, high degrees of financial dependence or remittance funds)
  • Significant movements of people for labor exchanges, tourism, medical treatments, markets, refugees, etc
  • Any shared infrastructure, resources, language, culture or activities that are discussed at an official level
  • Recent military conflicts, support for internal unrest, or sponsored terrorism
  • Exchanges of official representation
  • Coverage of significant popular opinion on the relationship

There may be many more factors, but what is important is to demonstrate that there is a relationship and that it is not just an insignificant one. Loopy30 (talk) 17:33, 24 October 2017 (UTC)

This is an excellent summary of the kinds of issues that would represent useful and relevant content for the purposes of establishing a bilateral diplomatic relationship as notable enough to warrant a standalone article. I have little more to add but to endorse Loopy's comment. Oh, except to point out that one example of unresolved issues and negotiations would be a direct boundary dispute. Bearcat (talk) 17:41, 24 October 2017 (UTC)
Bearcat, I agree with you. This is a good list not just of whether an article should exist, but also what you should consider including in one. Also, this isn't the first time we've had a conversation on this precise question. Would you and Loopy30 please consider writing this down somewhere, before bilateral relations articles end up on the list of WP:Perennial proposals? WhatamIdoing (talk) 00:57, 9 November 2017 (UTC)
  • Endorse Option # 5.) "Some country-pairs should have a bi-lateral relations page, but the presence or absence of ambassadors isn't a useful test; other factors (such as a long-standing history or significant bi-lateral trade) are more relevant." Basically, a WP:SIGCOV standard. Although I haven't been active in this area lately, a year or two ago I waded into a number of these pages, attempted to source some unsourced ones, and can clearly see the absurdity of having articles on bilateral diplomatic relations between Ruritania and Spensonia.E.M.Gregory (talk) 21:07, 24 October 2017 (UTC)
  • I never did figure out what is wrong with having the 20,000 articles mentioned above; I still believe in the value of the policy, NOT PAPER. These are articles all of which have the opportunity to grow, and to which beginners can make useful contributions. Most often the apparent difficulty in finding sources is just cultural bias, and to the extent that we succeed in our basic goal of increasing the range of editors at Wikipedia, more and more they will be more adequately sourceable. — Preceding unsigned comment added by DGG (talk • contribs)
    • Based on this discussion, I think a proposal to create all these pages (via bot) would likely pass. power~enwiki (π, ν) 00:10, 30 October 2017 (UTC)
    • What's wrong with it is that you get a bunch of articles saying routine, boilerplate things that nobody is going to bother keeping track of, and therefore nobody should trust. And that level, WP is paper: it still has to be kept track of. We don't need 19,000 articles saying that countries A and B do or do not exchange ambassadors and have basic extradition and trade treaties. Mangoe (talk) 01:43, 30 October 2017 (UTC)
  • And such nonsense articles are also totally misleading because enthusiasts stuff them with Google hits so anyone viewing the article would think the two countries must be very close partners. If secondary sources have written about the significance (WP:N) of the bilateral relations, an article could be produced with some confidence that the so-called relations aren't merely routine. Johnuniq (talk) 02:11, 30 October 2017 (UTC)
What's wrong with that is that Wikipedia's primary goal is quality, not quantity. 20,000 good articles about bilateral diplomatic relations between countries, that are well-referenced and substantive and informative? Sure, absolutely, bring 'em on. But 20,000 boilerplate articles about bilateral diplomatic relations between countries, which just state that such relations exist, the end? What could possibly be the point of, or the value in, that? Bearcat (talk) 18:40, 30 October 2017 (UTC)
  • comment I don't think the problem here is that we need a new or different standard for notability for these articles--if you put it to a !vote I'm pretty confident that consensus would favor using WP:GNG. The problem is interpretting GNG. What is the topic of these articles, really? What is significant coverage of this topic? How many sources are required? Some folks seem to think that any newspaper article mentioning two countries in the same sentence constitutes significant coverage of their relations. Other would say no. This is where direction needed, and a guideline or policy could help. Yilloslime TC 04:02, 2 November 2017 (UTC)
  • @Reyk: 39,800, but who's counting. I already got dibs on Kyrgyzstan–Paraguay, so don't anybody touch that one; there's 39,799 other ones for y'all. Mathglot (talk) 04:50, 2 November 2017 (UTC)
    • That's twice as many because presumably Kyrgyzstan-Paraguay would be the same article as Paraguay-Kyrgysztan. Reyk YO! 04:55, 2 November 2017 (UTC)
      • Reyk, You're right, doh... Who knew that bilateral relations were commutative? Back to 7th grade with me! (Then again, one wonders if the Paraguayan embassy in Bishkek and the Krygyz embassy in Asunción really see things the same way...) Mathglot (talk) 21:12, 7 November 2017 (UTC)
  • Comment Does anyone have a list of, say, the 1,000 most important bilateral relationships? It might be possible to extract from UN data, or their might be a international scholarship study somewhere. Those could then be prioritized, even if they're not necessarily the only ones that are notable. Also, for some of the smaller states, we might consider more merges of articles, like "county-region" relations articles.--Pharos (talk) 18:29, 3 November 2017 (UTC)
  • The problem with relying on significant coverage is that few Western media provide adequate coverage of places such as Sub-Saharan Africa. Do this simple experiment: pick a country in that part of the world, & try to remember the last news report about its foreign policy. I can attest from experience writing articles on Ethiopia that many provably notable bilateral relationships would fail that test if applied too rigorously. An approach similar to what Loopy30 proposed above would accommodate the issue of significant coverage. -- llywrch (talk) 21:42, 7 November 2017 (UTC)
We're not limited to sourcing such stuff solely to news reports, or to Western media. There are also specialist journals on international diplomacy; there are actual media in Sub-Saharan Africa; there's Al-Jazeera; there are academic books on African politics and diplomacy; there are biographies of African diplomats and politicians; and on and so forth. It is in fact very likely possible to properly source a good article about every diplomatic relationship that exists on earth — the issue isn't really whether some countries might get left out, because there are always sources we can draw on to write a good one if somebody actually puts in the effort to look beyond just the big Western media behemoths. Whether there's any value in boilerplating a bad article just so that there's something in place, despite the lack of any discernible effort into making that something any good, is a different question. Bearcat (talk) 19:07, 12 November 2017 (UTC)
  • Power, there was a lot of discussion (

and AfDs) about this in 2009. See Wikipedia:Centralized discussion/Bilateral international relations and Wikipedia talk:WikiProject International relations/Bilateral relations task force, also see the suggested guidelines at Wikipedia:WikiProject International relations#Bilateral relations. Fences&Windows 10:57, 14 November 2017 (UTC)

Indeed that is quite the history! I guess those of us that never learned this, are doomed to repeat it... Thanks for providing these links to the WP:BILATERAL project. Loopy30 (talk) 12:46, 14 November 2017 (UTC)

Orphans

Over the past decade the guidelines on what constitutes an orphan article have been shifting - at least in some places. It used to be that an orphaned article had less than three incoming links from other articles (note, an orphan is a person who has lost one, or both parents). Initially disambiguations (set index articles did not exist then?) and lists did not count.

The following changes at least have since taken place:

  • September 2009 This change recommends adding orphan tags, only if there are no incoming links. The removal of phrase "less than three" was again by User:OlEnglish here, at 06:20, 11 October 2011. This seems to have been a BOLD move, but based on the idea that by redefining the problem we could make it go away (dealing with backlogs by ignoring them is not a solution in my opinion).
  • Now also disambiguations, set index articles and lists are considered sufficient incoming links.
  • Other places have gradually been edited to conform with these changes, but there are still places that do not - for example New Page Patrol.
  • WP:AWB has been changed to conform with the prevailing wisdom, which has changed over the years.
  • We also do not deal with (and never have, really) "walled gardens".
  • {{Orphan}} has become a "mostly invisible" tag.

Personally I think a more sophisticated method of monitoring incoming links might be appropriate these days, and as I said in 2010 " there is no intrinsic reason that some page should not be validly an orphan, and indeed many pages are only linked to from one or more lists." [Even so it was in 2017 trivial to create two new incoming links for Methuen Water Works, in that era claimed as non-de-orphanable.]

Given that the idea of de-orphaning was to "build the web", not to make sure that each page was reachable from every other, be it by means ever so circuitous, what do the panel think we should do in the future?

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

  • If I had my way the {{orphan}} tag and everything associated with it would be deprecated completely. The people who take it upon themselves to tag articles as orphans appear unable to grasp the concept that because something is a niche topic and doesn't have many incoming links, doesn't mean either that it's not notable nor that the lack of incoming links is some kind of problem that needs to be fixed; "build the web" doesn't mean it has to be possible to navigate from every page to every other page, even if they're on completely unrelated topics, purely by clicking wikilinks. (Something with no incoming or outgoing links, on the other hand, is a problem.) Wikipedia does have many issues, but "it's difficult to get from 626 Notburga to Selina Rushbrook purely by following links" shouldn't be considered one of them. ‑ Iridescent 22:29, 16 October 2017 (UTC)
  • I agree with Iridescent. The mindless tagging and untagging takes more effort than just going in and adding links where they are appropriate, and it takes away from the pages that might truly be orphaned yet fixable. And as Iridescent said, not everything is going to be linked to a ton of pages and not everything needs to be either. Nihlus 22:54, 16 October 2017 (UTC)
  • As one of the people working at the Feb 09 orphan category, I disagree that the orphan tag is useless or unhelpful. Building the web isn't just for the sake of being able to get to every page from every other page - the intent behind building the web is to increase the amount of information available to the reader. I have found plenty of instances where investigating why something is tagged as orphaned has helped me improve Wikipedia. I apologize for not having diffs at the ready, as these are observations made over several months of de-orphaning work and it would be quite an effort to go back through thousands of contribs looking for specific examples.
Off the top of my head: I have found plenty of orphans that have actually turned out to be duplicates of better-linked articles; merge and redirection improves the main article and reduces confusion for readers. Many orphans are drill-down topics that would be appropriate to mention in parent articles but have not been for whatever reason, adding that information to the parent article (and linking the child) enriches it. I have expanded plenty of list articles with orphans, increasing the accuracy and utility of those lists. Many species and/or genus articles are orphans, which has prompted me to research and create taxonomy articles to fill the gaps. And finally, many are just plain useful articles that someone tried to link to but some error (typo or formatting difference causing redlink, newbie failure to wikilink, etc etc) caused the link not to work. (There are also plenty of articles in the backlog that need deleting because of promotional issues, lack of notability, and even ancient copyvios, so if tagging something as an orphan gets extra eyes on articles when they're far out of the NPP queue, I'm in favor of that).
All that being said, I think that one incoming link suffices to make something not an orphan. There's no sense demanding that everything be linked from a bunch of places; some things are really only related to one parent topic and that's okay. An orphan should be any page which has no incoming links from mainspace. Any single link from mainspace, be it lists, indexes, navboxes, "see also" sections, etc (with the exception of disambiguation pages) should be enough for us to accept that a page is not an orphan. I would support the deprecation of the "low-linked" articles categories if we confirm the one-article de-orphan criteria, since that would be redundant. ♠PMC♠ (talk) 00:07, 17 October 2017 (UTC)
  • My only thoughts here are that if it is at all humanly possible, I would love it if AWB did not put articles in the "tag as orphan" workflow until 8 days after creation. Quite literally the practice I hate most on all of Wikipedia is when people who just got AWB practice how to use it by tagbombing articles with speedy deletion tags on them as orphans that need more categories. Putting an 8 day hold on the AWB part of this would help prevent tagbombing of new articles and stop watchlists from being clutted by useless edits that are going to be deleted within a few hours to a week. TonyBallioni (talk) 00:17, 17 October 2017 (UTC)
  • I feel the orphan tag serves an important purpose, yes there are some cases where there isn't going to be much to link too, but more often than not, I think that there is. Even more important than that. it gets people of thinking of ways that page could be incorporated into other articles, and investigating if there are options available. The tag should not be looked up as a badge of shame, but as a way by which many by many editors can help make the jigsaw puzzle of Wikipedia work. --Deathawk (talk) 05:51, 17 October 2017 (UTC)
  • support single link de-orphan criteria, (excluding redirects); not every topic has a lot that can link to it. Also support TonyBallioni's suggestion of a stand down period for new creations. What we need is other criteria to de-tag the >130k articles tagged orphan; perhaps after a certain period at least 1 (2, 3?) outgoing links is enough to auto de-tag it. ClubOranjeT 12:07, 17 October 2017 (UTC)
    • I take great pleasure in having never touched AWB, but I'm assuming this is something we can build into its default recommendations? I'd support a 8 day moratorium on AWB tagging any article because I don't think I've ever seen de facto NPP done well using AWB, but I'd settle for a delay on the orphan template as it is the one that is most frequently spammed by new AWB users. TonyBallioni (talk) 16:40, 17 October 2017 (UTC)
      • I think that a delay for both orphan and nocat would be appropriate. Whether or not the ideal delay is eight days is something that people would have to consider, but I am convinced that a delay would be helpful. WhatamIdoing (talk) 01:21, 19 October 2017 (UTC)
        • I'm not sure about nocat, as our catters use that find pages to cat, which they usually do very quickly. For Orphan there is a significant backlog, so a default delay might be a good idea - but I am not wholly convinced, especially given that the tag becomes invisible very quickly. I doubt (despite my comments above) that there are a significant number of pages where at least one incoming link cannot be created. All the best: Rich Farmbrough, 13:28, 19 October 2017 (UTC).
        • WhatamIdoing my reasoning for 8 days is because by that time most of the articles that are CSDable or the obvious AfD candidates are gone. Adding orphan tags to these articles serves absolutely no purpose other than to clutter watchlists IMO. The nocat I'd suggest a 24 hour delay: even some very experienced editors create articles without cats then add them after creation. Getting an AWB tag on it while you are going through hotcat yourself can be very annoying for many people. TonyBallioni (talk) 13:39, 19 October 2017 (UTC)
      • I don't think NPP is done with AWB? Calling tags "spam" and conflating speedy with orphan is - well I would just say "wrong". All the best: Rich Farmbrough, 13:28, 19 October 2017 (UTC).
        • You are correct that NPP should not be done with AWB, but unfortunately tagbombing of new pages is often done with it. I never claimed that all orphans were CSD candidates. I was saying that as one of the more active people at NPP it is very common to see pointless orphan tags being placed on pages tagged for speedy deletion cluttering watchlists and this is most frequently done by new users that are just getting used to AWB. TonyBallioni (talk) 13:39, 19 October 2017 (UTC)
          • I don't see how speedy deletion pages are going to be on many people's watchlists - if you are saying this is a difficulty for you as a NPP who has watchlisted the articles when CSDing them, perhaps we should be getting the orphan tag applied before the CSD tag - 8 days later is not going to cut it in these cases. I also think that finding incoming links for CSDs would tend to mitigate against speedy deletion in cases where it isn't justified.
          • All the best: Rich Farmbrough, 20:50, 19 October 2017 (UTC).

Comment You may read User:Magioladitis/AWB and orphans for a full report of which pages are excluded by AWB. -- Magioladitis (talk) 13:16, 20 October 2017 (UTC)

Thank you Magioladitis, that is very helpful. Would there be a way to get AWB to delay the tagging until a certain amount of time after article creation? TonyBallioni (talk) 13:20, 20 October 2017 (UTC)
TonyBallioni I have a similar open Phabricator task: T127173 which can be modified to much that demand. Till now we had no problems with that because we had a bot for both tagging and untagging and it was running also daily. -- Magioladitis (talk) 13:27, 20 October 2017 (UTC)
  • Deprecate visible templates (or move to talk pages and use code to enforce their placement there – throw an error if used in mainspace); retain invisible maintenance categories, since these are useful for finding under-linked articles and working them into our "web".  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  01:29, 21 October 2017 (UTC)
  • Retain one link discounts an orphan tag, there are already 140,000 orphans (many wrongly tagged ). Increasing orphans to 3 links would at least double the list and disillusion those who are deorphaning, considerably slowing down the clean up rate. Atlantic306 (talk) 19:58, 24 October 2017 (UTC)
  • Retain one link discounts an orphan tag. I agree with User:PMC that these tags often prompt me to take useful action, not only linking, but proposing merges. And agree with User:ToniBalloni that new article should be given a breather, although I wonder if a kinder, gentler tag, suggesting that adding links can strengthen a new article, with a collegial explanation about how to create links, might be a really nice approach with new editors and new articles. It's easy to forget how arcane editing is and how easily we dishearten new editors.E.M.Gregory (talk) 13:42, 25 October 2017 (UTC)

Comment: Orphan articles have proven very difficult to monitor for violations of Wikipedia policy. IIRC, the article that triggered the notorious Wikipedia Seigenthaler biography incident was an orphan article, which escaped notice because it had no incoming links. Hence we need to somehow identify articles lacking any reasonable links to it. -- llywrch (talk) 19:01, 7 November 2017 (UTC)

  • Comment: there's no harm in an article being an orphan ... except in the (far-too-common) case where the article title is "Foo (xyz)" or "Foo, Placename" and there isn't a link, hatnote or redirect from "Foo". And similarly for the article "Name A. Surname" which doesn't have any link from "Name Surname". Those are important and need to be flagged up and fixed. Other orphans... by all means have categories of orphan articles for those who want to de-orphan, in general it's not a problem. PamD 22:19, 10 November 2017 (UTC)

Other railway-related RfCs

Since there has been no notification here yet, there are currently three open RfCs on Wikipedia talk:WikiProject Trains. The first pertains to the disambiguation style of British railway stations, the second pertains to the usage of "station" in the names of halts and transit stop articles, and the third pertains to the disambiguation style of rail/rapid transit lines. Jc86035 (talk) 09:44, 11 November 2017 (UTC)

Criminal in biographies

Comments are requested at Wikipedia talk:Biographies of living persons § RfC about mentioning a persons criminal status (BLP CRIME). Thank you. —Sangdeboeuf (talk) 02:37, 12 November 2017 (UTC)

Notification of RFC

A Request for comment has been made at Wikipedia talk:Lyrics and poetry on whether or not the lyrics of national anthems can be posted on Wikipedia under a claim of Fair Use. Interested parties are invited to comment. Yunshui 雲水 15:26, 13 November 2017 (UTC)

WP:NOTMEMORIAL and victim lists in tragedy articles

There is a consensus against enacting this proposal, and consensus that these scenarios should be handled on a case-by-case basis. TonyBallioni (talk) 00:31, 24 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.

Currently, WP:NOTMEMORIAL states that "Wikipedia is not the place to memorialize deceased friends, relatives, acquaintances, or others who do not meet [the requirements at WP:BLP]". Many, including myself, have interpreted this as prohibiting lists of victims in the articles of tragedies. However, many others disagreed, and in June 2016 there was a discussion as to whether to add such a list to 2016 Orlando nightclub shooting. In the closing statement, it was suggested that while there is a precedent to include such lists, such precedent may conflict with NOTMEMORIAL, and a separate RfC should be held about the general interpretation of the NOTMEMORIAL and to determine whether or not a list of victims violates the policy. Indeed, local consensus for 2016 Orlando nightclub shooting was "to allow the list untill it is either removed to a separate article or a higher level consensus abolishes the use of such lists acrosss wikipedia" [sic]. The full closing statement by Maunus is below for reference:

I count 22 !votes to include vs. 16 to exclude. However, several arguments for excluding are temporary opening the possibility of having separate page listing the victims. The argument against is WP:NOTMEMORIAL, which suggests that wikipedia should not memorialize people who are not themselves notable biographic subjects. Arguments for allowing, suggest that WP:MEMORIAL does not apply to embedded lists in articles, and point out the precedentfor having such lists in other articles about mass shootings. I think that there is a conflict between WP:MEMORIAL and the existing precendent, but this should be addressed in a separate RfC about the general interpretation of the WP:MEMORIAL. In such an RfC i would vote to exclude lists of victims in articles on mass deaths (especially given the inequal possibilities afforded different kinds of victims in different pats of the world), but in this case the local consensus regarding this article in specific is to allow the list untill it is either removed to a separate article or a higher level consensus abolishes the use of such lists acrosss wikipedia.

That brings us here. I propose that we add a line to WP:NOTMEMORIAL that would prohibit listing individual victims of tragedies if they do not meet our notability guidelines and/or WP:BLP. This would apply to not just lists, but general naming of non-notable victims as well, either in the article or as a separate article. This proposal, if approved, would also override any local consensus and precedents. SkyWarrior 04:53, 7 October 2017 (UTC)

Memorial:Support

  • Support as nominator. SkyWarrior 04:53, 7 October 2017 (UTC)
  • Support per WP:BIO1E and just generally out of respect. If all we can write about a person's entire life is that they died, we should not write about them. I've done a lot in my life, none of it notable, but if I die in a terrorism incident and that's the only thing you ever write about me, I will haunt your ass. Ivanvector (Talk/Edits) 12:24, 7 October 2017 (UTC)
  • Support. Naming non-notable victims is a horrible and blatant invasion of privacy (and WP:BLP), as well as a bizarre misuse of Wikipedia. Softlavender (talk) 03:07, 9 October 2017 (UTC)
  • Support More specifically, I agree there are times they are appropriate as to understanding whatever the tragedy was, but we should be considering those exception, with the rule to avoid inclusion of victim lists in general. Hence I support the general idea, just that we need the "with exception" cavaet. --MASEM (t) 14:12, 9 October 2017 (UTC)
  • Conditional support, "I support the general idea, just that we need the "with exception" caveat" per Masem. Therefore wording should indicate ' ordinarily avoid', rather than 'ban' such lists. Per others, these lists fulfil no real purpose, except sentimental memorialising. Pincrete (talk) 15:01, 9 October 2017 (UTC)
  • Support Not a fan of victim lists in general. SparklingPessimist Scream at me! 02:54, 10 October 2017 (UTC)
  • I'm not a fan of Pessimists so does that mean we get rid of you ? .... No ofcourse it doesn't, You either need to provide a better rationale other than WP:IDONTLIKEIT or strike the entire thing. –Davey2010Talk 21:02, 11 October 2017 (UTC)
  • Support Not only is this a pretty blatant violation of WP:NOTMEMORIAL, there are WP:BLP concerns here. Unless these people are independently WP:notable, it's a dubious call to be archiving their names in our articles in this fashion; I don't think the value a list of names adds to understanding the substance and context of a tragedy (as an encyclopedic topic) is significant enough to justify dragging the identities of these people (and by consequence, their families) into an article. Needless to say, the equation changes with enough WP:WEIGHT in the sources--with the important caveat that weight in this instance means more than just a handful of sources repeating the names: there would need to be a certain baseline depth of coverage as well. And even then, we would have prose detail for anyone who is genuinely WP:DUE for inclusion, not a mere listing. Snow let's rap 06:52, 13 October 2017 (UTC)
  • Support, as general rule, allowing for exceptions, as others have already explained. - Nabla (talk) 20:57, 13 October 2017 (UTC)
  • Support per Snow Rise. The case-by-case discussion should be limited to whether the victims are independently notable, and that is already a provision of this proposal. There is little need for case-by-case discussion about anything else. Those discussions invariably have more to do with interpretation of NOTMEMORIAL than about the specifics of the article, and article talk is not the place to have such discussions. Further, the notion that name-listing in RS is all we need to list these names is in direct conflict with WP:BLPNAME. ―Mandruss ☎ 19:18, 16 October 2017 (UTC)
  • Support. If information isn't encyclopedic, it shouldn't be in the encyclopedia. There are opposes arguing for a "case by case" treatment, but no evidence of a "case" where such a list would be encyclopedic. —swpbT go beyond 17:48, 27 October 2017 (UTC)
  • Support. Lists of victims do not add to encyclopedic understanding of the topic at hand. We can link to sites that keep lists of the victims. This is the job of a newspaper, not an encyclopedia. Also, I know it may seem anomalous in today's world of social networking sites and reality TV, but some people may wish to keep their grieving private, without involving the entirety of the internet. NinjaRobotPirate (talk) 05:19, 28 October 2017 (UTC)
  • Support I've read the support and oppose views and I find the support views much more persuasive. It doesn't seem like the actual names of the victims provides much encyclopedic information to me. What do the names, by themselves, add? It seems like, at least with respect to non-notable people, that a summary of the number of victims and their ages and genders or religions or whatever else is relevant provides all of the encyclopedic information that anyone would need. We also have no idea whether the victims or their families want to be publicized in this way; I am guessing some of them don't; and Wikipedia isn't organized in a way that would allow those families to make an effective plea for privacy (I don't think there's a warning template "don't mention this particular victim" and even if there was its use would defeat the purpose of not publicizing the name). I think this privacy problem is the best reason to have the suggested rule. I am still quasi-traumatized about the ISIS victims whose families pleaded to Wikipedia for privacy and were mostly ignored. (I'm not actually traumatized, but it wasn't a good moment for us.) The objection "we don't need a blanket rule because we couldn't imagine every circumstance" is weak because the reason we have WP:IAR is to allow people to ignore rules when their justifications don't make sense. Also, to me, that particular objection seems more like "I don't like the WP:NOTMEMORIAL policy in the first place" (a bad reason to oppose this proposal without some stated actual objection to the policy) not "we might want to make exceptions to WP:NOTMEMORIAL." We can make exceptions to any blanket prohibition established here using WP:IAR as necessary where circumstances warrant it. There are other silly justifications made by opposers, like "you could use a list of victims to see that everyone killed in the École Polytechnique massacre was a woman." It would be much easier for a reader to find that out by reading a sentence that said just that than would be to try to discern from a list of French names that everyone killed was a woman. Another oddity is how just posting the list of victims ignores the people who were injured, sometimes severely, but not killed. Wouldn't any justification for listing the names of victims also apply equally to people that are injured? One example of the problems of only listing the dead and not the injured is that you would have no idea that men were also targeted in the École Polytechnique massacre unless you read the article, which mentions the gender of everyone that was hurt, not consult the list of names of victims – which ignores people only maimed. Overall, I see no encyclopedic benefit to the list of names. AgnosticAphid talk 23:10, 2 November 2017 (UTC)

Memorial:Oppose

  • Oppose. This should be handled case by case, not by a blanket global prohibition. Seraphimblade Talk to me 05:03, 7 October 2017 (UTC)
  • Oppose. Totally agree that this is something that is handled case by case. A full on ban would be ignoring situations that we simply can't anticipate today. Dennis Brown - 2¢ 11:01, 7 October 2017 (UTC)
  • Oppose Case-by-case consideration is the best way to go. The phrase "victims of tragedies" covers far too broad and far too diverse a population for the proposed rule. Eggishorn (talk) (contrib) 11:50, 7 October 2017 (UTC)
  • Oppose This should be handled case by case. At a minimum BLP1E (or similar) cases should be mentioned. If victims of a notable event are mentioned/listed as part of reliable coverage of said event, it makes sense that we mention them as well. A prohibition would go against the intention of WP:MEMORIAL. Agathoclea (talk) 12:11, 7 October 2017 (UTC)
  • Oppose per above. postdlf (talk) 13:47, 7 October 2017 (UTC)
  • Oppose per above. HastyBriar321 (talk) 02:27, 8 October 2017 (UTC)
  • Oppose per Seraphimblade. I'll also add that this is especially true if reliable sources have produced such lists. A Quest For Knowledge (talk) 01:36, 9 October 2017 (UTC)
  • Oppose as per above - Should be done case-by-case, As noted by Agathoclea if they're mentioned in reliable sources = Include them, if not = don't. –Davey2010Talk 02:59, 9 October 2017 (UTC)
  • Oppose per "case by case" arguments. Similarly oppose "name them if RS names them", and I certainly hope that doesn't make it into the close statement. RS almost always names them because their mission is very different from ours. As for the language at WP:MEMORIAL, name lists in a handful of news articles do not make the individuals notable; if they did, we would have bio articles on those individuals; there is only one notability threshold. ―Mandruss ☎ 06:46, 9 October 2017 (UTC)
  • Oppose weakly. (Summoned by bot) It has to be a case by case, anything else will just cause trouble, not guidance. L3X1 (distænt write) 16:13, 9 October 2017 (UTC)
  • Oppose . (Summoned by bot) Depends on the tragedy. Should not be a blanket rule, should be case-by-case. Coretheapple (talk) 15:34, 10 October 2017 (UTC)
  • Oppose If the names are verifiable / covered in reliable sources, then it could be part of the article. Each article should be considered on the merit of including such a list. Graeme Bartlett (talk) 09:19, 11 October 2017 (UTC)
  • Oppose I see no reason not to list where the subjects are verifiable with reliable source. Consider 1940 Canberra air disaster. Four of those killed are very notable indeed; the four aircrew are not. But I think the article is best served by their inclusion. Hawkeye7 (discuss) 21:28, 11 October 2017 (UTC)
  • Oppose - Case by case basis is needed. If they are mentioned in a reliable source I fail to see any argument against their inclusion. Nihlus 18:45, 16 October 2017 (UTC)
  • Oppose This issue came into sharp relief after the 11 Sept 2001 attacks (we eventually created an entire wiki which is now mothballed). I am in general cautiously against including lists of victims, particularly long lists, it adds very little. There are cases, though, where even non-notable names are relevant, for example where the names themselves indicate something of value. Even then this is best sourced and stated explicitly. All the best: Rich Farmbrough, 22:24, 16 October 2017 (UTC).
  • Oppose. No need for a hard and fast rule. Sometimes it's appropriate to name victims; sometimes (especially when there are many victims) it isn't. Depends entirely on the individual case. -- Necrothesp (talk) 13:24, 17 October 2017 (UTC)
  • Oppose - It would cause chaos to implement such a hard and fast rule across the board. Each article must be looked at individually. No hard and fast rule should be implemented across the board. Each article must looked at individually. If the list of victim names is included in numerous top-tier reliable sources, particularly for major tragedies such as mass shootings, then exluding the names would be non-sensical and a great disservice to readers. The names would obviously be noteworthy content. Including only basic, identifying information - such as name, age, and residence city - would in no way be memorializing victims. Memorializing would include things such as personal background details, tributes, anecdotes, quotes, and photos. For articles about mass shootings, consider this: the 10 deadliest mass shootings in U.S. history are, in order, the 2017 Las Vegas shooting, the Orlando nightclub shooting, the Virginia Tech shooting, the Sandy Hook Elementary School shooting, the Luby's shooting, the San Ysidro McDonald's massacre, the University of Texas tower shooting, the Edmond post office shooting, the 2015 San Bernardino attack, and the Binghamton shootings. All of them, except Las Vegas (which is currently in the midst of a discussion about this), include a list of the victims' names and, at the very least, their ages. This evidence makes clear that Wikipedia editors have repeatedly debated this issue and clearly established a consensus that a list of victim names should and will be listed in major mass shooting articles, and that its inclusion overrides any objections based on WP:NOTMEMORIAL, WP:BLP, and WP:OTHERSTUFF. 2605:A000:FFC0:D8:E8B0:35F4:5401:1C0D (talk) 15:16, 17 October 2017 (UTC)
  • Oppose—Most individuals who are killed tragically are not "independently notable." If they were, they could have their own article. The proposed policy misses what lists do. Among other things, lists can illustrate the discriminatory intent of a massacre perpetrator (École Polytechnique massacre); provide an illustration of the indiscriminate nature of violence, for example that a shooter attacked children; help describe the chronology and place where violence was applied (Haditha massacre); illustrate familial relationships among those victimized (Haditha massacre, again); and indicate the affiliations of those killed. It's possible that a truly random, or non-purposeful attack needs none of these things, but let's leave it to page editors to work that out. Moreover, lists provide a mechanism for a user searching for a given victim to find the tragedy in which they were killed. These objective grounds are in addition to concerns that encyclopedic text should offer at least the same human dignity to victims of tragic violence as their perpetrators.--Carwil (talk) 19:34, 17 October 2017 (UTC)
  • Oppose – WP:NOTMEMORIAL says "Subjects of encyclopedia articles must satisfy Wikipedia's notability requirements. Wikipedia is not the place to memorialize deceased friends, relatives, acquaintances, or others who do not meet such requirements." This is about articles and notability, and says nothing about whether lists of victims are encyclopedic or not. I suggest we continue to look at this more case-by-case. When reliable sources publish lists of victims, it would seem OK for us to do the same. Dicklyon (talk) 04:52, 20 October 2017 (UTC)
  • Oppose, list of victims is part of encyclopedic knowledge of an attack. If reliable sources publish such lists, do not see why they cannot be included on Wikipedia. A violation of not memorial would be if we started including obituaries ("they are survived by five kids, three dogs, and a hamster"). In some cases, the lists might not be appropriate, but they should be handled on case-by-case basis. Renata (talk) 23:16, 22 October 2017 (UTC)
  • Oppose, If the incident itself in which they died is notable, then the people who died taken as a whole are notable. In some cases obviously the number would be too big (e.g., 9/11, or the sinking of the Titanic). Should be decided case-by-case. FOARP (talk) 12:37, 24 October 2017 (UTC)
  • Oppose - As others have said this should be handled on a case by case basis. No need for WP:CREEP here. - Knowledgekid87 (talk) 14:36, 24 October 2017 (UTC)
  • Oppose - Each article is different. If the victims are named in multiple reliable sources and if it is due weight they should be included Atlantic306 (talk) 20:09, 24 October 2017 (UTC)
  • Oppose - Information about and names of victims should be included provided they can be sourced to multiple WP:RSes.E.M.Gregory (talk) 13:30, 25 October 2017 (UTC)
  • oppose - Lists of victims should be included if they have sufficent sourcing. Large lists should be determined case by case. If the list is too long it could be moved to separate page.Patapsco913 (talk) 13:05, 27 October 2017 (UTC)
  • Oppose. I think there should be both no prohibition on including victim names and no encouragement to list all victims. Victims who have been the subject of substantial reporting, even if they do not meet WP:BLP (specifically WP:BLP1E), should be included. Victims don't have to be individually notable to be mentioned in such an article, but we also shouldn't list every victim at a page like 9/11. This is very much a case-by-case thing. ~ Rob13Talk 15:15, 2 November 2017 (UTC)
  • Oppose lists of victims are relevant to a crime hence can and should be included, provided there is sufficient sourcing. gidonb (talk) 11:46, 4 November 2017 (UTC)
  • Oppose under WP:CREEP. The premise of this proposal seems to be that the WP:LOCALCON of a single article should be overridden by making general changes to a policy. Sławomir Biały (talk) 00:34, 6 November 2017 (UTC)
  • Oppose due to the fact that the proposal is directly contradictory to the specific freedoms afforded by the notability guidelines, which state that, "The notability guideline does not determine the content of articles, but only whether the topic should have its own article", "The notability guidelines do not apply to contents of articles or lists", "Notability of lists (whether titled as "List of Xs" or "Xs") is based on the group.", "Because the group or set is notable, the individual items in the list do not need to be independently notable". I'm opposed to anything that might not let me be free on the project somewhere down the line just because others can't contain being offended. Wikipedia is also not censored. Huggums537 (talk) 15:51, 9 November 2017 (UTC)
  • Oppose. Should be handled on a case-by-case basis. Sometimes a list of names should be included. Too many of our editors strictly police things. Flyer22 Reborn (talk) 20:04, 12 November 2017 (UTC)
  • Oppose primarily on the principle of wp:NOTCENSORED. And, as cogently stated in this section, the Notability guideline does not apply to contents of an article, only to the topic of an article. Wikipedia does, in fact, include articles naming hundreds of victims: Titanic passengers, and 9-11 emergency responder fatalities. DonFB (talk) 05:12, 16 November 2017 (UTC)
  • Oppose. "Wikipedia is not the place to memorialize deceased friends, relatives, acquaintances, or others..." I think pretty much means "Wikipedia is not the place to memorialize deceased friends, relatives, acquaintances, or people like that. Otherwise it would not list three specific classes of people, all of whom are personally known to you, and then add "and others..." to mean a class of person (people who named in important news stories) very much different from the three examples given. That would make little sense. What is intended is "Wikipedia is not the place to memorialize deceased friends, relatives, acquaintances, business colleagues, roommates, ex-spouses, ex-boyfriends or girlfriends, neighbors, or persons known to any of these (i.e. "friend of a friend" or "child of a acquaintances", etc.) whom your intend to memorialize for that reason". This is overly long and even then you'd surely miss some group which you wanted to include. This is why we generally say "and so forth" in many of our rules.
So I mean what's intended is "Nobody wants an article about your neighbor's kid who tragically died of leukemia" This has little to do with victims of notable events named in major news stories. So this would be a new thing. Do we need this new thing? It says here we don't. Herostratus (talk) 06:19, 18 November 2017 (UTC)
  • Oppose Should be handled on a case-by-case basis. --RAN (talk) 18:13, 23 November 2017 (UTC)

Memorial:Alternatives

  • Mixed guidance - Alternative guidance might be "avoid listing names in mass deaths unless the individual names are commonly listed in accounts, or are otherwise notable" This seems an area where the precedent seems to sometimes list victims of shootings but not always, with no clear guide that I can see. Guidance might mention that larger events should not list names because it's infeasible and large enough that the individual names were not covered so do not meet WP:V or WP:WEIGHT. Examples University of Texas tower shooting, Sandy Hook Elementary School shooting, and Columbine High School massacre, UpStairs Lounge arson attack. Versus Cleveland Elementary School shooting (Stockton), Oklahoma City bombing, 1975 LaGuardia Airport bombing, or September 11 attacks. Markbassett (talk) 04:54, 8 October 2017 (UTC)
  • Mixed guidance, per Markbassett. We do have an issue to resolve, but should not over-reach.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  21:57, 8 October 2017 (UTC)
  • Mixed guidance - I agree that it is improper to list the victims in cases of random mass shootings... but I do think the names of the victims are important to mention in cases where the victims were the intentional targets (i.e. where the killer was intentionally trying to kill specific individuals). Blueboar (talk) 15:13, 9 October 2017 (UTC)
    • An addendum... to the extent that we DO name victims, we need to do so with respect for the families of the victims. Should a victim’s family ask us to remove their loved one from the list, this expressed desire for removal needs to be respected and honored. Blueboar (talk) 18:58, 23 November 2017 (UTC)
  • Mixed guidance - I would probably have agreed to support this proposal, but then there are cases where a simple list is notable and should be included. Perhaps the guideline is set dependant on the overall number of people, most higher-body-count incidents would also have a proportionally higher number of unnotable individuals. It could be that low-individual lists are allowed, medium-individual lists are collapsed (possibly in a template at the end of the page called "List of people killed in *x*"), and high-individual lists are excluded altogether? IJReid {{T - C - D - R}} 05:32, 12 October 2017 (UTC)
  • Mixed guidance: Where inclusion of victims is necessary to understand a crime (motivation, sequencing, interaction with perp, etc), then they should be included. Where inclusion is not required to understand a crime, they should not be included. This means that in some cases all victims would be included, while in other cases some might be referred to obliquely or grouped, and in other cases few or none would be included. For the Las Vegas shooting, Campos appears to be the only victim critical to understanding the event.~Hydronium~Hydroxide~(Talk)~ 11:48, 19 October 2017 (UTC)
  • Mixed guidance: I would prefer External Links to lists of victims. Failing that, I would like the names to be treated the way secondary sources handle them. That is, if multiple reliable secondary sources mention a victim's name, then Wikipedia can do so. As an example, University of Texas tower shooting is drawing from a variety of documentaries. Abductive (reasoning) 06:50, 20 October 2017 (UTC)

Memorial:Neutral

Memorial:General discussion

Please arrange for the RfC format to be fixed. There are at least two problems with the layout:

  1. There is neither a signature nor even an unattributed timestamp for the opening statement. When building the RfC listings, Legobot (talk · contribs) copies from the {{rfc}} template (exclusive) to the next timestamp (inclusive). The next timestamp is in the "Support" section, so Legobot will copy that heading and the first !vote. If this appears in the RfC listing, it would be against WP:RFC#Statement should be neutral and brief, and could skew the responses.
  2. The text copied by Legobot includes a table; this is forbidden by WP:RFC#Statement should be neutral and brief as it breaks the listing entry.

Have a look at how the RfC appears at WP:RFC/BIO (Permalink). --Redrose64 🌹 (talk) 19:09, 7 October 2017 (UTC)

Sorry about that, I think I fixed it. SkyWarrior 23:35, 7 October 2017 (UTC)

Please also note that the opening statement should be "neutral and brief [...] A long statement will make the list harder to read [...] If you have lots to say on the issue, give and sign a brief statement in the initial description and save the page, then edit the page again and place additional comments below your first statement and signature", per Wikipedia:Requests for comment. —Sangdeboeuf (talk) 17:15, 12 October 2017 (UTC)

Comment I sympathise with whoever has to close this! I note that almost no one supports a blanket ban, some supporting identifying 'target groups' others some other guidance. However it would be good if we could get some clarification of when such lists are appropriate. The problem with a completely open approach is that a lot of editor time is expended, typically at a time when the main article is itself occupying a lot of time and discussions are often very OTHERSTUFF, "those other victims got a list why don't these, what's wrong with them?". This is an old-fashioned sentiment I know, but are we entitled to think that victims and their families would necessarily WANT to be listed permanently on WP? Pincrete (talk) 23:09, 5 November 2017 (UTC)

Good point... we should not list if the families ask us not to. Blueboar (talk) 18:59, 23 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.

Application of policy at Talk:2017 Zimbabwean coup d'état

I've not been involved in Wikipedia that much for a few years, but have just got involved in a debate that has quite worried me about how policy is being applied, or possibly not being applied.

I noticed we had an article called 2017 Zimbabwean coup d'état, even though most news organisations aren't currently calling it a coup, and the article says in the lead that the armed forces have specifically said it isn't a coup. I posted a move request to suggest that a different title ('2017 Zimbabwe crisis') might be more appropriate given the sources, WP:V and WP:NPOV.

The prevailing argument in the debate at the moment seems to be, to quote one user, 'Oppose per WP:DUCK. If it looks like a Coup d'état, sounds like a Coup d'état, it's a Coup d'état.' (Four users have specifically cited the Duck Test.)

To quote WP:DUCK: "The duck test does not apply to article content, and does not trump, or even stand aside, policies such as no original research, verifiability and neutral point of view." (Emphasis in original.)

I know it looks like a coup. I even agree it probably is a coup. My issue is that the core Wikipedia policies are that we don't just write what we believe; we write what is in reliable sources, we write only what is in reliable sources, and we present the views expressed in those reliable sources neutrally. If we (including several administrators) now ignore all of that in favour of "It looks like one to me".... I am honestly worried for Wikipedia.

Can someone assure me that I am worrying unnecessarily?

(Apologies that this might look like a WP:CANVASS - I'm not asking people to go over there and vote, just to explain why this isn't evidence that Wikipedia's core content policies are now routinely ignored in favour of personal opinion.) TSP (talk) 23:06, 16 November 2017 (UTC)

You're correct. It is something to be worried about, but I haven't seen it and so it maybe doesn't happen a lot, in which case I wouldn't worry too much. Best would be to just point out to the person (and any watchers) that they're wrong, and cite the relevant passage. Herostratus (talk) 06:25, 18 November 2017 (UTC)
Well, the proposal failed, 6 for and 15 against; I'm not sure more than three or four of those oppose votes actually gave any policy-based reason for their vote. (Those that did present any policy-based reason mostly cited WP:COMMONNAME, but without any actual attempt to demonstrate that it was the term most sources were using.)
*shrugs* I guess Wikipedia editing is at least a lot easier if we can now just put <ref>This is obviously true</ref>.
(BBC still isn't using 'coup'; but obviously we know better than they do.) TSP (talk) 17:29, 20 November 2017 (UTC)
I think the user Jenks24 gave the best advice when they closed the discussion "No prejudice against revisiting when this has become less of a 'breaking news' type story" (bold mine). Instead of worry about what is right, worry about what can be done about it. From a purely pragmatic point of view, you are unlikely to move that small group of determined editors at the moment. Instead, give it a few weeks, then revist the issue. The issue is not what is "right" or "wrong", but rather what is to be done about it. The easiest path forward, if you are right, is to just let it chill for a while, and then come back when people aren't as likely to be in a combative mindset. --Jayron32 18:27, 20 November 2017 (UTC)
  • This is exactly the kind of very predictable (and predicted in what is currently the first discussion on this page) outcome of ignoring wP:NOT#NEWS and writing articles about breaking news sourced to primary news reports, rather than waiting until secondary sources appear on which to base a proper encyclopedia article. 86.17.222.157 (talk) 19:14, 22 November 2017 (UTC)~
    • I disagree. Many people come to Wikipedia to read articles on recent events like this one. How many weeks or months do you think that we should wait until adding information about it to History of Zimbabwe or whatever? --186.54.2.155 (talk) 19:58, 24 November 2017 (UTC)
      • In the case of major events like this one it would usually only take a few days before secondary sources, such as articles in newspapers reviewing the situation rather than reporting breaking news, start to appear. At that time (and it may already have happened in this case) it would be clear whether we should call this a coup or not on the basis of what such secondary sources say. The point is that in this case an article was created before the secondary sources on which to base even its title, let alone its content, existed. 86.17.222.157 (talk) 21:31, 24 November 2017 (UTC)
On the base question, but in the abstract (I don't have time to do so a source analysis on this particular case): This isn't even new; see pretty much every debate in the history of WT:Manual of Style/Words to watch. The gist is that when it comes to any contentious label, it cannot be applied in Wikipedia's own voice unless it (or something closely synonymous, if there's any real wiggle-room – sometimes there is and sometimes there's not) is the dominant description in independent RS. E.g. if 10 sources say something was a rebellion and 1 says it was a revolution WP can't call it a revolution. If 8 say a group is a "white pride" organization and two say "white power", WP uses "white pride" because "white power" is probably being misused. If a dozen say "militant islamic faction", 2 say "fundamentalist islamic", and 3 say "islamist", we don't use "islamist" or "fundamentalist" in WP's voice, because they're not actually synonyms and people get this wrong all the time. Of course, source quality also plays a factor. If 15 low-brow newspapers, opinion blogs like HuffPost, and pop-culture magazines, plus a new book by a ranty polemicist with a poor reputation for fact-checking call something a coup, while 15 major news sites, including those with a reputation for serious political and world-events coverage, and a new book by a renowned polit-sci professor call it a populist power shift, we'll go with the latter, while "teaching the controversy" that some are characterizing it as a coup. We can always provide the alternative perception(s) within WP:UNDUE bounds and with specific attribution and, where needed, direct quotation.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  13:51, 29 November 2017 (UTC)

Names of articles on recent events

See Wikipedia:Names of articles on recent events and its talk page for a proposal to incorporate dates into article names even if not required for disambiguation. Andrewa (talk) 09:15, 29 November 2017 (UTC)

The ongoing actual consensus discussion is at Talk:2015 Thalys train attack#Requested move 21 November 2017.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  15:05, 29 November 2017 (UTC)
Yes, and the proposal talk page links there, and the proposal itself to the article concerned and now to some others. There's also a link to the discussion at WT:AT, but I think the proposal talk page is the place for discussion, with heads-ups elsewhere as appropriate. Andrewa (talk) 16:15, 29 November 2017 (UTC)

Anti/Pro-Trump/other politician user categories and userboxes?

I'm doing this as a pre-emptive measure because there seem to have been quite a lot of user categories and userboxes that are being brought to the attention of both WP:CFD and WP:MFD. The earliest discussion I can find is Wikipedia:Categories for discussion/Log/2017 February 14#Category:Politically leftist Wikipedians, which saw both that category and an equivalent for right-wing Wikipedians get deleted. It seems that for awhile things were quiet, until we had this discussion, Wikipedia:Categories for discussion/Log/2017 September 4#Category:Wikipedians who are against Donald Trump, which also saw that category get deleted. I've nominated a category recently myself, but only one, and I didn't realize how widespread these materials are, or how much momentum this trend of nominating these things is gaining. There is also Wikipedia:Categories for discussion/Log/2017 October 6#Political support categories, which seems to be gaining a steady delete consensus (it's about user categories that specifically and unambiguously endorse candidates on both sides of the spectrum). Elsewhere, however, the solution is not so clear-cut, with many categories, in the view of users such as myself, expressing support for one sociopolitical viewpoint or another without using it to imply interest in collaboration with other Wikipedians in editing those same topic areas regardless of whether they personally agree with each other. Personally, my view is that these userboxes stand in clear violation of WP:UBCR, while the categories violate WP:User categories#Inappropriate types of user categories, namely "Categories which group users by advocacy of a position". This is not merely a fringe view either, as there's enough of us who think this way that it's clouding consensus on the issue, warranting broader discussion.

I believe the best way to go about this is to list examples of what might end up being discussed at either MFD or CFD. I encourage others to add to it, but within reason - this is not a substitute for discussion at either venue. Whether we decide to keep them or get rid of them, we'll likely still have to take it over there. It is not my goal to try to circumvent either venue; it is not merely about these specific examples or others like them, but the idea of them as a whole. I just want to nip this in the bud and give us some peace of mind. If you add something to this list, please leave a ping for the user who originally made it unless that user has already been pinged here.

Keep in mind that userboxes can also be categorized in a confrontational way, so on the face of it they may seem to express a message everyone can agree with, but in adding them to your own page you'll add a category you may not necessarily feel you belong in. Userboxes may be kept, but should be recategorized as the community sees fit. Feel free to point out problematic categorization wherever you see it. 

{{Template:User alt-right foe}}

Paging Buaidh (talk · contribs). Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 14:02, 7 October 2017 (UTC)

I agree, political userboxes should not add a user to a "Left/Right wing" or "Anti-Trump/Clinton" category, but to a category such as "Users that support Trump/Clinton". - ZLEA (Talk,Contribs) 17:07, 7 October 2017 (UTC)
We shouldn't even have those, since they don't support encyclopedic collaboration (likely the opposite), and the Trump vs. Clinton matter is already over anyway.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  21:56, 8 October 2017 (UTC)
  • Given that we are supposed to maintain a Neutral Point of View as editors, I don't think it appropriate to have any politically oriented user categories. Whether a user supports (or opposes) candidate X, Y or Z is irrelevant to writing and maintaining an encyclopedia.
And if we do decide to keep these categories, we should institute a topic ban to go with them... anyone who declares for or against a politician should be topic banned from editing articles that relate to that politician. Blueboar (talk)|
I hereby declare my strong opposition to Donald Trump and defy any editor to show that that has negatively affected my fairly active participation at Donald Trump since before the election. Just try a TBAN against me and see how far you get. Sorry but that's a non-starter. Besides, such a rule would do absolutely nothing for article quality, it would simply make POV editors keep quiet about their POVs. I agree that Wikipedia should be as apolitical as possible and editors should generally keep their political leanings to themselves (exception made in this comment for a good reason). ―Mandruss ☎ 18:02, 7 October 2017 (UTC)
You may have good intentions, but that's not a good idea. It presumes that any editor with any position strong enough that he/she mentions it on his/her userpage is automatically going to make NPOV-violating edits. This simply is not true, though. Master of Time (talk) 18:05, 7 October 2017 (UTC)
Interesting, I'd never heard that viewpoint before. That's certainly not what I'm concerned about, and it's not been the concern raised so far. What we're worried about is this causing schisms among editors, perhaps people refusing to collaborate with each other or getting to any degree antagonistic over issues as sensitive as political ones. Biased editing on related articles was definitely not something that crossed my mind. As far as the point you two are making, there's a difference between "Wikipedians interested in Donald Trump" and "Wikipedians against Donald Trump"; the earlier implies some sort of vested interest in actually bringing more information about him to the encyclopedia, aside from the more positive connotations "interested" tends to have, whereas the latter does not actually carry any implication of interest in editing in that topic area at all, making it a questionable use of userspace and category space. Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 21:08, 7 October 2017 (UTC)
I don't disagree with that. My previous comment was only about the TBAN-if-you-declare idea. WP:UBCR (emphasis theirs): "Userboxes must not be inflammatory or divisive." Inflammatory? Probably. Divisive? Definitely. ―Mandruss ☎ 21:19, 7 October 2017 (UTC)
I see. I don't know how I missed that part of Blueboar's post. My apologies. Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 21:34, 7 October 2017 (UTC)
A topic ban is definitely taking things too far. Concern over biased editing was not the spirit in which this RFC was started, and until now was not something I'd seen mentioned in discussion over this topic. As I said before, the concerns that folks like myself share is that it could foment discord among the userbase, making users reluctant to collaborate on certain topics or engage in certain discussions to avoid risking being antagonized for holding to one belief or another. Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 21:32, 7 October 2017 (UTC)
  • One, I hope we break out the rational arguments instead. Two, we can keep the petty mudslinging off the page. Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 20:55, 7 October 2017 (UTC)
  • Well, don't try to control how people express their opinions and you wont be accused of thought police. If I have a userbox saying 'I think the US president is a racist homophobic imbecile' vs 'I support the Democrats'. You could make a credible argument the first would be disallowed under BLP but any restrictions on the latter would just lead to the knock on effect of people complaining about every political position. Users advocating for gender legislation reform? That's a political position, cant have it on the userpage. Users in favour of gun control? Political position. Users with anti-racism statements? Political position. Unless you are going to blanket ban per Blueboar above *all* userboxes, this will never fly - as there will always be someone who disagrees politically with something or other. On a basic level a userbox that professes support for the LGBT movement is both offensive and inflammatory to a huge number of people. I will enjoy watching you attempt to get rid of them. Just let me know so I can get the popcorn ready. Only in death does duty end (talk) 15:28, 9 October 2017 (UTC)
  • You are making valid arguments but using needlessly uncivil language. No one here is trying to be the "thought police". This RFC was not to enforce some kind of deletionist solution to the problem. I'll accept the outcome whichever way it goes. I simply believe this needs to be discussed as while we have reached consensus in some of the discussions I've linked, there appear to be many more that could end up at MFD or CFD sooner or later, and rather than bombard people with notices of discussions in progress, it would just be easier to find examples and reach some kind of consensus here to prevent needless discussions. Whatever outcome we achieve here will be replicated on the individual discussions, thus invalidating the need for them and saving us a lot of time & work. I have only made my own thoughts on the matter clear, I have made no attempt to control the discussion or enforce any kind of outcome - you made a blatant personal attack with that accusation. Try helping us achieve a consensus rather than getting confrontational. Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 19:48, 9 October 2017 (UTC)
  • You could have just made your arguments in your original post and not gotten confrontational at any point. It would have been a very welcome contribution to this discussion. Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 20:03, 9 October 2017 (UTC)
  • It's somewhat pointless to call something a personal attack if it wouldn't stand a chance of a sanction following a traumatic 10-day train wreck at WP:ANI. "Thought police" would not. But it's unhelpful hyperbole; if this is a proposal to "control how people express their opinions", WP:UBCR is another one that already has community consensus. We do put reasonable limits on editor self-expression here, or try to do so with incomplete success. ―Mandruss ☎ 07:45, 13 October 2017 (UTC)
  • That it wouldn't stand a chance at ANI is not the point, and in fact is evidence that WP:CIVIL is increasingly irrelevant because people ignore it knowing that most transgressions against it won't be punished since it would take too long relative to the degree of slight that occurred. It is a personal attack, it's a false accusation. How people react to it does not at all define what it actually is.
You do have a point that Wikipedia already does try to control what users say on it, though, and to see that, look no further than WP:FORUM, which mandates that we relegate discussion on talk pages strictly to being about improving the articles to which they are attached. To pretend we have "free speech" here is laughable because Wikipedia is a private organization that can enforce whatever rules it damn well pleases on those who use it, not an attempt at any form of government that would have such obligations towards its citizens. Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 02:31, 14 October 2017 (UTC)
  • Zeke - I think other kinds for MFD would be (1) Coverage of something trivial and transient -- just momentarily viral on the internet and now no longer covered. In particular lately far too many articles about Trump (is it over 1,000 now?) where far far to many were some embarassingly trivial topic. (e.g. covfefe or high heels or hair or handshakes). Also MFD might be (2) Content present in more than 3 articles. I tend to think some of this was pasted into multiple spots and so winds up not a good fit to most places it was put. Markbassett (talk) 05:59, 8 October 2017 (UTC)
  • Having thought about this some more, I realize that another important concern is the treatment of our userspaces as social media profiles, which are so often used merely as a platform for expressing and promoting points of view while refusing to be challenged. Ideally, I would think interests and tastes are not described unless they either 1) are used to imply where you're most likely to see a particular editor working or 2) could influence that editor's contributions in any way. Me personally, I've left a lot unsaid about me on my own userpage only because I did not see its potential to contribute to my profile as an editor. I have my own political opinions, but I don't see the need to express them here, largely because I don't intend to contribute to political topic areas if I can help it. But enabling these sorts of things might leave the door open for mere soapboxing of the kind that we see so often on Facebook - things people say only to be heard, not to actually make the encyclopedia any better for having said it or getting any kind of dialogue going. More often than not, they're intended for people to accept and start believing in without any response whatsoever. After all, our userspaces are not really part of the encyclopedia, and people have to take our actual article content with a grain of salt as it is. Why would a userspace rant be any more reliable? And would they necessarily be posted with an eye toward making the encyclopedia around which userspace orbits any better? Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 00:51, 9 October 2017 (UTC)
  • I agree basically that we should not have categories that classify editors directly into any political or ideological mindset, particularly if they are just adding a userbox to their page (the userboxes are fine in this regards). Far too much potential for abuse internally and externally there. Fully agree that there is a problem if a user-box automatically includes an editor into a category, since that is ripe for problems if the user box is edited to include other categories by presumption. I don't see a problem on a user-page or user-boxes as long as all necessary content and behavior policies are followed (eg no BLP violations, political messages should remain civil, etc.),since the user is controlling that themselves. I would probably make a case that editors should not use user-page content to cast aspirations against an editor, under WP:NPA, so that people should be free to express their views to understand their editing patterns. --MASEM (t) 15:40, 9 October 2017 (UTC)
That last point is important.... adding political user tags can give the appearance of non-neutral editing, even when the actual editing may be neutral (or at least attempting to be neutral). I am concerned that these tags will lead other editors to dismiss a valid concern ("oh, we can dismiss this editor's concern... he/she is not neutral... see, he/she even proclaims their non-neutrality on their user page!"). In disputes, these tags will encourage others to focus on the editor, and not the actual edit. Blueboar (talk) 16:47, 9 October 2017 (UTC)
That type of concern should be handled by behavior around those making a deal of a user-tag, and should be called out as completely inappropriate, approaching an NPA warning, as otherwise we'd be questioning the differential between what is a political position versus other sentiments expressed by user-boxes. If an editor has a user box that says "I support the far right", we shouldn't care as long as their behavior in editing is not solely informed by that stance, and they follow all expected behavior patterns for editors. That's a whole problem of identity politics that is dominating the real world but shouldn't be a factor in editing on WP, and should actually be called out when people use that against editors when editor behavior otherwise does not warrant. Obviously, if we find a case of an editor that consistently edits uncollaborative with the POV represented by a user-box, that's a different situation that should be handled in a different manner. --MASEM (t) 17:04, 9 October 2017 (UTC)
Agreed. POV-editing should be handled on a case-by-case basis, and I really don't think userboxes should ever come into play in that situation - in fact, my experience would tell me the editors with the greatest problems concerning their biases would be ones whose usernames are redlinks because they didn't come to build a userpage, let alone an encyclopedia, so they wouldn't know or care about userboxes. The editors who take the time to actually use them are, in my book, far less likely to cause that kind of problem. Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 03:21, 10 October 2017 (UTC)

We really have no community consensus as to the role of p&g, a consensus that should form the bedrock for everything else. Some will say that p&g guide behavior, so we can speak of violations of it. Others say that p&g reflect behavior, and a p or g should be updated if there are enough editors ignoring it or unaware of it (in that case it follows that speaking of violations impedes the community's ability to form consensus). Ample support for both concepts can be found in policy and common practice. I have never understood how both can be true, but that's what we appear to have and it makes this kind of discussion problematic. This is "meta" and probably out-of-venue, so feel free to disregard or respond on my talk page (I would dearly love to understand this apparent paradox), but it also seems at the core of the frequent issues like this one. ―Mandruss ☎ 08:52, 13 October 2017 (UTC)

  • Categories are meant to allow easy access to topics that are connected. User categories are thus meant to allow to find users who share common characteristics which might be useful in improving the encyclopedia, broadly construed. So categories that group users by country, language, school etc. are good uses for categories, because you might need to find someone from country X, school Y, speaking language Z etc. Is there any need to find editors who support or oppose a certain politician? I can't think of one...
    Userboxes on the other hand serve a different purpose, they allow users to (positively) declare interests and (negatively) declare biases and thus are useful even when there is no reason to categorize such users. So a "Pro-Trump"/"Anti-Trump"/etc. userbox is definitely useful because it allows others to understand that some contributions might be tinged by a certain bias. Like Masem, I don't see a problem with that since contributions by people who take the time to declare their biases are usually made with more thought than by those who don't. Regards SoWhy 09:35, 13 October 2017 (UTC)
definitely useful because it allows others to understand that some contributions might be tinged by a certain bias. If I understand what you're saying, you have demonstrated the potential problem that Blueboar referred to above. I think we have more than enough false suspicions of POV editing held by people who fail to recognize/acknowledge their own bias, without feeding those people with ammunition for their ABF. Far from being "useful", it's both useless and destructive. ―Mandruss ☎ 11:30, 13 October 2017 (UTC)
I could certainly support userboxes ahead of user categories. Having too many on a certain subject might be something we look into solving, but that's probably another RFC. Userboxes are personal, and if this ends up changing the rules as to their content, that's fine too. If anything, we should look at it this way: Our policies on userboxes say one thing, but by and large, our userboxes, the things it supposedly governs, say a very different one, and the divide has only been allowed to grow over the years, especially these tense last few. It's obvious something needs to change there, whether any of us like the outcome or not. But categories definitely serve a different purpose on user pages compared to articles, which even serve a different purpose to those on talk pages, and so on. Being able to find someone based on potential political bias, if it is indeed helpful at all, has a far less obvious benefit than being able to find someone willing to make difficult blocks, provide copies of deleted pages, can provide some feedback on a much-needed topic area, or can potentially supply some good photography for a given subject. To put it simply, the categories define what a user can bring to the table of editing Wikipedia, and bias, one way or another, doesn't exactly have potential in that area. At best, it would merely show what might influence an editor for better or for worse. It wouldn't show some skillset this user has. Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 02:31, 14 October 2017 (UTC)
Here is a convenient way to find the editors who currently transclude {{User anti-Trump}}, just one of the many pro- or anti-Trump userboxes currently extant. I don't see much difference between the categories and the userboxes for the purposes of this discussion. Both have the same very real potential to impede the project's mission (building an encyclopedia), and both have little upside besides self-expression. In the end, Wikipedia is not a social networking site. This applies also to other divisive political userboxes such as {{User Black Lives}}, but I'm willing to limit scope for now. ―Mandruss ☎ 13:54, 14 October 2017 (UTC)
  • Remembering the Great Userbox Wars of 2006, I would suggest leaving them alone. They are not helpful, but the harm isn't as great as some people claim it is, and people really like to declare who they are and what they believe. Jimbo failed when he tried to make userbox policy by fiat. See WP:CSD#T1 and the links there. —Kusma (t·c) 14:06, 27 October 2017 (UTC)
  • Hmmm, I'm honestly intrigued. Out of interest, @Kusma:, was this "userbox war" also about political content, whether completely or as just one type of content under review? A bit of history would be helpful to this discussion - I think you've opened an interesting thought line here. Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 07:02, 2 November 2017 (UTC)
  • @Zeke, the Mad Horrorist: The most contentious userboxes were the political and religious ones like "This user is opposed to abortion", "This user supports the Labour Party", "This user is a Catholic". People noticed that it was possible to find like-minded users by their userboxes or categories (but it did not happen very often). Some people decided to stop this and tried to make user space (or at least template space) neutral. Kelly Martin then deleted hundreds of userboxes out-of-process in January 2006. I think she believed that Jimbo was backing this. The result was hundreds of unhappy users whose pages had ugly red links and a RfC that went off the rails and was restarted. In February 2006, Jimbo Wales and some others added the speedy deletion criterion "templates that are divisive and inflammatory", which was supposed to be used against userboxes. Most of these deletions were controversial, and so we had an extra subsection of DRV to deal with them: Wikipedia:Deletion review/Userbox debates. For months, the topic of userboxes was hotly debated. For example, some people suggested they should be subst-only (see WP:MACK, which also has lots of links to other parts of the debate). Eventually it became more or less accepted practice (see WP:GUS) that userboxes about a user's opinion were not OK in template space, but were OK to have in userspace (and transclusion was legal). This kind of keeps template space NPOV, while allowing people to disclose whatever they like in annoying little boxes. In any case, if you want to start any proposals in this area, I strongly suggest you read all of the discussions I linked you to, and keep in mind that some people really are strongly attached to their user pages and to how they look. I do not expect that getting rid of userboxes is either feasible or worth the effort and disruption, but you are welcome to prove me wrong. —Kusma (t·c) 09:58, 2 November 2017 (UTC)
As someone who watched that fracas from the sidelines, I'll confirm that as a fair summary of what happened. IMHO, the Userbox Wars is one of the least analyzed events in Wikipedia history -- none of the books I have read about Wikipedia mention it -- while having the most far-reaching influence on the community culture. Which means we are all doomed to repeat its mistakes. -- llywrch (talk) 18:36, 7 November 2017 (UTC)
  • Wikipedia:User categories already specifically cites a political example ("Wikipedians who dislike George W Bush") as inappropriate under "Categories that are divisive, provocative, or otherwise disruptive", and this also includes "support for or opposition to a controversial person, group, project, idea, policy, or activity", and all this on top of "Categories which group users by advocacy of a position" being inappropriate under the guideline. Meanwhile Wikipedia:Userboxes#Potentially divisive words sanctions userboxes about being for a political position but not ones for being against a political position, so along those lines political userboxes about being for something can be allowed (as long as they remain CIVIL). Alcherin (talk) 18:18, 27 October 2017 (UTC)
  • We already have guidelines that call for statements of support rather than of opposition in userboxes. Beyond that, we do not need the User Page PoliceTM. If you don't like somebody's userpage, don't look at it. But making them remove something about what they believe won't change the fact that they believe it, so WP:NPOV in article space is what really matters. --Tryptofish (talk) 21:55, 3 November 2017 (UTC)
  • Delete categories, keep userboxes - If a user makes an edit which appears to have a POV, I would much prefer that this be a bias declared openly on the userpage with a userbox than one which it's impossible for us to know. Userboxes are elements a user uses to show various facts about himself, and with the ability of any user to create his/her own, it's nearly impossible to find users by their bias. Categories, on the other hand, are primarily a tool to make such searching easier; users should only be categorized by those categories which a decent user who knows what (s)he's doing may be looking for in order to get help on Wikipedia or sister projects. עוד מישהו Od Mishehu 07:37, 6 November 2017 (UTC)
  • @Od Mishehu: it's nearly impossible to find users by their bias. Not so. It's a little more time-consuming because you can only find them for one userbox at a time (using "What links here"), but that hardly qualifies as "nearly impossible". The userbox galleries conveniently list enough userboxes in one place to get you started, and you can have a good list of a few dozen like-minded editors within a matter of perhaps 20 minutes. It's easily worth that much effort to be able to stack a discussion using email, no? And you only have to do it once, the same list can be re-used for any future discussions in the same topic area. A userbox can be advertised in a gallery whether it resides in user space or Template space, so there is no real difference for purposes of this discussion.
    But, according to Kusma's assessment above, self-governance means these efforts can be defeated by a sufficient number of I like my userboxes non-arguments, so Resistance Is Futile and I shall cease resisting. ―Mandruss ☎ 21:35, 20 November 2017 (UTC)
  • The point is that we don't need to find users by their bias. Finding users by their bias would be more useful for POV pushers than for NPOV enforcers. Indicating a user's bias is useful for judging his/her edits; finding users by their bias is unnecessary. עוד מישהו Od Mishehu 07:22, 21 November 2017 (UTC)
  • After re-reading that several times, I can only conclude that you completely misinterpreted my comments. I haven't said we need to find users by their bias. To the contrary, I've said that the ability to do so is dangerous, and I showed how it's easy to do so.
    And Indicating a user's bias is useful for judging his/her edits is just plain wrong. If we start using userboxes to "inform" judgments about POV-pushing, there will be two effects: 1. There will an increase in false positives, and there are already too many. I've been accused of POV pushing several times on the basis of one position in one discussion, and I've seen that happen to other good editors more times than I can count. The ability of the average editor to see bad faith where no bad faith exists is really quite remarkable, and the last thing we need is to exacerbate that problem by providing more fodder for false positives. 2. It will be easily gamed as true POV pushers will simply drop the userboxes or, better yet, declare the opposite bias. In short, that is a really, really bad idea. ―Mandruss ☎ 10:41, 23 November 2017 (UTC)
  • So you think someone will add a "Pro-Trump" userbox to their userpage and then when making anti-Trump edits will point to the userbox and say "Bias? What bias? I like the guy!"? That this would work as an argument in any discussion seems even more far-fetched than the idea that someone will start compiling lists of people with a certain userbox to accuse them of POV-editing. Besides, as Od Mishehu points out, userboxes are just a way for users to declare their interests and biases. Would you also forbid people from adding any such information in text-form? After all, that can be used against them as well. Regards SoWhy 11:44, 23 November 2017 (UTC)
  • 1. The point is that there is little correlation between bias and POV pushing. Every one of us has a bias whether we recognize it or not, and declaring that bias should not be used as fodder for false positives, which is an unavoidable side effect of what was suggested above.
    2. I have not suggested that someone will start compiling lists of people with a certain userbox to accuse them of POV-editing. I have suggested that some editors will undoubtedly use such lists to locate like-minded editors for canvassing purposes, and probably already are doing so. If you don't believe that a significant amount of canvassing is already done via email, I have some beachfront property in the Mojave Desert that you might be interested in. The "ends justify means" mentality is far too common for that not to be true, and a lot of it is in plain view for all to see.
    3. Your last comment is a classic example of "If we can't eliminate a problem completely, why bother making any improvement at all?" That is never a useful argument. Besides, do you know of a way to list editors who have declared a bias in text form?
    Regardless, as I said earlier, this whole debate is pointless if cogent reasoning can lose out to "I like my userboxes" comments supported by flimsy self-expression arguments (Wikipedia is not a social networking site) if supported at all, and the history of this issue, as described by Kusma above, indicates that's the reality. So I'll try once again to walk away from this thread. ―Mandruss ☎ 12:28, 23 November 2017 (UTC)
    POV editing isn't identical to POV pushing - the former is already being done in the first POV edit and can easily be the result of a bias even with no bad-faith intention; POV pushing is continually insisting on POV editing even after the user was asked to stop. עוד מישהו Od Mishehu 15:56, 28 November 2017 (UTC)

Break for navigation

Meaning no offense to Zeke, I think this discussion has been approached in a somewhat unfocused fashion. The process would be better served with a specific proposal and the current format is only going to invite in every wide-ranging perspective remotely connected to personal expression on Wikipedia, and encourage people to talk past one-another, as is already occurring above. That said, here are my thoughts on these sorts of categories and userboxes:

Personally, I think its manifestly evident that these sorts of boxes and especially the cats are problematic with regard to a whole array of issues relating to the signaling of POV and WP:Battleground behaviour; indeed, such categories of editor and flags of ideological positions would be ripe for exploitation by those editors inclined to form tag-teams and power-blocks on certain content issues--there is certainly no shortage of editors possessed of this sort of tunnel vision, especially in some of our more well known contentious topic areas.

However, the fact of the matter is that we don't even need to reach to WP:NPOV to see why it would be an ill-advised change in policy to start embracing such features for organizing editors by political allegiance. Because this notion already explicitly violates numerous principles found in WP:What Wikipedia is not, all of them representing broad and long-standing community consensus. Wikipedia is WP:NOTFREESPEECH, and the project doesn't exist to allow people to connect or to express themselves, and editors should not be in the habit of treating the project like a social media forum to broadcast their beliefs. That's Wikipedia 101. Now needless to say, we allow a certain amount of flexibility with regard to user pages, so that community members can establish their identity and embrace a little bit of the communal work spirit, bond over their shared editorial interests and be maintained in their enthusiasm for the project--and that's something to be valued. But allowing userboxes signaling opposition to a specific political candidate or office holder? Categories that aggregate editors by political philosophy? No, I'm sorry, but those kinds of behaviours/features have clearly leaped into WP:NOTHERE territory (even for those whose primary editorial concerns are in political topic areas) by signaling an individual's priorities or even advocating for political beliefs.

In short, editors should be keeping their personal perspectives out of their editorial work, so there's no pragmatic rationale for broadcasting their shared political affiliations on-project. And at the same time, they are not meant to be using this project as a platform for espousing their beliefs for personal reasons. So there's no context where these kinds of features make sense as permissible forms of open expression on the project--which, again, does not (and never has) guaranteed contributors unrestricted free speech. And again, that's before you look at all of the pragmatic reasons why it should not be allowed, because of the obvious problems with gamesmanship, canvassing, tag teaming, battleground attitudes, divisiveness, walled garden mentalities, aggregation of POV, vote stacking, confirmation bias, and just so, so many other issues that come along with allowing editors to gather under a particular political flag on-project. In other words, a WP:SNOW call for me. Though again, I'd like to see a more concrete solution proposed, rather than just having people affirm or reject that this is a problem. Snow let's rap 03:45, 30 November 2017 (UTC)

RfC about original research on ʻOumuamua

You might take a look at the RfC taking place at Talk:ʻOumuamua#Is the Inbound Velocity table original research?. It's a discussion on whether we're allowed to use the software tool JPL Horizons as a reliable source or if it's unpublished original research (WP:OR). This discussion has implications beyond the specific article. Can a piece of software (that is, an algorithm), run specifically to provide data to a Wikipedia article and not appearing anywhere else but Wikipedia, be considered a reliable published source; for example, in an inline citation? --RoyGoldsmith (talk) 17:41, 30 November 2017 (UTC)

Discussion at WP:REDLINK

I've started a discussion at Wikipedia talk:Red link#Where does this apply? regarding the scope of the guideline (in particular regarding user categories) - but remember to please keep the discussion civil. ansh666 21:15, 30 November 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

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

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. [7] 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)
https://www.youtube.com/watch?v=3aWAs7xNtbY 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.

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)

Responses

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)❤T☮C☺M☯ 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 - 2¢ 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 - 2¢ 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.

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) mind...it'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 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.

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.

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?

Tracked in Phabricator
Task T6521

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 [8].

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 [9]. 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 [10]. — 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.
$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 (talk • contribs) 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)

Closing

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.

Followup

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

RfC: Russian metro line article titles

See also: § RfC on naming of Chinese railway line articles

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. 77.180.49.189 (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. https://www.rmt.org.uk/news/tube-chaos-on-piccadilly-line/ has "Picadilly Line", a UK website, about a UK line. 78.53.140.207 (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. 78.53.140.207 (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? 77.180.49.189 (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? 92.231.182.37 (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.
92.231.182.37 (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 [11] while TASS uses an uppercase [12]. 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 [13]) and (uppercase [14]) The New York Times wavers between the colloquial name with uppercase [15] and the official name with lowercase [16]. 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 [17] 92.227.230.156 (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 92.227.230.156 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. 77.179.37.199 (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"? 92.231.183.209 (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? 92.231.183.209 (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. 77.179.78.253 (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. 77.179.78.253 (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. 77.179.76.40 (talk) 23:55, 9 December 2017 (UTC)

Comments regarding WP:USEENGLISH

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

They are as English as possible : NYC's BMT Fourth Avenue Line, Moscow's Filyovskaya Line. 77.179.76.40 (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. 77.179.78.253 (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 [18] 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" [19]? 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 [20]: 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)

Scope

Resolved

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

Status

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. 77.179.78.253 (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? 85.182.27.83 (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. 77.179.37.199 (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? 77.180.49.189 (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

 – 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 92.231.182.37 (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". 77.179.78.253 (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. 85.182.27.83 (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." 85.182.27.83 (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 "()"? 92.226.217.125 (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: [21][22]. 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) [23] 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) [24] 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. 78.55.248.119 (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

 – 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 213.39.186.49 (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. [25] "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. https://en.wiktionary.org/wiki/-year-old 78.55.248.119 (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. 77.179.37.199 (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)

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

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)

MOS:PN to MOS:CAPS merger

 – 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)
    No one proposed removing it, so I don't know what you're on about. The concept of "merge" here is "move content from one place to another, with a minimal changes only, to integrate it into the pre-existing material at the target page". It does not mean "delete the content and start from scratch".  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  16:54, 16 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. --slakr\ talk / 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)
Yeah, no one said anything about contradicting policy. Example: I hereby declare that the word "cat" on Wikipedia shall be taken to mean felid, since the word is often used this way in English: "the tiger is the largest living cat", "many of members of the cat family are nearing extinction". Felis catus, the domesticated species, is to be referred to as the "domestic cat" or "house cat". This proposition contradicts no policies. Do you think it's a guideline?  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  17:02, 16 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)
Right; that's a WP:PROJPAGE essay. We have many of them, and some of them are very good. They're not guidelines. It takes a tremendous amount of community buy-in to elevate one of those "topical RS" pages to guideline status, as we have done with WP:MEDRS. It doesn't happen unless the community considers it a really serious matter (e.g. people dying because they relied on bogus medical "information" in an article here).  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  17:02, 16 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)

CaCL:Support

  • 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.[26] 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.[27] 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 (t) Josve05a (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)

CaCL:Oppose

  • 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 Wikipedia.org 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.[28] 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)

CaCL:Other

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

CaCL:Discussion

  • 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., [29][, [30], [31], [32]). 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.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(policy)/Archive_138&oldid=1164510932"