Wikipedia:Village pump (policy)

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

Please see this FAQ page for a list of frequently rejected or ignored proposals.
« Older discussions, 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
Centralized discussion
Proposals: policy other Discussions Ideas
For a listing of ongoing discussions, see the dashboard.

Note: entries for inactive discussions, closed or not, should be moved to the archive.

Wikipedia:Disambiguation and inherently ambiguous titles[edit]

What guidance should WP:Disambiguation give for article titles that do not result in a conflict between two or more articles, but which are not inherently unambiguous to a general audience?

Background:

  • This content regarding titles that inherently lack precision was added to WP:DAB on June 6, 2015, by SMcCandlish, consisting of a paragraph under "Is there a Primary Topic?", an example under "Deciding to disambiguate", and a summary sentence in the lead paragraph: "Disambiguation may also be applied to a title that inherently lacks precision and would be likely to confuse readers if it is not clarified, even it does not presently result in a titling conflict between two or more articles." SMcCandlish posted a rationale of this addition to the talk page, which received no replies.
  • On July 16, 2015, Red Slash removed the main paragraph, with the comment "How does this have anything at all to do with disambiguation?". A talk page discussion between Red Slash and Francis Schonken discussed this removal.
  • On July 28, 2015, Red Slash removed the example under "Deciding to disambiguate". On August 6, this example was restored by SMcCandlish and again removed by Red Slash, then, on August 7, restored by SMCandlish, removed by Francis Schonken, again restored by SMcCandlish, and again removed by Francis Schonken. An RFC on the content from that time doesn't appear to have been officially closed, but by my count has three editors in support of the principle of "disambiguation for clarification" and three opposed.
  • In February 2016, the lead sentence (the only remaining portion of the content originally added June 6) was removed by Born2cycle, restored by by SMcCandlish, removed by BD2412, restored by Dicklyon, removed by Calidum, restored by Tony1, removed by Calidum, restored by Tony1, removed by Calidum, and restored by Bagumba who locked the page for edit warring. A talk page discussion did not result in any clear consensus.
  • On March 23, the lead sentence was removed by Dohn joe, restored by In ictu oculi, removed by Dohn joe, and restored by SMcCandlish. A further talk page discussion ensued.
  • With respect to the participants on both sides, the discussion of the proposed guideline so far has generated more heat than light. I'm hoping a straightforward and (pardon the pun) unambiguous RFC can resolve the issue somewhat permanently and put an end to the disruptions to WP:D. Two of the talk page discussions have proposed taking this to RFC, but don't seem to have been able to reach agreement even on what an RFC should look like. As I have not, to my recollection, participated in the dispute, I have done my best to frame it neutrally and been so bold as to just go ahead and post it here. Please let me know if I have missed anything salient in the above summary.--Trystan (talk) 02:34, 25 March 2016 (UTC)

Responses (disambiguation)[edit]

  • Comment: Parenthetical notes in an article title (unless the parenthetical notes are part of the article title) should only be used to distinguish between multiple articles with the same title. I can't think of a time when I would add a parenthetical dab to a title of an article when it didn't belong, merely to clarify something. Perhaps if some examples of contentious article titles were posted, we could see the nature of the dispute here. --Jayron32 03:11, 25 March 2016 (UTC)
This isn't a pertinent concern, since the disambiguation in question is always or at least virtually always done with natural, comma, or descriptive disambiguation (can anyone think of any exception?). For about two years, adherents to parenthetic disambiguation pushed for this at naturally ambiguous animal breed article titles as a WP:LOCALCONSENSUS gambit, and consistently failed to gain consensus for that (see WP:BREEDDAB for partial list of RMs and outcomes).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:53, 17 May 2016 (UTC)
  • No guidance. This kind of guidance is a can of worms - loads of unintended consequences. We should not "pre-disambiguate" an article because "it sounds too generic" or "that doesn't sound like it is an X" or "that sounds too similar to X". If there is an existing encyclopedic topic that shares a name with another topic, there is potential ambiguity, and we refer to WP:DAB's guidance. If there's only one topic, then WP:DAB does not come into the equation. The examples given to illustrate the contested guidance show that. "Flemish giant" - with no context - sounds like it might be a tall person from Antwerp. While this may be true, tall people from Flanders is not an encyclopedic topic. So instead, Flemish giant redirects to Flemish Giant rabbit - a domestic rabbit breed.

    But that's the point - "Flemish giant" redirects to "Flemish Giant rabbit". Why? Because there is no other encyclopedic topic to disambiguate from. Conversely, Algerian Arab is a dab page, while Algerian Arab sheep is an article about sheep. So in this case, "sheep" serves to disambiguate, while "rabbit" does not. If you prefer "Flemish Giant rabbit" for WP:CONSISTENCY purpose or something else, that's fine, but it's not actually disambiguating anything.

    So - there is actually nothing unusual here. Regular WP:DAB questions should be asked of any title. Those questions should not include "Doesn't that kind of sound like something else?" Dohn joe (talk) 03:45, 25 March 2016 (UTC)

"If you prefer 'Flemish Giant rabbit' for WP:CONSISTENCY purpose or something else, that's fine, but it's not actually disambiguating anything." OK, by your narrow definition, this is not actually disambiguating anything, in that there is no confusion what article you want if you say Flemish giant. Note, however, that by a broader definition, quite often that extra word that is "not necessary" does a lot of good in terms of improving precision and reducing ambiguity. Did you look at the railway station example I added? The point is that that minimalist titling that some espouse leaves things looking imprecise, and we have many examples of consensus naming conventions that don't interpret precision and ambiguity in this narrow B2C way. Dicklyon (talk) 03:52, 25 March 2016 (UTC)
Projects are allowed to develop naming conventions. They usually are exceptions to the precision/ambiguity criterion of WP:AT - see WP:USPLACE, WP:Naming conventions (UK Parliament constituencies), etc., referenced at WP:PRECISION. So, yes, consistency, or naturalness or some other consideration can override precision. But it should remain an exception that doesn't swallow the rule. Dohn joe (talk) 04:03, 25 March 2016 (UTC)
I'm pretty sure projects don't change, supercede, or make exceptions to policy and guidelines. And WP:PRECISION isn't overridden by having the article title "unambiguously define the topical scope of the article". People seem to ignore that provision, and treat precision as a negative when they could use a shorter title without a collision. That's the B2C algorithm, and it's nonsense. Dicklyon (talk) 05:03, 25 March 2016 (UTC)
I'd never seen Wikipedia:Naming conventions (UK Parliament constituencies) until today. I can't believe it exists. Curly Turkey 🍁 ¡gobble! 05:09, 25 March 2016 (UTC)
Your singular personal belief is not required to make things exists. The world, and the things in it, exist outside of your consciousness. --Jayron32 05:18, 25 March 2016 (UTC)
And the world outside the Wikipedia:Naming conventions (UK Parliament constituencies) basement has moved strongly against this pointless "disambiguation"—WProjects like WP:CANADA and WP:INDIA dropped this silliness years ago. So, what were you saying about "singular personal beliefs"? Curly Turkey 🍁 ¡gobble! 05:25, 25 March 2016 (UTC)
And yet, it still exists. Notice how you had a feeling or an emotion (you thought it "silly") and nothing changed. The world works like that: reality continues to keep being real despite you having feelings about it. It's odd you haven't learned that. --Jayron32 16:17, 25 March 2016 (UTC)
You don't appear to have a point. Curly Turkey 🍁 ¡gobble! 21:18, 25 March 2016 (UTC)
What Dohn joe is missing is that Algerian Arab was disambiguated to Algerian Arab sheep on the basis of it simply being naturally ambiguous. It only became a disambiguation page later. His 'So in this case, "sheep" serves to disambiguate, while "rabbit" does not' point is completely invalid. He doesn't appear to understand what "ambiguous" and "disambiguate" means. Neither do many of the other correspondents here. Fortunately, RM respondents often do. That's why Argentine Criollo, Welsh Black, British White, Florida White, and many other such names were disambiguated to more WP:PRECISE titles, despite no other article directly vying with them for the shorter ones.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  04:03, 26 March 2016 (UTC)
  • No guidance. WP:DAB was created to address a very specific situation – what to do when two or more articles share the same name. Everything else is covered by WP:AT and its spin-offs. For example, I'd consider Flemish Giant to be an inappropriate title (or at least less appropriate than Flemish Giant rabbit) because it fails WP:AT's "precision" criterion ("The title unambiguously identifies the article's subject..."). No extra guidance needs to be added to allow for titles like Flemish Giant rabbit, and any such guidance would be outside the scope of WP:DAB. DoctorKubla (talk) 09:39, 25 March 2016 (UTC)
  • Retain the guidance – and this RfC is non-neutral and grossly misleading due to major errors of omission: No policy rationale presented for removal, only false claims that consensus wasn't established. The material describes actual practice at WP:RM for 15 years, and actual requirements of various naming conventions (e.g. WP:USPLACE). Attempts to delete it are based on lack of basic understanding of the word "disambiguation" (it means "to resolve ambiguity"), patently false claims that previous discussion did not happen and that consensus wasn't established, and a minority, extremist view that WP:CONCISE trumps all other article naming criteria in every case, no matter what, despite the clear wording of the WP:AT policy. The RfC falsely paints a picture of a slow editwar. Actual review of the history shows two back-to-back consensus discussions, two different attempts to by parties that the RfC falsely paints as opponents to integrate the material into WP:AT policy itself, normal WP:BRD process and revision, 8 months of acceptance, the two drive-by attempts at deletion predicated on false claims and unawareness of previous discussion, which were reverted by multiple parties. See #Discussion (disambiguation) for details. This RfC, whatever its intent, would reverse much longer-standing portions of multiple stable naming conventions like USPLACE and WP:USSTATION, just for starters, yet none of the affected pages were notified. Three quarters of a year of stability is plenty evidence of consensus, especially after three consensus discussions refined the material to its present state.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:04, 25 March 2016 (UTC)
  • Recognize that disambiguation is more than one thing. Keep the guidance, as it deters those who try to use the omission (of recognition of this common practice of making titles non minimally short in order to make them more precise and less ambiguous) to drive toward a precision-is-bad minimality. 2620:0:1000:110A:71BE:75D9:749D:32C9 (talk) 19:42, 25 March 2016 (UTC)
That IP is me. Sorry for forgetting to log in, and expressing myself so poorly. The point is that disambiguation of this "unnecessary" sort is used, widely, in wikipedia, and is even encouraged in various naming guidelines and conventions, for the purpose of supporting the WP:CRITERIA or precision and recognizability. Those who argue against this use of disambiguation seem to want to take a very narrow view of what ambiguty is, and put zero value on precision. This approach is epitomized by the decade-long campaign of B2C for "title stability", described by him at User:Born2cycle#A_goal:_naming_stability_at_Wikipedia, where he espouses moving toward a system of unambiguous rules, essentially removing from editors the discretion to make titles more precise or less ambiguous than the shortest possible title that does not have a name conflict. To support this approach he has spent years rewording the recognizability, precision, naturalness, and consistency criteria to essentially minimize their value, leaving concisenss as the main criterion. I find this approach abhorrent. Dicklyon (talk) 16:44, 26 March 2016 (UTC)
There is ambiguity, and there is ambiguity that is relevant to WP:DISAMBIGUATION. They are not the same. Don't conflate them. The only ambiguity that has ever been relevant to WP:DISAMBIGUATION is when two are more titles on WP share the exact same WP:COMMONNAME. --В²C ☎ 21:33, 27 March 2016 (UTC)
See dictionary material I helpfully provided for you. What you just posted doesn't even parse. Disambiguation is removal of ambiguity. All ambiguity is relevant to disambiguation, and all disambiguation is relevant to ambiguity. Disambiguation doesn't magically refer to "only the ambiguity I want it to mean". You don't get to make up your own version of the language on the fly.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  21:00, 1 April 2016 (UTC)
  • No guidance from disambiguation should be created for article titles generally. If someone is looking for information about the Flemish Goose, which is very large and sometimes referred to as the Flemish Giant, then it is good to have the search box suggesting "Flemish Giant rabbit" as the only possibility before the person clicks and starts reading and is disappointed. Ditto for the Flemish Giant cross-stitch pattern. A recent example of a too-short page title that I came across was Hybrid name, which I moved to Hybrid name (botany) because on the talk page are such comments as "Why is this article written entirely from the point of view of plants, as if hybrid animals don't exist? We need to redress the balance." and the page itself had a tag "The examples and perspective in this article may not include all significant viewpoints. Please improve the article or discuss the issue. (May 2010)". The situation has clearly confused a few readers because although hybrid animals such as Ligers do exist, there is no special way of naming them, whereas for plants there is a detailed set of rules for creating scientific names. Sminthopsis84 (talk) 20:58, 25 March 2016 (UTC)
  • Retain guidance as it stands - This isn't even a properly presented RfC. What is the problem with the current guidelines and why does it need to be re-evaluated per WP:PG? All I'm seeing here is WP:JUSTDONTLIKEIT or something for the DRN (which would be rejected). --Iryna Harpy (talk) 21:53, 25 March 2016 (UTC)
  • No guidance. I feel that this sort of guidance should be integrated into WP:AT itself, if ever. I've been here on Wikipedia for a long time and I've always understood the WP:DAB guideline to only apply whenever two or more articles have ambiguous titles, and not merely because a non-ambiguous title sounds ambiguous. So such additional guidance that touches singularly on precision should be placed into WP:AT, where a more holistic look at the 5 criteria of good article titles should lead to better titles. Otherwise, the guidance placed on WP:DAB will seek to emphasize precision over the other criteria. —seav (talk) 03:26, 26 March 2016 (UTC)
  • Injection of some facts and reliable sources, since at least half the respondents here don't seem to understand what "disambiguate" means. It is not a made-up Wikipedian neologism, for "resolve a title conflict between two articles" (resolving such conflicts is simply the most common use of disambiguation on WP; it has never, in the entire history of the project, been the only one).
    1. Definition of disambiguate at Dictionary.com (Random House Dictionary [US] and Collins English Dictionary [UK]): RH: "to remove the ambiguity from; make unambiguous: In order to disambiguate the sentence 'She lectured on the famous passenger ship,' you'll have to write either 'lectured on board' or 'lectured about.'"; Collins: "to make (an ambiguous expression) unambiguous".[1]
      Definition of ambiguous: RH: "1. open to or having several possible meanings or interpretations; equivocal: an ambiguous answer; 2. Linguistics. (of an expression) exhibiting constructional homonymity; having two or more structural descriptions; 3. of doubtful or uncertain nature; difficult to comprehend, distinguish, or classify: a rock of ambiguous character; 4. lacking clearness or definiteness; obscure; indistinct: an ambiguous shape; an ambiguous future." Collins: "1. lacking clearness or definiteness; obscure; indistinct; 2. difficult to understand or classify; obscure."[2]
    2. Definition of disambiguate at OxfordDictionaries.com [UK & US]: "Remove uncertainty of meaning from (an ambiguous sentence, phrase, or other linguistic unit): 'word senses can be disambiguated by examining the context' ".[3][4]
      Definition of ambiguous: "(Of language) open to more than one interpretation; having a double meaning: 'the question is rather ambiguous', 'ambiguous phrases' ".[5][6]; "Not clear or decided".[7]. Note that the definition some people want to apply here as if it were the only one does not appear to be a language-related one: "Unclear or inexact because a choice between alternatives has not been made: 'this whole society is morally ambiguous', 'the election result was ambiguous' ".[8]
    3. Definition of disambiguate at Dictionary.Cambridge.org [UK & US]: "specialized to show the ​differences between two or more ​meanings ​clearly: Good ​dictionary ​definitions disambiguate between ​similar ​meanings."[9]
      Definition of ambiguous: "having or ​expressing more than one ​possible ​meaning, sometimes ​intentionally: The movie's ending is ambiguous. ... His ​reply to my ​question was ​somewhat ambiguous. The ​wording of the ​agreement is ambiguous. The ​government has been ambiguous on this ​issue."[10] "having more than one possible ​meaning, and therefore likely to cause confusion: Many ​companies are ​appealing against the ​ruling, because the ​wording is ambiguous."[11]:in "Business" tab
    4. Definition of disambiguate at Merriam-Webster.com/dictionary [US]: "to establish a single semantic or grammatical interpretation for".[12]
      Definition of ambiguous: "able to be understood in more than one way : having more than one possible meaning; not expressed or understood clearly; doubtful or uncertain especially from obscurity or indistinctness: eyes of an ambiguous color; capable of being understood in two or more possible senses or ways: an ambiguous smile; an ambiguous term; a deliberately ambiguous reply.[13] "Not expressed or understood clearly".[14]:Learner's Dictionary subsite
Shall we continue?  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  04:51, 26 March 2016 (UTC)
I think we all know what "disambiguation" means in the real world – however, I think it's one of those words, like "notability", that has acquired a very specific meaning in the world of Wikipedia. In the four years I've been here, I've only ever seen the word used in relation to article-title conflicts. WP:DAB, since its inception, has only ever been about article-title conflicts, and it's the broadening of the scope of this guideline that I object to. DoctorKubla (talk) 18:57, 26 March 2016 (UTC)
WP:REALWORLD. The nature of the discussion has made it very, very clear that "we" did not all know what disambiguation means at all. But let's back up and just look at WP:POLICY: "Wikipedia policy and guideline pages describe its principles and best-agreed practices. Policies explain and describe standards that all users should normally follow, while guidelines are meant to outline best practices for following those standards in specific contexts. Policies and guidelines should always be applied using reason and common sense. ... Guidelines are sets of best practices that are supported by consensus. Editors should attempt to follow guidelines, though they are best treated with common sense, and occasional exceptions may apply." There are entire naming convention guidelines that depend on this kind of precision disambiguation, and it is regularly performed at WP:RM; the "occasional exceptions [that] may apply" are so common they've often become codified as guidelines themselves! Ergo it has consensus, and it should be documented properly. It does not matter that the current draft of the WP:Disambiguation page only addresses title-collision disambiguation. It is not the only kind of disambiguation we do, and it never has been. We can wikilawyer for another year about what that draft says, and it will never change the facts about what Wikipedia actually does. There is no conflict of any kind between the wording you want to remove and actual WP practice, but there would be in removing it. By contrast, changing the WP:Notability guideline to use a broader definition of the word notable would instantly and radically conflict with actual WP practice. Notability here is a precise term of art with a particular definition laid out in detail at the top of that guideline; it's a criterion that causes results (e.g. article deletion). Disambiguation is simply a procedure, an action taken as a result of the application of other criteria, including precision and recognizability, after balancing their interaction with others, like conciseness. It's an apples and oranges comparison, except in that WP:Notability presently directly reflects WP consensus and best practices, and WP:Disambiguation did not until this was fixed 8 months ago; before then, and without the sentence you want to remove for no clearly articulated reason, the page reflects only some of standard WP disambiguation operating procedures, and pretends the others don't exist. All because people don't know what the damned word means. You're trying to disprove my point that some people are mistakenly treating "disambiguation" as some kind of special Wikipedianism, by trying to show that it's some kind of special Wikipedianism.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  22:35, 26 March 2016 (UTC)
Just because some people sometimes justify title choices based on real world disambiguation does not mean WP:DISAMBIGUATION is, should be, or ever was about real world disambiguation. Whether real world disambiguation should continue to be tolerated as a factor to consider in title selection is within the domain of WP:AT, not WP:D. --В²C ☎ 21:33, 27 March 2016 (UTC)
Since you're just repeating yourself, I will as well: See dictionary material I helpfully provided for you. What you just posted doesn't even parse. Disambiguation is removal of ambiguity. All ambiguity is relevant to disambiguation, and all disambiguation is relevant to ambiguity. Disambiguation doesn't magically refer to "only the ambiguity I want it to mean". You don't get to make up your own version of the language on the fly.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  21:30, 1 April 2016 (UTC)
WP:DISAMBIGUATION deals with how to resolve ambiguities among two or more titles of actual WP articles. When no actual ambiguities exist between actual WP article titles, then there is no need for WP:DISAMBIGUATION. Period. #NotThatDifficult. --В²C ☎ 20:15, 7 April 2016 (UTC)
  • No guidance. WP:DISAMBIGUATION has always been, and should always remain, limited to situations where two or more actual articles on WP share the same WP:COMMONNAME. --В²C ☎ 21:33, 27 March 2016 (UTC)
  • Delete per WP:IAR and WP:CREEP. It generally doesn't matter what the exact title of an article is and arguing about such titles is disruptive. Andrew D. (talk) 18:25, 30 March 2016 (UTC)
  • No guidance. Disambiguation was intended only to be used where multiple articles shared the same name. Preemptive disambiguation is unnecessary disambiguation and shouldn't be promoted. Calidum ¤ 02:14, 31 March 2016 (UTC)
Whose intention are you referring to? What about all the cases where it is used to reduce ambiguity and improve precision? Are you saying just define those as something different, not disambiguation? Or you're saying those are bad and we need to stop making titles more precise than the shortest possible title? Dicklyon (talk) 02:17, 31 March 2016 (UTC)
Dicklyon, I can't speak for Calidum, but conflating the WP and general meanings of "ambiguous" and "disambiguation" is not helpful, so I'll be precise about which one I mean. The point is that the merits of whether general ambiguity is a factor to consider when there is no actual WP ambiguity with another title is not a matter of WP:DISAMBIGUATION, but something for WP:AT to address. Perhaps it can be justified by WP:PRECISION, as you say. But unless there is an actual url conflict to resolve between two or more article titles, it's not a WP:DISAMBIGUATION situation, period. That's the point here, and therefore the wording in question has no place on WP:DISAMBIGUATION. --В²C ☎ 00:42, 1 April 2016 (UTC)
I hear what you're saying. But in the past you and others have pointed to this page to justify making titles less precise and more ambiguous. So having this page acknowledge that removing ambiguity has roles other than preventing article name collisions seems like a good thing that should stay. Dicklyon (talk) 02:30, 1 April 2016 (UTC)
@Dicklyon: Just asking for my own education – could you point me to an example of a discussion in which WP:DAB was cited as a justification for making an article title less precise? DoctorKubla (talk) 09:48, 1 April 2016 (UTC)
Here's one that opened just today: Talk:...Re_(film)#Requested_move_01_April_2016. It doesn't explicitly cite WP:DAB but relies on the theory that only name collisions matter and that ambiguity is otherwise fine. As you can see, editors other than Dohn joe are pretty much unanimous against this interpretation; maybe some of the other "no guidance" voices here will join him? Dicklyon (talk) 17:02, 1 April 2016 (UTC)
Another open case, not explicitly citing WP:DAB, is Talk:Ron_Walsh_(footballer)#Requested_move_13_March_2016; many primarytopic grabs are of this form; treat the disambiguating information as negative and argue that name collision can be avoided in other ways, so we must move to the more ambiguous title. Dicklyon (talk) 17:23, 1 April 2016 (UTC)
And here's a classic example from way back in 2008, with multiple editors on each side of the question: Talk:Bronson_Avenue_(Ottawa)#Requested_move; illustrating that editors often want to reduce ambiguity (disambiguate) even when there are not title collisions, and other editors point here and argue that's not OK per disambiguation guidelines. This one went on at great length and closed as "no consensus", meaning that the attempt to make the titles less precise and more ambiguous by citing "Unnecessary disambiguation" failed in that multiple-RM case. Dicklyon (talk) 01:18, 2 April 2016 (UTC)
  • Stop circumventing policy: Keep what became somewhat stable and take this up through the proper venue for making changes to policies and guidelines, that only in part includes this discussion. A problem I have is that there are errors in thinking and procedure.
Exemptions like boldly making changes that could be accepted by a broad community consensus, seems to only make confusion and possible perennial discussions on what should be more stable far more often than not. Changing policies and/or guidelines should not be done by edit warring, the apparent practice of BRD, or these "local" only discussions to definitively solve such local editing solutions concerning policies and guidelines. A continued practice of by-passing a procedural policy (protection for any long accepted broad community consensus) does not make it proper, makes a laughing stock of our policies and guidelines, and allows said policies and guidelines to be changed on a whim.
I am in support of retaining what is on the page because we can not right an error by a wrong procedure any more than we should attempt to edit war to create policy. I think this should be closed as consensus to move forward and follow procedure (to be brought up on the talk page), or an admin could move the discussion to the talk page so it can be listed everywhere relevant. The end result would mean leaving things as they are and settling it the right way. This would also reassert that policy should be followed. I would think, from this point, that only Wikilawyers would oppose following policy. Otr500 (talk) 06:31, 31 March 2016 (UTC)
Otr500, I, for one, cannot understand what you're saying, specifically what reasoning justifies "retaining what is on the page". What is on the page is the result of edit warring; the point of this discussion is to decide in a more thoughtful process whether it should be retained or not. This discussion has been publicized at the talk page; previous discussions there did not lead to consensus, so someone thought maybe we could have a more productive discussion here. Again, I don't understand what exactly you're saying, much less why. Please clarify. --В²C ☎ 00:34, 1 April 2016 (UTC)
@ B2C: Read the procedural policy. Because you can't here me (I don't understand "exactly" what you are saying) does not mean that others can't. I thought listing in two places, in bold, would be pretty clear as I didn't use any big words. Keep seemed pretty clear and retaining what is on the page equally understandable so I will assume (and hope) a miscommunication would be in the reasoning.
    • "If consensus for broad community support has not developed after a reasonable time period, the proposal is considered failed. If consensus is neutral or unclear on the issue and unlikely to improve, the proposal has likewise failed.". A discussion to a conclusion, that might involve an admin, would normally stop edit warring. Editors that find themselves in such a position, especially seasoned editors here to build a good encyclopedia, should self include Wikipedia:Edit_warring#Other_revert_rules to include 1RR (one-revert rule) or 0RR (zero-revert rule) and not use reverts to include team reverts to push a POV. I could expect this on articles but policies and guidelines should enjoy more prudence.
"Stop" means exactly what it states and I can provide a definition if that is unclear. Any "edit warring" began at a point and I saw nobody argue with what @SMcCandlish: stated that there were 8 months of stability. Maybe you missed that or didn't understand, and IF I missed something specifically please point it out instead of not understanding everything. I am stating: There should be no edit warring on policy changes or attempted changes. Clear on that? If not you might consider reading the procedural policy again.
To argue that disambiguation has only one meaning does not make it true and that it should stand alone is not policy. Policies should not conflict nor should guidelines conflict with policy. IF WP:AT needs to mention disambiguation and point to a guideline, to make better article titles, then what in the world is the problem with that. What we have is editors that sometimes have a POV and sometimes promote it the tenth degree and Wikipedia enhancement be damned.
Support for the below mentioned Flemish Giant over Flemish Giant rabbit has proven in many article discussions to be against consensus. To support Flemish Giant (rabbit) has also be shown to largely be against consensus preferring natural over parenthetical disambiguation. To try to ride a dead horse that disambiguation means only one thing just does not make it fact.
There is no need to change Belgian Hare but Blanc de Bouscat would be vague to the average reader. It has become practice (like it or not) to clarify titles like this by adding the breed and without the parenthetical disambiguation. Brackets around a word is not the only determining factor of disambiguation. Die-hard Britannica fans do not like this but Wikipedia does not have to be a sister site. Discussions have shown consensus has moved away from Britannica style parenthetical disambiguation, preferring to add the breed as part of the title, and to naturally disambiguate to prevent ambiguity and have consistency within articles, when we are deciding on an article title. Maybe we should examine the little active but relevant essay Wikipedia:Consistency in article titles? This does not mean that such practice of using parenthetical disambiguation is bad, or against policy, but used as an exception.
Sometimes accepted practice (by consensus) already shows the direction of community consensus, without trying to confuse the issue. Adding clarity so that new articles can follow accepted practice without large debates is not a bad thing. This prevents (as mentioned in above discussions) titles like Beveren (rabbit) (unassessed article with no talk page activity at this time), British Lop (stub class that is not a rabbit but a pig), English Lop (that is a rabbit and not a pig), French Lop (that is a rabbit), from Lop Nur, that is not a rabbit or sheep but a lake, and so articles like Welsh Mountain sheep are more clear (less vague) and differentiate (take away ambiguity that is still to disambiguate) a mountain from sheep.
Real world versus Wikipedia world: It doesn't matter because we are not talking animated or other world characters versus real world people. We are talking clarity versus unclear, precise versus concise, parenthetical disambiguation verses natural disambiguation. Leaning towards concise verses leaning towards precision. This should not be a battle. We use balance to name articles, as well as source and community consensus, and sometimes leaning one way or the other is not a bad thing, actually justifiable, and adding article consistency among titles helps and carries broad community consensus. Disambiguation, in the form of adding a word for clarity, does not mean we are promoting precision over concise. It means we are adding some precision so that the precise title name is more clear and less vague, and follows other like article naming. It does not matter how much we wikiLawyer this it is still disambiguation but I am sure we must because that is what lawyers have to do right?
Mr. B2C stated he can not understand what I am saying, and I hope not because of any personal inabilities. This discussion should be on the relevant talk page. The procedural policy, and I will type slow for clarity, states "Authors can request early-stage feedback at Wikipedia's village pump for idea incubation and from any relevant WikiProjects. Amendments to a proposal can be discussed on its talk page.". "start an RfC for your policy or guideline proposal in a new section on the talk page, and include the "rfc|policy" tag...". "The "proposed" template should be placed at the top of the proposed page; this tag will get the proposal properly categorized". These are ways to prevent edit warring and discussions from taking place, all over the place, as well as to ensure broad community consensus is followed, and so that changes made to policy by consensus is transparent, being on the relevant talk page. Listing a discussion here, as well as other relevant places, would be to point to a discussion on that talk page not have continued splintered discussions in many places.
Or; we can just make this a perennial discussion to be brought up over and over again. A lot of times this does not deter community practices as reflected by broad community consensus, no matter how much we discuss a supposed issue. Here is some fantastic reading: What to do if you see edit-warring behavior and How experienced editors avoid becoming involved in edit wars. That is why I stated that a discussion here is not a definitive solution but to gather consensus (not battle) that should be continued on the talk page to effect broad community consensus continuation or change. Otr500 (talk) 10:22, 1 April 2016 (UTC)
To compress and get to what I think the gist is of Otr500's multi-paragraph, multi-indent-level post above, and cut through a lot of the other chatter here: Eight months ago, WP:DAB was updated to describe actual practice, which is what guidelines are form as a matter of WP:POLICY. There were multiple BRD discussions about the then-long wording. The language was refined, and a short version (the sentence at issue here) was retained. Two thirds of a year later, two editors (B2C and Dohn joe) attempted to delete it on the patently false basis that it had not been discussed. Not only are their facts wrong, they cannot even formulate a cogent reason why it should be removed, just hand-wave a lot, in ways that have confused a few other people into supporting removal of it from its present location, though plenty of others support its retention. Notably, many of those who don't want to keep it where it is right now think it should be moved into WP:AT policy instead. This was also discussed 8 months ago at WT:AT and the decision was to not merge it into AT policy. This is now stable guideline language. A proper closure analysis of this confused and confusing pseudo-RfC should conclude with no consensus to remove the material (since the arguments for keeping it are valid and those for removing it are not, ergo the original consensus to include the material has not changed), and no consensus to merge it into AT policy, because that idea has already been rejected, and no new rationale for why this should rise to policy level has been provided, so again consensus has not changed. There are thousands of things in various guidelines that are relevant to various policies but which remain in guidelines and are not merged into policies, because they are not policy material, but guideline material. This is not mystically different somehow. In absence of any showing that the material does not actually describe long-established WP:RM and disambiguation practice, which it clearly does, the sentence remains in the guideline. Suggesting that it can be removed when it was arrived at through multiple consensus discussions, now that a new discussion to possibly move it into policy fails to come to consensus for that idea, would be patent WP:GAMING. One could just as easily propose that, say, WP:Citing sources should be merged into WP:V policy, and then when that proposal failed to gain consensus, delete the guideline on citing sources! WP does not work that way. Nothing works that way.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  21:30, 1 April 2016 (UTC)
  • WP:Disambiguation overreaches with respect to minimalist disambiguation, at the expense of the reader, at the expense of naming criteria "recognizability", "precision" and "consistency". If inclusion of a parenthetical term helps, it should be used, subject to balancing recognizability, naturalness, precision, concision, and consistency, and other good things even if not documented. Parentheses should be avoided, but inclusion does not make WP:Disambiguation a trump card. --SmokeyJoe (talk) 01:05, 1 April 2016 (UTC)
    • Aye. I most cases where this comes up, we use natural disambiguation simply because such a phrase exists in the reliable sources already, and the policy tells use to favor natural over parenthetic disambiguation when possible.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  21:30, 1 April 2016 (UTC)
  • Retain guidance – A title like "Flemish Giant" benefits no one. Most importantly, it does not benefit the reader, because it does not clearly define the subject. Shorter titles are not always better. WP:AT does not suggest this, but certain editors continue to the push this notion to the detriment of our readers. It is important that the disambiguation policy does not result in an automatic removal of bits of titles that do not serve to disambiguate from other Wikipedia articles, but do serve to clearly define the topic of the article in line with WP:AT, as Mr Lyon suggested above. The guidance as it stands allows for this to be made clear. RGloucester — ☎ 02:45, 1 April 2016 (UTC)
  • Retain the guidance. There has been a reluctance among some of the players to see disambiguation in terms of our readers. B2C's long campaign for a narrow algorithm-like solution was an utter disaster. Tony (talk) 13:42, 1 April 2016 (UTC)
    • Just for those unaware of it, three times (at least) Born2cycle has agitated for concision-above-all-other-concerns changes to article titles policy and RM procedures, citing personal essays of his on the topic as if they were guidelines. In all three cases WP:MFD userspaced them as anti-policy nonsense [15], [16], [17].  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  21:30, 1 April 2016 (UTC)
  • Data point Life is too precious to read all the above, but I once was in an argument over Memorial Hall (Harvard University). This other editor said it should be simply Memorial Hall since, at that moment, no other Memorial Hall had an article -- and apparently guidelines supported that knuckleheaded approach. Anything that remedies that would be welcome. EEng 19:53, 2 April 2016 (UTC)
This reminds me of National Pension Scheme. (Surprise! It's specifically about India.) ╠╣uw [talk] 10:22, 12 April 2016 (UTC)
Per WP:NATURAL policy, the proper titles would use natural disambiguation as first choice. But in both cases ("Harvard Memorial Hall", "Indian National Pension Scheme"), it results in a new ambiguity (which I needn't spell out here). The obvious solution is WP:COMMADIS: "Memorial Hall, Harvard" (adding "University" seems superfluous, per WP:CONCISE), and "National Pension Scheme, India", or WP:DESCRIPTDIS in the latter case, "National Pension Scheme of India". Both "Memorial Hall, Harvard" and "National Pension Scheme of India" actually border on alternative NATURALDIS, and are attested in sources.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:04, 17 May 2016 (UTC)
  • Retain the guidance since the lengthy discussion above and below has convinced me that this is useful guidance to editors in encouraging a better and less frustrating experience for our readers. BushelCandle (talk) 06:59, 3 April 2016 (UTC)
  • No guidance as I agree wholeheartedly with DoctorKubla. -- Tavix (talk) 12:24, 5 April 2016 (UTC)
  • Retain the guidance. I am also irked by the Memorial Hall (Harvard University) example provided by EEng and similar ones – articles about obscure things with common-sounding (i.e. wikt:ambiguous) names do benefit from some extra WP:PRECISION. Doing otherwise easily confuses the readers (as the context is often not enough to quickly conclude what the topic is, and matches displayed in the search box do not provide any hint about the topic) and editors (quite easy mislinking) alike. Of course, case-by-case examination is always welcome, but we do not apply WP:CONCISE at all costs. No such user (talk) 15:35, 6 April 2016 (UTC)
    • I, for one, do not call for applying WP:CONCISE at all costs. To the contrary. I call for applying it primarily as a "tie breaker". When considering all other WP:CRITERIA there is no clear answer, then go with the more concise one. It is that simple. But the main point her is that all this is WP:AT consideration; it has nothing to do with WP:DISAMBIGUATION. --В²C ☎ 20:07, 7 April 2016 (UTC)
  • Retain the guidance. It's reasonable to note that some titles may be ambiguous or likely to confuse a reader even if they don't exactly match any other titles, and I'm fine with having at least a modicum of text into the guideline to explain this. I understand that some prefer the term "disambiguation" to be defined more narrowly as just the mechanical process of distinguishing between otherwise identical Wikipedia titles, but I don't think that's particularly useful. There can be (and often is) a difference between what's merely technically ambiguous and what's actually ambiguous, and the latter can be a valid consideration when determining the best title for our readers. ╠╣uw [talk] 19:01, 11 April 2016 (UTC)
  • Change names The simplest thing to do would be to change the names. — Preceding unsigned comment added by Shinyapple (talk • contribs) 01:22, 30 April 2016 (UTC)
  • Retain guidance What useful purpose is served by inherently ambiguous titles, even when this is the sole article? Pincrete (talk) 21:37, 6 May 2016 (UTC)
  • Retain Guidance Why would we remove relevant information that helps users avoid pointless move discussions. I have seen time and again pointless move requests to ambiguous titles that fail precision.  InsertCleverPhraseHere  03:23, 15 May 2016 (UTC)
And numerous RMs have closed with the opposite result. Calidum ¤ 03:48, 16 May 2016 (UTC)
Not in the case of naturally ambiguous titles. They get resolved one way or another, and this way is much more common that the deleters here understand or admit. (Often a notably different alternative name is available, but when one is not, all that is left is some form of disambiguation).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:08, 17 May 2016 (UTC)
  • Retain guidance (and apply with common sense). There are situations where reduction of ambiguity is desirable even though there may be only one article with the title. This doesn't mean every potential ambiguity must be "pre-disambiguated", but we should not prohibit this. older ≠ wiser 17:11, 17 May 2016 (UTC)
  • No guidance; at least, not on connection with disambiguation. If there should be guidance of this sort at WP:AT, that is a different discussion. bd2412 T 17:23, 17 May 2016 (UTC)
    • One that was already had about a year ago, and consensus did not agree to import this wording from the guideline. Deletionists don't get to nuke stable guideline wording they don't like by re-proposing failed merges to policy, then pretending that's an argument against retaining it where it was originally. Could kill any guideline on sight with that tactic. Guidelines are guidelines for a reason, because they are not policy material. A simple observation of fact, that WP disambiguates for more that one reason (though one reason is certainly the most common) is not a policy matter, but a guideline matter. It does not tell us to do or not do anything, it describes actual practice.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:15, 17 May 2016 (UTC)
  • No guidance: As a user of Wikipedia, even years before I joined, it was clear that the bizarre term "?disambiguate" on Wikipedia meant to figure out the title of the article you were looking for when multiple articles have similar titles. I thought it was some term a bunch of geeks made up, proud of their $10 word a bit like the International Obfuscated C Code Contest. (When I first learned C and heard the term "obfuscated", I was confused, and apparently, that was intentional.) I always assumed there was a better more common sense way to describe how to find the correct title than "disambiguation", but now we just accept it. I read a lot, and I have, never, ever seen the word "disambiguate" used anywhere else, although "obfuscate" sometimes. Good writing should avoid unnecessary $10 words [18]. To find more than one use for this $10 word on Wikipedia is a mistake. The word "disambiguate" needs to be "disambiguated"! --David Tornheim (talk) 12:21, 4 June 2016 (UTC)
  • No guidance: this is WP:AT matter, not WP:D matter. A general "non-disambiguating disambiguator" guidance is not a good idea: it didn't get accepted at WP:AT (see ample prior discussion), not a good idea to insert some WP:AT-conflicting guidance into the WP:D guideline. Note that specific naming conventions contain guidance against using "non-disambiguating disambiguators" in certain cases (e.g. Wikipedia:Naming conventions (books)#Precision): not a good idea to add some conflicting guidance elsewhere (in other words: this is WP:RULECRUFT, ready to open up endless discussions again). For me WP:CRITERIA suffises, combined with what can be found in naming conventions for specific cases (e.g. Wikipedia:Naming conventions (music)#Articles in series implying that some article titles in specific series will contain extensions in a uniform format on top of what is necessary for disambiguation alone). The WP:D insertion under discussion here tries to shift the balance among the five WP:AT criteria: it tries to give the "precision" criterion some sort of over-all advantage over the "conciseness" criterion, contrary to the balance between these criteria in the policy. When such shift of balance would be needed (which I doubt), that should be hashed out at WT:AT and not at a guideline that is not even directly about article titling, and thus tries to get an upper hand over a policy. --Francis Schonken (talk) 06:17, 19 June 2016 (UTC)
    • For clarity: afaics this RfC was not properly notified to WT:AT, not even after unarchiving, despite that it has been suggested multiple times that this is in fact WP:AT matter. So far so good, but then below it is advocated that no "WP:AT/WP:MOS regular (...) should close" this RfC. So please make up your mind: either notify WT:AT and WT:MOS that this RfC is going on, so that said regulars are invited to express their opinion in this RfC, or retract objections that said regulars couldn't close this as uninvolved. --Francis Schonken (talk) 05:16, 19 June 2016 (UTC)

Discussion (disambiguation)[edit]

  • More detailed background: Attempts to delete part of the guideline, which was established through standard consensus-building discussion and revision many months ago, are predicated on two obvious fallacies: 1) That "disambiguate" is a made-up Wikipedian neologism for "prevent article title collisions". Check any dictionary; it's a plain-English word meaning "to resolve ambiguity"; doing so to prevent title collisions is simply the most common reason we disambiguate and has never been the only one. 2) That WP:CONCISE is akin to a law, and that the most concise possible name must always be chosen no matter what. Actually read WP:AT policy – all of the WP:CRITERIA are considered, and balanced against each other; the overriding concern is not following any "rule" bureaucratically, but ensuring clarity for readers. The naming criteria "should be seen as goals, not as rules. For most topics, there is a simple and obvious title that meets these goals satisfactorily. If so, use it as a straightforward choice. However, in some cases the choice is not so obvious. It may be necessary to favor one or more of these goals over the others."

    The previous debates about this guidance are misrepresented in the the summary in the RfC, which incorrectly paints it as a slow editwar instead of removal, discussion, refinement, acceptance, then much latter isolated attempts to delete it without a rationale. In the original discussions 8 months ago here and here, Red Slash tried to move it into policy itself at WP:AT (rejected), objections were raised about iit original length (it was shortened), and about particular examples it use (removed); the principal objector was Francis Schonken, on the basis of having made a proposal to rewrite AT in ways that would have integrated this and made various other changes (which did not achieve consensus at AT). After revision, the short version of this material was accepted in WP:Disambiguation without incident since that second discussion. This is standard WP:BRD operating procedure, and this revision and resolution process is how consensus is established. By August, the principal objector, Schonken, was removing attempts to reinserted expanded wording and examples [19] but retaining the agreed short version from prior discussions [20], which had already been accepted for two months. It remained uncontroverted for 6 more months, clearly long enough for consensus to be established, especially in a much-watchlisted guideline we use every single day.

    It was drive-by deleted in Feb. by Born2Cycle, with a bogus claim that discussion didn't happen and consensus was not been established [21]. This is is part of his years-long, tendentious campaign to promote WP:CONCISE as some kind of "super-criterion" that trumps all other concerns – which WP:MFD has rejected three times in a row: 1, 2, 3. The recent attempt by Dohn joe to delete material was predicated on his unawareness of the February discussion (which is mischaracterizing as being against inclusion when it was not) [22], his misunderstanding of previous discussions (see WT:Disambiguation#Restored content on precision cut from lead, which covers much of what I've outline here in more detail), and more false claims that consensus was not established.

    After 8 months of stability, the burden is on would-be deleters to demonstrate what the supposed problem is, and provide actual evidence that WP-wide consensus that such precision-and-recognizability disambiguations are permissible when necessary has somehow disappeared all of a sudden. This RfC, and two editors' PoV against this part of WP:DAB, would undo very long-standing naming conventions that call for this kind of precision-and-recognizability disambiguation, like WP:USPLACE and WP:USSTATION, and fly in the face of years of common sense decisions at RM, like the disambiguation of Algerian Arab (now a disambiguation page) to Algerian Arab sheep, and British White to British White cattle. Per WP:POLICY, the purpose of guidelines is to record actual community best practice, not try to force someone's made up idea about how things should be, like changing the meaning of English words, or preventing RM from doing what RM routinely does. Retaining this does the former, and removing it does the latter, both to pretend the word "disambiguation" doesn't mean what it means, and as to elevate concision above every other criterion, against the clear wording of policy.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:04, 25 March 2016 (UTC)

  • Comments (since there seems to be confusion): Wait! You mean I just don't like it doesn't mean we can change things just because? How about used in conjunction with and while ignoring all rules.
We have many policies and guidelines and a single one can not be used in disregard of others. I was under the impression we can not ignore all rules, if it is against consensus, even if we don't like it, unless we can sneak it in under the radar. FYI -- we should not really (according to policy) attempt to make or change policy by using WP:BRD unless we "ignore" the policy on Proposals and Good practice for proposals. The first states: "Proposals for new guidelines and policies require discussion and a high level of consensus from the entire community for promotion to guideline or policy.". The second: "If consensus for broad community support has not developed after a reasonable time period, the proposal is considered failed. If consensus is neutral or unclear on the issue and unlikely to improve, the proposal has likewise failed.".
Further, the procedural policy explains the process in detail that is located in the second part. A request for comments here is only one part of that process and not a determining factor for an outcome. Some confusion at Wikipedia:How to contribute to Wikipedia guidance#Policy discussions seems to be at odds with policy and may contribute to errors. Policy (Good practice for proposals) states the process for any proposed changes to policy:
1)- The first step is to write the best initial proposal that you can.
2)- Authors can request early-stage feedback at Wikipedia's village pump for idea incubation and from any relevant WikiProjects.
3)- Once it is thought that the initial proposal is well-written, and the issues sufficiently discussed among early participants to create a proposal that has a solid chance of success with the broader community, start an RfC for your policy or guideline proposal in a new section on the talk page, and include the {rfc tag along with a brief, time-stamped explanation of the proposal.
4)- A RfC should typically be announced at this policy page (and/or the proposals page, and other potentially interested groups (WikiProjects).
There appears to be some confusion at Wikipedia:Centralized discussion concerning sequence or location but policy seems clear.
DAB: Does cover the topic question above as well as WP:AT. Although there are editors that seem to prefer parenthetical disambiguation, or unnecessary use of such on article titles (Britannica style), this has not been established by any broad consensus but more just the opposite according to policy natural disambiguation is preferred and parenthetical disambiguation as a last choice. The etymology of "disambiguation" would be "not unclear" which would be "not clarified". An article title should be precise enough to unambiguously define the topical scope of the article, but no more precise than that.. Recognizable, natural, and concise goes along with this. DAB states: "Disambiguation is also sometimes employed if the name is too ambiguous, despite not conflicting with another article (yet),". Consistency also goes along with these and gives more than one reason why we have Flemish Giant rabbit, Continental Giant rabbit, French Lop, Lop rabbit, Angora rabbit, and so forth. Certainly using the more common name according to references. Common sense is also thrown in there somewhere.
Conclusion: We should not attempt to change or change policies or guidelines on a whim or by any local consensus. The process is made somewhat complicated to prevent easy changes. DAB and AT do a fine job. I think if editors disagree then they should probably follow the above procedures. Otr500 (talk) 12:39, 26 March 2016 (UTC)
The portion of WP:DAB that you quote was added a couple of days ago. A clear consensus in support of this recent addition would neatly resolve the difficulty of having an orphaned sentence in the lead that isn't explained in the body of the guideline.--Trystan (talk) 18:50, 27 March 2016 (UTC)
It's also based on material present in the original, longer version. The WP:GAME here is to keep whittling away at the material in hopes that it can be made to seem out-of-place in its context. If context is restored, it's obviously belongs where it is. This was true 8 months ago, when the context material was originally reduced, on the basis (Francis Schonken's objection) that the example article titles were "unstable". This wasn't actually true then, and 8 months have proven conclusively that it's not true now, so the original rationale to decontextualizing the sentence has evaporated. Better yet, later editors like Dick Lyon have pointed out that entire NC guidelines, like USPLACE and USSTATION, rely on the exact same principle and have for years, so the examples Schonken didn't like almost a year ago were could have been replaced at any time anyway. A challenge against this provision now is a challenge against multiple naming conventions that have been stable for years.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  21:59, 1 April 2016 (UTC)

Request for closure[edit]

This RfC was archived by the bot before having been closed. I would suggest that an administrator close it. RGloucester — ☎ 18:28, 23 April 2016 (UTC)

  • Shall this long expired RfC ever be closed, or shall it languish here for eternity? RGloucester — ☎ 00:23, 12 May 2016 (UTC)
    • All the above effort should have been put into something that actually matters. 217.44.215.253 (talk) 11:57, 16 May 2016 (UTC)
      • It matters plenty, since dispute keeps erupting about this, on policy and guideline talk pages, and in RMs, and elsewhere. The real time drain is the recurrent disputation, not the attempt to resolve it with an RfC. In the end, this can only reasonably close one way, or be consensus-reviewed without a close (not all RfCs must have formal closure and consensus determination by common sense doesn't require it) in one way: to retain the guidance. Let's review:
        • It's been stable for a year+; the original objections to it were mooted by later tweaks (i.e., objections ceased, and the changes the original objectors insisted on were accepted, resulting in a consensus).
        • We've since learned it agrees with multiple long-term naming conventions that weren't even considered when it was written and which were not taken into account by any objections, then or now.
        • It codifies actual practice that has been ongoing the entire time WP has existed.
        • In just a few topics we’ve bothered looking at, the last two years or so produced somewhere between dozens and a hundred RMs that did exactly what the wording suggested, before and after the wording, and with and without naming conventions behind them. The community gets it, even if some editors do not or will not.
        • The wording was clarified and improved further in response to issues raised by the RfC (though there has been back-and-forth reverting about this [23], [24], [25], followed by excessive rewriting (without discussion or consensus) that has tried to eliminate every trace of the wording at issue, in mid-RfC, as shown in this multi-edit diff; this has been very partially reverted [26] to preserve some hint of the material, pending RfC closure.
        • Nothing at all negative has happened on the basis of this wording despite this RfC languishing unclosed (it has not been over-applied to do stupid things, nor was it applied this way before the RfC, and cases which actually need this sort of disambiguation of naturally ambiguous names have been proceeding as if nothing happened. Or they had been. Now confusion and dispute has arisen in the wake of attempts to delete the material during the RfC; e.g. this other RfC has quite a number of editors in favor of such disambiguation in certain kinds of song-title cases, while others suddenly don't seem to think it is possible/permissible, obviously because of FUD surrounding the WP:DAB wording. [Not all support/oppose at that RfC relates to this matter, however; some of it is about WP:CONSISTENCY vs. WP:CONCISE, etc. But at least half a dozen participants are making arguments clearly rooted in the wording at WP:DAB that some are trying to delete, consensus and process notwithstanding.]
        • The numbers are in favor of retention, though not by landslide, to the extent that is seen as meaningful.
        • The RfC itself is misleadingly and non-neutrally worded (in favor of deletion); the contravenes WP:RFC and requires a closer to account for the bias (or to close the RfC as invalid on its face).
        • Supporters have provided source, policy, and RM precedent backing, while deleters have not. Various opposers to inclusion in the guideline have actually wanted to move it into AT policy (going all the way back to its original inclusion in WP:DAB), but this proposal was already rejected at WT:AT. Re-proposing failed ideas when nothing has changed is a waste of time. And one does not get to delete guideline material by proposing an implausible move-and-merge to policy that is sure to be rejected, then claim that this somehow has something to do with whether it can be deleted from the guideline. By that rationale any guideline could be nuked by proposing a such a doomed move and claiming that the material suddenly had no consensus of any kind.
        • WP:NOT#BUREAUCRACY, WP:EDITING and WP:CONSENSUS are policy (it does not require some local-consensus's permission to codify actual practice in guidelines; this is what guidelines are for, and no one owns them).
        • Finally, the arguments presented here are far stronger for retention than for removal. The latter are primarily predicated on WP:IDONTLIKEIT, factual errors about RM outcomes, confusion about what disambiguation means, and an insistence, with no basis, that the WP:DAB page cannot possibly be about anything but article title collisions even if the word itself has broader meaning.
In short, there really is no case for removal. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 16:42, 17 May 2016 (UTC) [updated 18:19, 17 May 2016 (UTC)]
  • So, my first request for closure was more than a month ago...doesn't that seem a bit beyond the pale? Would someone close this thing out, please? RGloucester — ☎ 17:52, 26 May 20(UTC)
RGloucheser, there is nothing to "close". The thread was never actually marked as an RFC, even though people started to !vote as if it was. Just stop responding, and the thread will be moved into the archives like any other old discussion. Blueboar (talk) 18:06, 26 May 2016 (UTC)
Yes, it was an RfC. The RfC tag is automatically removed after 30 days (i.e. ages ago), when RfCs expire and are meant to be closed. Closure is required, or else there is no resolution to the question asked by the RfC. RGloucester — ☎ 18:13, 26 May 2016 (UTC)
Sorry... my mistake. If you are willing to go with a non-admin, I would be willing to formally close. Blueboar (talk) 19:00, 26 May 2016 (UTC)
The "automatic" removal - actually a bot edit - is here, and within seconds it was removed from the RfC listings. There is a request for closure at WP:AN/RFC#Wikipedia:Village pump (policy).23Wikipedia:Disambiguation and inherently ambiguous titles, filed over a month ago. --Redrose64 (talk) 19:05, 26 May 2016 (UTC)
I don't think any WP:AT/WP:MOS regular like Blueboar should close it. Anyone who regularly works on these policypages is apt to have very strong opinions about how they "should" be, when there is nothing to analyze here but the consensus process, disconnected from what the topic is: Wording was introduced; it was discussed; it was modified by those objecting to it; they stopped objecting after modification, resulting in a consensus; it remained stable all year; someone who did not participate in any of these discussions attempted to delete the agreed-upon, stable text without new discussion or even being aware of previous discussion; multiple editors reverted that; that deletion idea has been discussed, and arguments for and against removing or retaining the wording in some form have been aired; which are stronger, from a WP:POLICY, WP:PROCESS, and WP:COMMONSENSE, especially given that the main alternative proposal is "move it into WP:AT", a proposal that was already rejected in the first discussion? The answer is pretty clear, so even if we don't get a formal closure, consensus to keep the wording has not actually changed.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:52, 29 May 2016 (UTC)

Just FYI, it's not at all unusual for a discussion like this to languish without a formal closing statement for months. I suspect that having nearly all RFCs bulk-listed at WP:ANRFC by one editor causes the limited volunteer attention to be spent where it's not truly needed, at the expense of longer and more complex discussions.

Looking at who's been active recently at ANRFC, if you want an admin to close this, then you probably need to hope that User:Bencherlite, User:Xaosflux, User:Coffee, User:BD2412 or User:EdJohnston will have time and interest in reading and summarizing 10,000+ words on this subject.

Also, there's no "rule" against requesting closure for any discussion. ANRFC is "Administrators' noticeboard/Requests for closure", not "Administrators' noticeboard/Requests for comment". It's not an RFC-specific thing. WhatamIdoing (talk) 19:06, 17 June 2016 (UTC)

Yep. Lots of non-RfCs get listed and acted upon there. "Requests for comment" is only one subsection of "Requests for closure" (though often the only populated one, and people tend to list RfC-like not-quite-RfCs there; it's up to ANRFC admins if they want to reorganize it, and apparently they WP:DGAF per WP:BURO. :-)  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  04:49, 30 June 2016 (UTC)

RfC: Clarification of BIO1E[edit]

In the second paragraph at WP:BIO1E, the assassination that led to the start of World War I is given as an example (and the only example) of a "highly significant" event. To me, this suggests that the appropriate bar is whether the event is covered in, or can reasonably expected to be covered in, history books. Others prefer a lower bar, especially for more recent events, that requires only extensive RS coverage and a subjective assessment of the event's impact—an assessment which often takes a short-term view. They would include events that very likely will not be covered in history books. Should the guideline be modified to clarify this point? If so, how? ―Mandruss ☎ 19:07, 2 June 2016 (UTC)

No response after one week at Wikipedia talk:Notability (people).

The sentence in question first gives the example of the assassination of Archduke Franz Ferdinand as an example. This was an event with very high historical impact and is widely covered in history books. The sentence then refers to "the large coverage of the event in reliable sources". This would include many events that receive extensive news coverage but have far less historical impact, if any. This is contradictory, creating more confusion than clarity.

Options:

  • 1 - Clarify the guideline. Remove the Princip example, replacing that entire sentence with: "The event should have received large coverage in reliable sources that devote significant attention to the individual's role."
  • 2 - Clarify the guideline. Add language following the Princip sentence: "Historical significance sufficient for inclusion of the event in history books is not required; extensive coverage in reliable news sources may be enough."
  • 3 - Clarify the guideline. Add language following the Princip sentence: "Generally, the bar should be historical significance sufficient for inclusion of the event in history books, either demonstrated or reasonably anticipated."
  • 4 - No change to the guideline. Simply affirm that: "Generally, the bar is historical significance sufficient for inclusion in history books, either demonstrated or reasonably anticipated." This RfC will then be used to show community consensus, supplementing BIO1E.
  • 5 - Do nothing, the status quo is adequate.
  • [other] - Roll your own. ―Mandruss ☎ 19:07, 2 June 2016 (UTC)

RfC survey: BIO1E[edit]

  • 3 or 4 as proposer. I feel that (1) the guidance is inadequate as written, and that (2) the criterion should be historical significance, not simply RS coverage of any kind. ―Mandruss ☎ 19:07, 2 June 2016 (UTC)
  • I support option 2. Something that occurred reasonably recently, no matter how notable the event was, is unlikely to turn up in any history book. If an event has been covered extensively by reliable sources, then I don't see why it matters that it hasn't been covered in history books. Omni Flames (talk) 05:04, 19 June 2016 (UTC)
  • I lean towards 4. As it currently stands we see plenty of articles being created with dubious historical significance (e.g. this person came in second in the 2005 American Idol, has never been heard from since; or had a minor role in a soap opera, which nevertheless did something consequential to the plot and got coverage for it, but then had no other significant coverage or played any notable roles). This needs to be corrected and made clearer. What we need to define is a way to establish "demonstrated or reasonably anticipated" - how would you ascertain if an event will be historical and covered in reliable long-term sources, such as books? "History books" should not be taken in the literal sense - I believe this refers to any long-term coverage in the relevant media for that particular subject. Best, FoCuS contribs; talk to me! 16:42, 26 June 2016 (UTC)
  • Simply add a non-history-book example, which effectuates the idea of Option 2 without having to change the guidance wording.. Extensive RS coverage, regardless of the publication medium, is sufficient. The idea we can predict what will be in future history books is WP:CRYSTAL. Focusing on "history books" in particular is "medium/genre fetishization" and should be avoided, per the avoidance of it at WP:V and WP:RS themselves and at WP:NOT#PAPER.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  04:46, 30 June 2016 (UTC)

RfC discussion: BIO1E[edit]

  • What you seem to be asking for is some kind of "super notability", based on what a particular subset of reliable sources have written about (or upon our own subjective opinion of what a particular subset of reliable sources might be writing about at some undetermined point in the future), rather than what we know reliable sources generally have written about. I don't see the merit, nor have I seen any indication that it is established practice so as to justify changing the guideline's description of what practice is. I think you're just reading too much into an example that was probably included for its obviousness rather than it setting the bar that all others must pass. We also already have WP:NOTNEWS, which I think is on point with your concern. postdlf (talk) 19:51, 2 June 2016 (UTC)
The guideline confuses me as written. Unless I'm unusually, almost singularly stupid, which is not outside the realm of possibility, it will confuse others as well. My primary goal here is to eliminate avoidable confusion and the resulting wasted time in discussions. Thus I would ask you to !vote 1, 2, or 1 or 2. If you can't see fit to do that, I included 5 just for you. ―Mandruss ☎ 19:58, 2 June 2016 (UTC)
  • Endorse Postdlf's points that this example is chosen for its sheer obviousness, also about 'NOTNEWS'. Real problem is the difficulty in establishing what IS going to be long-term significant. Would a better clarifier be the purely practical one that until the volume of available material requires a seperate article, default should be to not create one? Trouble is too many editors see a seperate article as an endorsement of the individual's significance, rather than the most efficient way to present information IM(H?)O. Pincrete (talk) 14:58, 3 June 2016 (UTC)
  • I think there's a bit of a WP:NOTCRYSTAL issue if we start predicting what will be in history books and how it will be covered. Who knows what society will consider important in 100 years? I'd rather keep the example in there, but have an additional sentence to the effect of: "The event should have received extensive and enduring coverage in reliable sources that devote significant attention to the individual's role." In other words, it can't be minor coverage (obviously) and it can't be brief coverage (two days in the limelight and then complete silence is exactly what WP:BLP1E is meant to keep out of the encyclopedia). ~ RobTalk 14:44, 7 June 2016 (UTC)
    • That sounds remarkably like option 5. For some reason no one wants to !vote in this RfC, so I'm prepared to let this archive for lack of participation and just continue to live with the ongoing consequences of this lack of clarity.
      The ability to step outside oneself and put oneself in others' shoes is very rare in such decision making. "It's clear to me, with my years of experience, so there is no need for further clarification." Ok then. Wikipedia continues to be designed by the experienced, for the experienced, and the less experienced can just struggle on—or not. ―Mandruss ☎ 02:37, 8 June 2016 (UTC)
      • No, I'm more-or-less voting for both an example and clarification away from the use of "future inclusion in history books", which is not currently an option. The wording of 2 prevents me from supporting it. The clarification there is worded in such a way that it still enshrines "future inclusion in history books" as the gold standard (with occasional exceptions for extraordinary sourcing). ~ RobTalk 04:39, 15 June 2016 (UTC)
    • Mandruss, I congratulate you on receiving thoughtful comments, rather than simplistic votes, in response to your Request for Comments. Most people starting an RFC would consider themselves lucky. WhatamIdoing (talk) 19:54, 17 June 2016 (UTC)
      @WhatamIdoing: The same comments can't be part of a !vote? Ok, I wasn't aware of that, and it hasn't been my experience. And I wasn't aware it was a binary choice, anyway. But thanks all, for the thoughtfulness, and I always consider myself lucky just to be allowed to work at a wonderful place like Wikipedia! ―Mandruss ☎ 01:08, 19 June 2016 (UTC)
  • I do not find the guideline confusing and do not think I found it confusing when I first read it. I concede that others may find it confusing and so I support the addition of the clarifying sentence suggested by Rob. I certainly do not think that we should be in the business of predicting how much coverage unpublished hypothetical future history books may or may not devote to a topic. Cullen328 Let's discuss it 04:41, 17 June 2016 (UTC)
  • I think this is a difficult area for less experienced editors, especially when they are interested and excited about writing about a recent event. IMO the biggest focus should be on "enduring" coverage, with a specification that editors should have a reasonable expectation of coverage extending significantly beyond the first anniversary of the end of the event. (For example, almost every murder or kidnapping will get a namecheck in a local newspaper on the one-year anniversary, and that's not enough.) This is not so much "future inclusion in history books" as "future inclusion in any reliable sources", which has some CRYSTAL challenges, but it is far easier to predict one year than one century, the 'deadline' has already passed for many events, and it's easy to clean up next year if we guess wrong.
    Also, expanding the requirement to require coverage in non-local sources would probably help. It's easy to find year-long coverage in local newspapers of (for example) individual children with cancer or the mayor's arrest for drunk driving, but that's not really notability. WhatamIdoing (talk) 19:54, 17 June 2016 (UTC)

WP:DATERANGE ambiguity and stylistic concerns[edit]

I recently initiated a discussion regarding WP:DATERANGE, the MoS guideline that specifies use of two-digit abbreviated years in end-ranges (i.e. 1995–99 instead of 1995–1999) for years from the 11th century onward only. Objections have been raised regarding this guideline before, and now again, with many agreeing with my reasoning for reverting to the old format, but it never proceeds any further. Here are several reasons why the current guideline should be abandoned and reverted:

  • Date ranges under the current format can easily be confused for something else entirely, especially for ranges ending in years '01–'12. For example, "2010–12" can easily be interpreted as December 2010 instead of a date range of 2010–2012.
  • It looks very unprofessional IMHO. Saving a measly two digits is not worth giving the appearance of using unnecessary shortcuts/slang in a respectable encyclopedia.
  • It doesn't read naturally for years in the 21st century spanning the 2000s decade to 2010 or later. This is mainly because years from 2000–2009 are usually pronounced "two thousand and", while years from 2010—present are usually said as "twenty". So a range such as 2000–16 being read as "two thousand to sixteen" sounds ridiculous. This is especially problematic for anyone having Wikipedia read aloud by a text-to-speech program.
  • Implementation is inconsistent, since it is only applicable to years 1000 AD+ and to none of the years in the BC era (why not?), leading to more confusion and unnecessary stylistic asymmetry.

I am looking to canvass the wider community to see if there is support to revert to the older style, which preferred permitted the entire 4-digit year for end-ranges. Please indicate whether you support the current MoS guideline or the previous one. — Crumpled Fire • contribs • 00:43, 18 June 2016 (UTC)

Question: You say the old format, but I've just been looking through the history to find when the format changed, and got tired around October 1, 2007‎ when it was still stating a XXXX–XX format as it does today. How long ago was the change from XXXX–XXXX, and why did it change? Fred Gandt · talk · contribs 01:41, 18 June 2016 (UTC)
In 2007, it also said "The full closing year is acceptable, but abbreviating it to a single digit (1881–6) or three digits (1881–886) is not", and this no longer seems to be accepted, except for birth and death dates. It once also specified that date ranges from the first millenium used all the digits (886–889, not 886–89). WhatamIdoing (talk) 05:52, 18 June 2016 (UTC)
As of February 10, 2012, our own manual of style is cited in this stackexchange question as a "guide" to how to format date ranges - so that's helpful. Fred Gandt · talk · contribs 07:25, 18 June 2016 (UTC)
Sorry for the confusion, but what I had meant by the "old" style was the permissing of the full closing year (4 digits), which is now removed from the guide. This removal is what has resulted in the change of 4-digit end-years to 2-digits across thousands of articles over the years, and for any 4-digit closing years in new articles/edits to be changed by someone with a comment citing the MoS. I'd prefer the abbreviated form be discouraged altogether, but as long as the 4-digit form is once again permitted as equally legitimate, that would be sufficient. — Crumpled Fire • contribs • 14:56, 18 June 2016 (UTC)
Ah, cool. Cheers. Fred Gandt · talk · contribs 03:00, 19 June 2016 (UTC)
@Crumpled Fire: I suggest this be converted to a "formal" WP:RfC, so that whatever its results are carry more "weight"... --IJBall (contribs • talk) 19:46, 27 June 2016 (UTC)
Good idea. I've done so here, you and others watching this discussion are welcome to join. — Crumpled Fire • contribs • 08:29, 29 June 2016 (UTC)
Per WP:MULTI and common simplicity and ease, I suggest the RfC should be held right here. Fred Gandt · talk · contribs 12:17, 29 June 2016 (UTC)
Done. Moved to below. — Crumpled Fire • contribs • 13:13, 29 June 2016 (UTC)
If you don't mind, I've refactored the RfC tag to the top, or it will lead to an accidental fork of the "!voting" (a term some object to) into two redundant sections, as people click links to the RfC and end up below it. I almost did this myself until realizing that the comments were in a section above the RfC tag. — Preceding unsigned comment added by SMcCandlish (talk • contribs) 03:54, 30 June 2016 (UTC)
Not a problem, I was considering doing something similar myself, thanks for the help. — Crumpled Fire • contribs • 05:05, 30 June 2016 (UTC)

Comments on DATERANGE RfC[edit]

  • Revert to previous style (permit and prefer 4-digit years), per points above. — Crumpled Fire • contribs • 00:43, 18 June 2016 (UTC)
  • I'm in favor of permitting the "full closing year", without requiring it. "In 2006–07, the sports person did something" is appropriate to the subject, even though I prefer "2006–2007" (or even "from 2006 to 2007", spelled out with actual words) for other contexts. WhatamIdoing (talk) 05:52, 18 June 2016 (UTC)
    FYI, in case you were unaware, this policy isn't just referring to adjacent years, it's any years within an entire century. In otherwords, "1957–98" is preferred over "1957–1998", which is IMO ridiculous. If it were just "1957–58", as in the common practice used for school years/fiscal years/etc., I'd have no concerns. — Crumpled Fire • contribs • 14:50, 18 June 2016 (UTC)
  • Permit 4-digit years. I can think of no reason to have 2-digit year ranges at all, much less have them preferred. WP isn't paper, so what are we saving by removing some digits? I'm not aware of any increase in understanding by the reader for 2-digit years in ranges, and per above, several possible misunderstandings. I'm saying "permit" rather than "require" only to avoid the same rash of MOS-fanatic changes that caused this dumb situation. --A D Monroe III (talk) 15:14, 18 June 2016 (UTC)
  • Permit 4-digit years—forcing two-digit ranges is silly micromanagement, and I can see no profit from enforcing it. Curly Turkey 🍁 ¡gobble! 22:23, 18 June 2016 (UTC)
  • Prefer or require 4-digit years: I think MOS:DATERANGE permits 4-digit years: "the range's end year is usually abbreviated to two digits". Two-digit years are an anachronism from before the printing press, in the computer age a two digit year cutoff is a kind of database problem. I was taught to not be ambiguous by using 9999 for four-digit years (and 999 for three-digit years, etc.). –BoBoMisiu (talk) 00:59, 19 June 2016 (UTC)
  • Require full syntax: I was considering this from the standpoint of standards, with the weight being on simple continuity i.e. One rule to rule them all. With this in mind I considered a range like "1874 to 1984" which would currently read as "1874–984" if we apply the same logic to the formatting as "1874 to 1884" being written as "1874–84". This is nonsensical, so we need several formatting rules to cover different ranges, which leads to confusion and argument. A one rule solution is to always use the full syntax e.g. "1874–1984", "1874–1884", "874–984", "874–1984" etc.. There can, under this simple single rule, be no confusion or ambiguity. Fred Gandt · talk · contribs 03:00, 19 June 2016 (UTC)
  • Previous style (full four digit year required) - We should not be using a potentially ambiguous two digit shorthand.- MrX 03:27, 19 June 2016 (UTC)
  • Permit both styles, prefer four digit – I wouldn't want to prohibit "1957–58" for school years or sports seasons. It would be nice to come up with a set of simple rules but there are so many exceptions and edge cases I think we need to leave it partly up to editor discretion. Kendall-K1 (talk) 12:40, 19 June 2016 (UTC)
  • Require all digits to avoid confusion and ambiguity; saving two characters (especially in a digital context) is unnecessary. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 13:12, 19 June 2016 (UTC)
  • Leave guideline as it is. This reflects normal English-language usage. Jc3s5h (talk) 13:23, 19 June 2016 (UTC)
    No it doesn't. Two-digit abbreviations for end-ranges consisting of a period of decades or longer (i.e. 1909–98) are virtually non-existent. The only use of this abbreviated format that I've ever seen commonly is for immediately adjacent years, as in fiscal or school years (i.e. 2008–09), as noted above. — Crumpled Fire • contribs • 13:40, 19 June 2016 (UTC)
  • Require all digits: A consistent style for all dates is far more compatible with automated tools, screen readers for the visually impaired, search engines, etc. --Guy Macon (talk) 16:44, 19 June 2016 (UTC)
  • Permit 4-digit years, prefer this as default, but leave 4 vs 2 editorial decisions to a case by case scenario. — xaosflux Talk 16:48, 19 June 2016 (UTC)
  • Permit both styles, prefer four digit per the rapidly accumulating SNOW above. Specifying always four digits is tempting, but two digits is extremely common for consecutive years and other edge cases. Alsee (talk) 10:03, 20 June 2016 (UTC)
  • Require all digits except for school years or sports seasons and the like Peter coxhead (talk) 11:29, 20 June 2016 (UTC)
  • Prefer full years – I've had to correct my own edits to the two digit style more than once, and each time I always wondered why I was having to do that. Even if the two digit style is acceptable, the four digit style is more universal. I can't think of any reason in the context of Wikipedia to prefer the two digit style. Expressing a preference is what the MoS does, by the way. There is no matter of "requirement" in it. Editorial consensus on a talk page should still be able to determine specific instances where the two digit style might have usefulness. RGloucester — ☎ 16:41, 20 June 2016 (UTC)
  • Comment – In this decision, either leave the current default 2010–12 or require the 4-year 2010–2012 format. But whatever you do, don't leave it as a "dealer's choice". IOW, either leave the current, or go to the full 4 year, but don't leave both formats as "acceptable". This should be a binary choice: either choose the current, or choose the former. Leaving as a "dealer's choice" will lead to chaos and edit warring... (On my end, I've gotten very used to the current format, but the "all-4 year" format would probably be "cleaner" across the whole project...) --IJBall (contribs • talk) 16:45, 20 June 2016 (UTC)
  • Require four-digit years per Fred Gandt, IJBall, Guy Macon above. For simplicity, clarity, lack of ambiguity, and for tools that automatically extract meaning from wp. Regards, James (talk/contribs) 17:31, 20 June 2016 (UTC)
  • Permit both styles... I wouldn't mind requiring "4-digit" for prose, but when it comes to usage in tables, I usually much prefer "1998–99" because it makes the column nice and narrow and there's not all the repeating of 19s or 20s down the column. But then, there are times when "4-digit" is the better choice in tables as well. —Musdan77 (talk) 17:39, 20 June 2016 (UTC)
  • Permit both styles, preference to two-digit except where ambiguous per nom. Examples: 1965–68; 2010–2011. 🖖ATS / Talk 00:29, 21 June 2016 (UTC)
  • Require all digits, except for school years, sports seasons, and potentially tables if not ambiguous and the like, for the good rationales given. FeatherPluma (talk) 01:00, 21 June 2016 (UTC)
  • Permit both styles, preference for two-digit except where ambiguous I find 2 digit simpler to read, and people employ 'translations' when verbalising the written form, sometimes using the longest, sometimes the shortest form. Pincrete (talk) 11:07, 21 June 2016 (UTC)
  • Question How does a screen reader read 2000-12 compared to 2000-2012? Only in death does duty end (talk) 11:45, 21 June 2016 (UTC)
    • Just to clarify, depending on the answer to the question, my vote will be either ****-**** only or 'both allowed'. As an accessibility issue, if screen readers have issues (which I have seen on other websites, but personally have not experienced on wikipedia) with the ****-** format, generally it should be discouraged. If there is no issue, I dont see any reason it shouldnt. Only in death does duty end (talk) 13:03, 21 June 2016 (UTC)
    • Paging User:Graham87...
      On a related note, I understand that the hyphen (or en dash) between the years is silently dropped. It's possible that spelling it out the connection in words, as in "2000 to 2012" or "between 2000 and 2012", would be best for users of screen readers. WhatamIdoing (talk) 03:35, 26 June 2016 (UTC)
      • By default, JAWS reads 2000–2012 as "2000 dash 2012" and 2000–12 as "2000 dash 12". NonVisual Desktop Access omits the hyphen when it is present, but when an en dash is there, it reads "2000 en dash 2012" and "2000 en dash 12", respectively. I don't think we should let screen readers determine the guidance here; both forms are exceedingly common, and using "to" and "between" would just not work in many places. Graham87 06:59, 26 June 2016 (UTC)
        • Just to clarify: It would say 'two thousand (en)dash two thousand twelve' versus 'two thousand (en)dash twelve'? I understand punctuation is a mess, I am more familiar with braile readers ;) but to me I think the former would be preferable to the latter. Only in death does duty end (talk) 08:48, 29 June 2016 (UTC)
    • According to this blog who tested 3 screen readers - punctuation is a mess (scroll down to the table of dashes). Of note, not all screen readers will behave the same. — xaosflux Talk 03:50, 26 June 2016 (UTC)
  • Comment: per Only in death's concern (above); I think it worth considering that if the abbreviated form is allowed, it should only be so when wrapped in <abbr>...</abbr> tags to assist human and machine comprehension. Fred Gandt · talk · contribs 12:15, 21 June 2016 (UTC)
  • Define full ending year as the default house style, with local exceptions based on discussion of real need (this last part is implicit in the word "guideline" and does not need to be stated). As with any guideline, it would not be useful to say both are permissible and leave it to personal preference; that would be a guideline largely devoid of guidance, and would enable more time-wasting conflict than it prevented. ―Mandruss ☎ 03:52, 26 June 2016 (UTC)
  • Require all digits because saving 2 digits is not a huge benefit, having multiple permissible styles gives an unprofessional look, yyyy-yy seems to be more of a US thing that is less commonly used by other countries, yyyy-yy can be confused with yyyy-mm dates, avoids editors toggling between the two formats and one universal rule is so much easier than multiple rules trying to pin down exactly when 2 digits are/aren't allowed.  Stepho  talk  01:01, 30 June 2016 (UTC)
  • Permit both styles. Retrograde step to insist on all eight digits in all situations, removing the flexibility we currently have. Even in infoboxes and tables? Nuts. Tony (talk) 01:43, 30 June 2016 (UTC)
Although I find the two digit style unnecessary, aesthetically ugly, potentially ambiguous, and arbitrary (Why not abbreviate to 1 or 3 digits? Why not for years before 1000? Why omit the grammatically correct apostrophe preceding the two digits?), I would be willing to support a guideline identical to that currently found at MOS:DATEVAR, which allows the abbreviation of month names "only when brevity is helpful (refs, tables, infoboxes, etc.)". Which is not to say that two digits should always be used in tables and infoboxes, but rather only when a cluttering amount of (three or more) date ranges are present. — Crumpled Fire • contribs • 02:18, 30 June 2016 (UTC)
  • Require full "2001–2012" syntax. This matches our treatment of page numbering ("pp. 2001–2012", except possibly in some citation styles imported from off-WP that forbid it, but this seems so rare it need not be accounted for, and I've never once had someone revert me correcting to the longer, clearer format). It also comports with our treatment of other similar ranges of numbers ("sources reported between 2,001 and 2012 fatalities", not "sources reported 2,001–12 fatalities", which to many will imply some kind of subtraction operation).

    Permit an exception for tables, if and only if all of the following apply: a) horizontal space in the table is genuinely at a premium, b) line-breaking with "2001–<br />2012" would be disruptive to the table layout or sortability, c) the shortened date is wrapped in <abbr>...</abbr> (or the {{abbr}} template for it), and (not "or") d) the table also includes some shorthand dates like "1996–00" and "2012–15" that cannot be mistaken for yyyy–mm dates (i.e., do not end in "-01" through "-12"). A large table broken up into several smaller ones with the same columns, in the same article, would be considered a single table for this purpose.

    No special exemption for sports or any other particular topic, whether they use dash- or slash-delimited formatting by convention. Wikiprojects do not get to PoV-fork their own little local micro-consensus against site-wide norms, as a matter of policy. WP is an encyclopedia; it is not sports journalism or mimicry of it. WP permits some specialized stylization when it does not conflict with general-audience expectations and comprehensibility needs, but rejects it when it does. And no special pleading for "I got here first" editors. We already have way, way too much WP:OWN/WP:VESTED-violating "get off my article!" behavior, over micromanagement of formatting nit-picks. This has to be put to an end, not expanded even further.

    While if one were writing an informal blog or a company memo, one might not care what date format was used, and not really care all that much if a few people had some difficulty with it, on Wikipedia the fact that alternative styles can be attested to exist does not mean that every imaginable paper-medium style must be permitted, willy-nilly; we have a mission and responsibility to be as accessible to and clearly informative for as many readers as possible. Most of WP:MOS and its subpages consist of best practices selected from a range of possible practices, and selected (especially in favor of clarity over ambiguity, even at the cost of a tiny bit of brevity) by consensus on the basis of experience with what does and does not work well on WP, what leads to continual strife when no firm rule is provided, what WP:COMMONSENSE suggests, and what the preponderance of external style guides recommend. On all four counts, we are pointed toward using the full "2001–2012", not shorthand "2001–12", format. The shorthand style is primarily used in journalism, where space is often taken to matter more than clarity, and inside academic citation formats in particular fields, particularly those also geared toward maximum compression, for reduced journal printing cost and for expert convenience, at the expense of "lay" readability (e.g. "Jacksom PM, Garcia AG. AmJPsych", versus the "Jackson, P. M.; Garcia, A. G. American Journal of Psychology" we expect here).
     — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  03:48, 30 June 2016 (UTC)

Extended discussion of DATERANGE RfC[edit]

A short discussion was initially had at the MoS/Dates and numbers talk page (the latest of many which went nowhere) regarding the re-introduction of the four-digit endrange year in WP:DATERANGE. When some support was garnered but discussion again stalled, it was then expanded to a discussion and !vote here at the Village Pump, garnering a high level of agree !votes to return to the original style of allowing—or even preferring—four-digit end years (i.e. 2000–2016) instead of the current two-digit end years (i.e. 2000–16) for ranges that occur post-11th century and within the same century.

In addition to the points made and support garnered at the Village Pump, it's becoming clear to me that the general editing public (and likely the general public itself) finds the 2000–16 format disagreeable, as I've already had to revert three instances ([27],[28],[29]) within the last few days of someone changing "2000–16" to "2000–2016" in the infobox for Anton Yelchin (a high-traffic article due to the subject's recent death). As suggested by a user at the Village Pump discussion, I am opening an RfC to hopefully determine once and for all whether the community at large agrees it's time to re-introduce four-digit end years in ranges. — Crumpled Fire • contribs • 13:12, 29 June 2016 (UTC)

Possible outcomes[edit]

Keep in mind that this policy applies to years 1000–present only, and only to ranges that stay within the same century.

  • A) Status quo (prefer 2-digit, no explicit allowance of 4-digit)
  • B) Only allow 4-digit end-range years
  • C) Only allow 2-digit end-range years
  • D) Equally allow both, using whichever is established/the first editor used, and discuss prior to change (similar to CE/AD policy)
  • E) Prefer one, but allow the other in certain circumstances (specify details in your comment)

As the proposer, the outcome I support is B, as I see no benefit to reducing 4-digit years to 2 digits arbitrarily in any case, ranges or otherwise, as argued previously. — Crumpled Fire • contribs • 14:26, 29 June 2016 (UTC)

The slowness of Wikipedia:Move review[edit]

This process is now becoming less managed and less visited. Also, I wonder whether the MRV serves its purpose anymore. If it does, how do we improve it? If not, what can we do with it? --George Ho (talk) 06:12, 20 June 2016 (UTC)

Most of the discussion result in endorsed, so perhaps it is getting pointless if moves/nonmoves are never overturned. Graeme Bartlett (talk) 11:50, 20 June 2016 (UTC)
There have been seven MRVs in the last three months. Two of them have been overturned and it looks like one of the currently open ones will also be overturned. That's a pretty significant percentage, especially when you consider that you would expect most to end as endorse (look at DRV for example, of the recent discussions currently listed we have four endorses and a no consensus that defaulted to endorse with no overturns). The problem I think is that there is just too little participation at MRV, so although we generally get to the right decisions it takes longer than is useful. My ideal solution would be to merge it with DRV (and also add in any reviews of RfC closes) because they all involve reviewing a closer's decision to see if they accurately judged the consensus of the discussion. I'm not sure how that would fly with the DRV regulars though. Jenks24 (talk) 12:40, 20 June 2016 (UTC)
Shall we invite DRV regulars in? George Ho (talk) 19:00, 20 June 2016 (UTC)
It was discussed and rejected at Wikipedia talk:Deletion review/Archives/2012/April. That was a while ago, but I don't think the outcome would be any different. —Cryptic 15:58, 24 June 2016 (UTC)
  • I didn't even take my objections to several moves to this because of too few people working it (although the New York one seems populated, is it worth it to bring the move here?). So may I ask (I've asked elsewhere with only crickets for company), how long does it have to be before a new RM can be put up, especially with new 'evidence' to present? Thanks. Randy Kryn 16:09, 24 June 2016 (UTC)

Notice about potential overhaul to MOS:TV[edit]

Moved to Wikipedia talk:Manual of Style/Television#MOS:TV "overhaul" planned?

This is just a notice that members of the Television project are considering overhauling and rewriting our MOS, headed up by myself. Nothing is happening until August 2016, but there is a discussion regarding interest in the endeavor which you can find here, and add your signature if you would like to be a part of the effort. - Favre1fan93 (talk) 01:14, 23 June 2016 (UTC)

Thanks for the heads-up, but please note that MOS:TV is a Wikipedia guideline, not an owned page, a wikiproject advice essay, of WikiProject Television, so it's not appropriate to call it "[y]our MOS". It's part of the MoS. What it says affects a large number of articles that are not entirely within the scope of WikiProject Television, and it's important that it not start PoV-forking away from things like MOS:NUM, etc..  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  04:21, 30 June 2016 (UTC)

Deprod by nominator[edit]

If someone nominates an article for PROD, and then shortly deprods it without any edits in between or significant contributions afterwards, does that still make it ineligible for PROD? I just nominated the article in question for AfD anyway, but I'm curious about this. nyuszika7h (talk) 14:15, 24 June 2016 (UTC)

I wouldn't think that would count. The issue is whether there were any objections to the PROD, and if the PRODer basically says "never mind" and removes it themselves that doesn't count as an objection in my mind, it's instead as if it were never prodded. postdlf (talk) 14:22, 24 June 2016 (UTC)
This kind of situation was discussed at Wikipedia talk:Proposed deletion/Archive 12#Different situation. -- GB fan 14:46, 24 June 2016 (UTC)
I now agree with the end of that discussion. If the prod is removed by the editor that placed it, that is not a contested PROD. -- GB fan 14:53, 24 June 2016 (UTC)
Yeah, that's in keeping with other interpretations. E.g., I can still {{db-author}} a page that I created by mistake, even if someone edited then self-reverted their edit from. Etc. An accidental and self-reverted prod isn't substantive.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  04:18, 30 June 2016 (UTC)

Review of RfC implementation requested[edit]

We recently had an RfC (Wikipedia:Village pump (policy)/Archive 126#RfC: Religion in biographical infoboxes) which I am in the process of attempting to implement. As we all expected, there are a lot of strong feelings on both sides. The latest dispute is at Talk:Donald Trump#Presbyterian in infobox.

What I would really like is some feedback from other editors with a good grasp of policies and without strong feelings about US politics to review my comments on that talk page and let me know on my talk page if you think I am misinterpreting or misapplying any policies/guidelines. I want to get this right. --Guy Macon (talk) 05:58, 27 June 2016 (UTC)

Drafts in draftspace versus WikiProject subpages[edit]

There's been a series of moves and requested moves about various drafts inside WikiProject open at the moment. I was moving a bunch by hand to draftspace but this was opposed and so we had these discussions:

I can't finding any particular policy for when these should (if they should) be moved from their locations as subpages within WikiProjects or in draftspace but I'd like to put a notice here so that we can have some more outside views for the following discussions, even if it is reversing all the pages moves or keeping them where they are. -- Ricky81682 (talk) 07:09, 27 June 2016 (UTC)

  • WikiProjects own nothing. If they are interested in those pages they can add a banner tag to the talk page, just as any other project can do. --Izno (talk) 11:21, 27 June 2016 (UTC)
    • Izno Based on this revert including other project is not considered acceptable. Either way, there's a lot of discussions and inconsistency about them so I don't know if an RFC is needed or we just go hap-hazardly. -- Ricky81682 (talk) 21:03, 27 June 2016 (UTC)

Use of USPS stamp images[edit]

A inquiry to the US Postal Service “Integration and Planing Rights and Permissions” division on 9/8/15, case ID 124603003, reported that no prior approval is necessary for use of stamp images in "newspapers, news magazines, news journals and other media,” which I take to mean online encyclopedias, as the inquiry specifically referred to use of USPS stamp images on Wikipedia. However users "must credit the USPS and noting its rights, such as “United States Postal Service. All rights reserved.” and “all aforementioned uses must consist of the unaltered, original image...” — that can be obtained by a download free from the Smithsonian Institute’s Arago:people, postage and the post website, as well as USPS sites featuring the most current issues.

Why should Wikipedia policy continue to bar most USPS stamp images, when it is just a matter of reporting image information in historical context of cultural significance in a Wikipedia article and their use is permitted by the USPS? There need be no fear of Wikipedia becoming a stamp album, any more than there is need to fear WP becoming an art gallery, or a video game promotion by representing images of art or box covers. The key is writing informative encyclopedic narrative directly associated with each image. TheVirginiaHistorian (talk) 15:09, 27 June 2016 (UTC)

The USPS statement clearly does not release the stamp images under an acceptable free license (specifically that it does not allow alteration, which is a requirement we need to call images free). As such, stamps (since a specific year when the USPS was no longer a direct government agency) are copyrighted works and treated as non-free, and since WP's mission is to minimize the use of non-free, we restrict the use of such stamp images unless they meet NFCC. --MASEM (t) 15:13, 27 June 2016 (UTC)
That's not clear. How can the images of copyrighted video game boxes and album covers be allowed on Wikipedia and not stamps as a part of informative encyclopedic narrative? TheVirginiaHistorian (talk) 16:02, 27 June 2016 (UTC)
Cover art for a notable published work (one that has its own standalone article) is considered to be an acceptable use of non-free images to illustrate how that work is marketed and branded (even if that is not discussed at all in the article). If there was a stamp or stamp set that was notable on its own (eg meeting the WP:GNG for a standalone article, the same allowance would clearly be made. However, individual stamp or series of stamps are rarely notable on their own, and generally are covered on the topic that the stamp is illustrating to say that the topic was commemorated on a stamp or stamp series. And in that case, one rarely needs to see the image of the stamp to understand that context. --MASEM (t) 16:37, 27 June 2016 (UTC)
TheVirginiaHistorian, I think it depends upon where you want to use an image of the stamp. For example, I see that they have stamps with pictures of spoonbill birds and banana splits, and it's unlikely that those stamps would be appropriate for those articles. However, they also have one of the renowned teacher Jaime Escalante, and it would probably be appropriate to include the stamp alongside a well-sourced paragraph that explains that the USPS printed a stamp in honor of him. The File: page would need to be here (not at Commons) and it would need a {{subst:Stamp rationale}} template, but that is probably an acceptable use. WhatamIdoing (talk) 18:55, 27 June 2016 (UTC)
Actually, no, that would not be an acceptable use if there already existed an image of Escalante, particularly a free one. If we already know what the person looks like from other media, just using the image of the stamp to show another image and to say that a stamp was made to commemorate him would fail WP:NFCC#1 (if a free image was available) and WP:NFCC#3a (if a photograph existed otherwise). There would need to be more discussion on the specific image used on the stamp sourced in the text to made it an allowable use. --MASEM (t) 19:04, 27 June 2016 (UTC)
I was assuming that the "well-sourced paragraph that explains that the USPS printed a stamp" would actually talk about the stamp, and that the image of said stamp existed to illustrate the paragraph about the stamp, rather than the article's subject as a whole.  ;-) An unrelated snapshot of the person doesn't really tell you anything about the stamp's appearance, so NFCC complaints on grounds of "we have a different picture of this person" would not prohibit us from using a copy of the stamp to show what the stamp (NB: not the person) looks like. WhatamIdoing (talk) 05:53, 30 June 2016 (UTC)

I see the notable test. Most stamps with historical interest are initiated with joint resolutions of Congress, a majority of both House and Senate. Anti-stamp editors have previously objected that the dust jacket of a book on the New York Times best selling list, or a national marketing campaign for a video game make the respective visual representations “notable”. Surely relative to the larger context of U.S. history, a Joint Resolution of Congress commemorating a person, event or place is even more notable in comparison.

The Template:Stamp rationale is, “used for purposes of illustration in an educational article about the entity represented by the image”. It is not replaceable image, because "a free use alternative won’t exist.” Further, “there is no possible commercial disadvantage to the copyright holder.” The WP:Stamp rationale was used for the images at Puerto Rico on stamps which now is populated with placeholders since their arbitrarily removal. They were at Commons, why must they be exclusively at Wikipedia? I thought the Foundation policy was to migrate images to Commons. This seems to be a narrow parochial argument against the larger interests of the Foundation for free online access to information.

It is notable that Puerto Ricans and other U.S. citizens from U.S. territories were once excluded from U.S. commemorative stamp notice, while now politicians, poets, actors and baseball notables are commemorated as Americans, rather than an anonymous peon. WP has a project to overcome WP structural bias. Is that the proper venue for that article? Or is opposition just a general bias against stamps in Wikipedia at all, as one editor complained. It seems that the anti-stamp view is not consensus policy, as there is a Template:Stamp rationale. TheVirginiaHistorian (talk) 06:39, 28 June 2016 (UTC)

No, the act of Congress doesn't make the stamp image notable, but instead lends to the notability of the person or the topic that the act commemorates.
Also, keep in mind that the Foundation wants to encourage a encyclopedia with minimal use of non-free images, those images that cannot be reused and modified by any reuser, so that the work can be distributed freely around the world. Stamps, under the language you quoted, do not fall into that, so their use should be minimized. In an article about the general culture of Puerto Rico on stamps, it would be impossible to illustrate every stamp that has been issued to commemorate that, free or non-free, and where non-free is concerns, on such lists, only one or two representative examples would be appropriate for visual identification. It's not a bias against stamps, since stamps can be used selectively for illustration, just mass representation of stamps without any discussion of the stamp's image importance. --MASEM (t) 14:05, 28 June 2016 (UTC)

That a republic commemorates its outstanding citizens is a remarkable event in history, the expression of it in a stamp happens to be visual rather than verbal. The visual expression should be seen as equivalent to the verbal. The Foundation encourages the use of stamps by providing a Template:Stamp rationale. It does not want free images of persons, places or events modified on Wikipedia so that the personage is unrecognizable. The stamp image is stipulated as non-free in the policy approved Template:Stamp rationale for each image.

The contrast between the free-use Spanish commemoration of 1492 Columbus in 1892 and the proposed non-free use U.S. commemoration of Columbus in 1992 is instructive to the reader, but denied by Masem's misconstruing of NFCC#1, there is no image of the U.S. stamp available except that of the U.S. stamp, although is is allowed in lower resolution in NFCC#3b. In NFCC#3a, where "Multiple items are not used when one item can convey equivalent significant information" — does not apply as the visual contrast between the Spanish and U.S. stamps is not apparent without the U.S. image. There is no multiple image gallery of the same U.S. stamp in the article.

At Puerto Rico on stamps the history of U.S. postage for Puerto Rico is comprehensive, to meet the standards of a Featured Article classification by WP policy. Masem’s characterization of it being “impossible to illustrate” is simply a unreasonable denial of the work completed. Each stamp is discussed in relation to its importance as representative of Puerto Rico in compliance with NFCC#8. The charge that there is no discussion on image importance is unthinking obstruction of the intent of the Foundation. TheVirginiaHistorian (talk) 17:21, 28 June 2016 (UTC)

The Foundation did not supply Template:Stamp Rationale. That was a template created on en.wiki that does have some allowed uses but does not mean every stamp image is allowed. It simply helps to make assigning a rationale for a stamp easier by filling in some of the required NFCC information that are common to stamps. The rational and other NFCC aspects must still be valid.
Most of the items listed at Puerto Rico on stamps do not require one to see the stamp to understand the topic. You have plenty of sources to note that various people and places in PR were commemorated by putting them on stamps, and that's as far as the sources go, they do not describe anything of significance of the visual nature of the stamp. As such, one does not need to see the stamp to understand why the person or place was commemorated, nor to understand that a stamp was made for them. That said, we are reasonable in allowing one or two visual examples of non-free in such lists, recognizing many readers are visual readers, so one or two stamp images would be fine under NFCC. But not all those presently marked as "no image available". --MASEM (t) 17:35, 28 June 2016 (UTC)

Every stamp image which is supplied with a Template:Stamp rationale meets the NFCC requirements for usage by #1 and #3a, it cautions the user to the limits of the non-free image, it must be credited to USPS and “All rights reserved”, even as the entire image is used. All elements of NFCC are met at Puerto Rico on stamps for those with the place holder, “No image yet”, including #8, each stamp is "discussed in relation to its importance" as representative of U.S. stamps of Puerto Rico.

Your interest in the descriptions of the visual nature of each stamp and its production at Puerto Rico on stamps is a technical philately one, which does not directly bear on the subject matter of the article, an article that addresses the history, politics and culture of Puerto Rico as a U.S. territory on stamps. But if that is your particular interest, of course it can be admitted as your contribution to the article to expand its coverage of the topic.

The idea that “There are U.S. stamps about Puerto Rico.” would comprehensively cover the topic of reader interest without visual images of the stamps is reductio ad absurdum. At George Washington, readers want to know more than “George Washington was a Virginian” albeit in an absurd sense, that is all a reader needs to know. An article on a visual medium requires visual representations, so long as article length guidelines are not violated. TheVirginiaHistorian (talk) 10:19, 29 June 2016 (UTC)

  • "Every stamp image which is supplied with a Template:Stamp rationale meets the NFCC requirements for usage by #1 and #3a," Er, unless I am reading you wrong, you are stating that merely using the template meets the criteria for #1 and #3a - thats incorrect, you have to demonstrate use of the media meets the criteria, then the template can be used as an aide. Only in death does duty end (talk) 10:41, 29 June 2016 (UTC)
  • The template only helps towards meeting NFCC#10; #1 and #3 have to be satisified by the actual use and rational entered into the template. The subject matter is how PR has been commemorated on stamps, not the visual aspects of those stamps, so images are secondary and not necessary to understanding the topic. That is not to say no image can be used, one or two representative examples are fair, but without any further discussion of the visual aspects of the stamps (beyond a simple description), particularly with commemorated subjects that already have free images, more images are against the Foundation's goal of minimizing non-free use and our NFCC policy that supports that. --MASEM (t) 13:59, 29 June 2016 (UTC)

This discussion badly needs involvement from some US copyright experts. Just because the USPS claims rights doesn't mean it actually has them. There's a general principle that materials produced at taxpayer expenses by agencies and other bodies of the US federal, state, county, and local governments is public domain, and caselaw has even extended this to work produced for them by contractors. It's difficult to see why the US Postal Service would be some magical exception. That said, this is not a question I've pursued in any detail (i.e. with Westlaw and LexisNexis access and other shepardizing resources) since the 1990s, so something could have changed. Most of the intellectual property attorneys I know, who have looked into the overall question, are convinced that WMF is being excessively paranoid about copyright in general, and not permitting the community to avail itself of most of its fair use rights, to the detriment of projects like Wikipedia (they theory being that WMF is trying to avoid litigation it could win hands-down but which would still generate legal expenses; some of us would rather WMF fought those fights and did fundraising efforts and outreach to ACLU, EFF, etc. to back them up).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  04:16, 30 June 2016 (UTC)

It's rather simple, actually. Up to 1978, the USPS was considered a branch of the federal gov't and stamps issued by them were in the PD by the US-PDGov. However, after 1978, the USPS while still an agency of the gov't specifically had copyright laws apply that works produced by the USPS were now eligible for copyright; see United_States_Postal_Service#Stamp_copyright_and_reproduction.
And no, it's not an issue about copyright, it's about being a free content work. We know we are more restrictive than fair use but that's because we are trying to create a free content encyclopedia. Very little has to deal with how things are classified as copyright or not. --MASEM (t) 04:29, 30 June 2016 (UTC)
@SMcCandlish: Some of what you say is acknowledged by the NFCC gatekeepers, so that images of out-of-copyright art framed with a USPS border and postage value has been allowed in articles such as battles pictured at Commemoration of the American Civil War on postage stamps. The general usage of the postage places it in the public domain, but I argue additionally that the non-free use Template:Stamp rationale covers us in that it stipulates the USPS copyright, we acknowledge their "All rights reserved", and inquiry to the US Postal Service “Integration and Planing Rights and Permissions” division on 9/8/15, case ID 124603003 concerning use of USPS images on Wikipedia, reported that no prior approval is necessary for use of stamp images for educational, news and "other media". TheVirginiaHistorian (talk) 04:42, 30 June 2016 (UTC)
My point really is that, from years of doing fair-use legal work (as a policy analyst, not an attorney, but in an office full of intellectual-property specialist attorneys), it appears to me extremely dubious that any copyright claims made by the USPS are valid, and that if challenged they would be invalidated at every court level from District through SCotUS, because all the statutory and case law regarding the American governments' attempts to evade or eliminate fair use to control its own materials has ruled on the public interest's side. Unless, as I said, something recently changed radically. If it has, then an attorney steeped in that caselaw should be advising us (and WP:OFFICE) on these matters. If this has not transpired but there's a danger of it, then a) WMF should not be restraining our exercise of fair use out just out of some nebulous "what if" concerns, and b) should be working with other public interest groups like ensure that taxpayer-funded materials remain public domain. It would be an unmitigated disaster if something like crown copyright arose in the US (and other more open, public-domain jurisdictions that follow the US lead), all because various parties not only failed to speak up, but treated a non-law as if it were a law, and thereby established a de facto anti-fair-use "industry standard" that the courts or legislative bodies decided to enforce (which has definitely happened before – ever heard of sample clearances?).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  05:51, 30 June 2016 (UTC)
See the point I made above: the copyrightability of USPS stamps from 1978 is in the federal code, specifically written in by the Copyright office in response to the Postal Reorganization Act that reflects that the service become essentially an independent agency from the federal government [30]. And again, we are purposely stronger that US fair use not because of any legal issues, but because the goal is to make a free content encyclopedia. Meeting goal assures that we're always within fair use, by happenstance, but no law is requiring us to be more restrictive, it is the Foundation's mission that makes us so. --MASEM (t) 06:00, 30 June 2016 (UTC)
@Only in death: The use of a stamp for a stamp related article such as Puerto Rico on stamps when it is one of the U.S. stamps on Puerto Rico, demonstrates the use of the media (stamps) is required in the Template:Stamp rationale, “protected by copyright, therefore a free use alternative won’t exist”. That is, making the article into a literary discourse of the fine arts uniquely associated for each stamp image is not a requirement for an article on the stamps of Puerto Rico which addresses its American history, politics, economy and culture on stamps. But images of each of those stamps is a requirement to be comprehensive so as to meet the interests of a general reader.
@Masem:The use of postages stamps “to illustrate the stamp in question (as opposed to things appearing in the stamp’s design)…qualifies as fair use under United States copyright law.” The visual aspects are not required to be addressed — those are explicitly excluded. Even when they are, the stamp images are removed capriciously. In the article Puerto Rico on stamps, the image of the Julia de Burgos stamp notes that it "features the poet with blue water flowing behind her, evoking one of her best known poems, “Río Grande de Loíza,” a sensuous ode to the Puerto Rican river where she was raised.” — Yet that image was also removed.
@WhatamIdoing: All copyrighted images are removed, even though they meet the ten NFCC requirements and satisfy the Template:Stamp rationale. One or two are not allowed due to editors blanket removal when they misconstrue the NFCC criteria. An article on stamps can use stamp images. To simply assert it is “impossible” to comprehensively discuss Puerto Rico on stamps to meet the interest of a general reader ignores the editorial contribution. TheVirginiaHistorian (talk) 04:42, 30 June 2016 (UTC)
Remember that the Wikimedia Foundation and en.wiki's are purposely more restrictive than US fair use law to encourage the avoidance of non-free and the use of free content in its place, so it doesn't matter what fair use would allow, and we do not simply allow for images of things for causal illustration; there must be a reasonable purpose beyond decoration. I know you and I have discussed the de Burgos stamp before since I remember that the language about the imagery would justify it. It is true that it looks like an editor removed all the non-free without question and as they were not readded the files were deleted as orphans, but it is reasonable to readd only the de Burgos stamp image, just that you can't justify all of the others under NFC allowances. --MASEM (t) 05:50, 30 June 2016 (UTC)
The community should resist and undo this WMF angle to the extent that it can, because it's ultimately inimical to WP:ENC. One of the principal criticisms of WP as a usable work is the dearth of images. A less frequent but more serious one is our reliance on natural history images and the like from 1800s publications, many of which are grossly inaccurate.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  05:54, 30 June 2016 (UTC)
As long as they are footing the bill for the services, we're bound by their goals. You're welcome to freely fork en.wiki and make the it more amendable to fair use, but as long as we're in the WMF's sandbox, we have to abid by their rules. --MASEM (t) 06:01, 30 June 2016 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(policy)&oldid=727629546"