Wikipedia:Village pump (policy)

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

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

The policy section of the village pump is used to discuss proposed policies and guidelines and changes to existing policies and guidelines.
If you want to propose something new that is not a policy or guideline, use 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.

« Archives, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192

Wikipedia:Disambiguation and inherently ambiguous titles

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)

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)

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

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.
  • Note to closing admin: We have long established procedural policy covered under Proposals and Good practice for proposals for making changes to policies and guidelines.

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)

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

Discussion (disambiguation)

• 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 [18] but retaining the agreed short version from prior discussions [19], 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 [20]. 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) [21], 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

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)

Does IAR overule our Manual of Style?

In particular, does it overrule MOS:APPENDIX as Beyond My Ken claims here? How does obeying a MOS that the community has agreed upon "prevent you from improving or maintaining Wikipedia" (which is the requirement to invoke IAR)? --bender235 (talk) 20:16, 7 May 2016 (UTC)

Ignore all rules trumps all other policies in my view. But this goes if, and only if, it makes improvements over general practice (for example because the situation is specific to the article under discussion). In the specific case you are referring to, the change makes the matter worse as the inline references are now suddenly labelled "notes" while the further reading section (which are not references to the article but suggested further reading) is listed under references. There is no reason to assume this exception is needed for this specific article, so without a very sound and complete argument why IAR should not be used. Arnoutf (talk) 20:22, 7 May 2016 (UTC)

• Can IAR "overrule" MOS? ... Yes. Does it "overrule" MOS in every case... Nope. Should it "overrule" MOS in some specific case... probably not. Blueboar (talk) 20:32, 7 May 2016 (UTC)

Moreover, once IAR is cogently argued to support an edit against policy, if the edit is opposed then it must get consensus in order for it to stick. Since consensus is determined by the superior argument, all IAR really says is that the better argument in a consensus discussion isn't merely trumped by the argument that the opposite result is required by policy. IAR isn't a death pact which automatically overrules all other policies, even if there's a fairly decent reason for it, if the policy is supported by a better reason. Regards, TransporterMan (TALK) 21:00, 7 May 2016 (UTC)

Does IAR overule our Manual of Style? Yes, IAR is a policy while the MOS is a guideline; and, as User:Arnoutf states, it is in some sense the most powerful policy. In this specific case, was it a good invocation of IAR? Absolutely not. The point of IAR is not to let policies or guidelines get in the way of improving the encyclopedia but unless there is a real good reason not to we stick with the guidelines and policies. There seems to be no such overriding reason here. The editor has a IAR banner on their talkpage but their edit summary here, where it uses its policy status as the means to the end, suggests a deep misunderstanding regarding IAR. To throw away the manual of style so willfully is half-deserving of a {{uw-mos1}} warning. I've seen the editor around quite a bit and although I don't remember specifics, I have favorable overall impression of their edits. Hopefully this is just a momentary lapse in judgment. Jason Quinn (talk) 17:54, 8 May 2016 (UTC)

IAR allows someone to ignore a rule when it prevents them from improving or maintaining the encyclopedia. Any action taken under it still needs to be accepted by the community, it is not a magic bullet. HighInBC 17:59, 8 May 2016 (UTC)

Every instance of invoking IAR needs to be justified as being clearly in the interest of improving WP, it's not "get out of jail free" card. Roger (Dodger67) (talk) 18:13, 8 May 2016 (UTC)

One case where you know IAR is inappropriate is when, without major privacy issues being relevant, you find out that consensus is against your action. עוד מישהו Od Mishehu 03:06, 9 May 2016 (UTC)

• IAR, on its very face, trumps all rules; but, as many here have suggested, it is not a mandate to break all—or any—rules, nor an invitation to mavericks, nor an excuse for selfishness or laziness. Strunk & White's Elements of Style, if I remember right, perhaps puts it better: "Break any of these rules, if you have a good reason." In other words, IAR is never, by itself, a sufficient grounds for departure from generally-accepted rules: it is merely a proviso allowing such departure in particular instances, where a given rule stands in the way of improvement or preservation of Wikipedia.

The editing conflict cited by the OP seems to me to be a no-brainer: there are strong arguments in favor of a uniform order and format for fundamental elements of articles, particularly for appendices; and none that I can think of for variation. J. D. Crutchfield | Talk 16:40, 11 May 2016 (UTC)

Implementing the results of the infobox RfC

I am going through the entire list of all forty candidates for US President in 2016 (many now withdrawn) and trying to make sure that the religion entry in the infobox of each page meets Wikipedia's requirements as per the recent RfC on this page

Here are the requirements for listing a religion in the infobox (religion in the body of the article has different rules):

• Per Wikipedia:Village pump (policy)/Archive 126#RfC: Religion in biographical infoboxes: "the 'religion=' parameter and the associated 'denomination=' parameter should be removed from all pages that use Template:Infobox person. Inclusion is permitted in individual articles' infoboxes as a custom parameter only if directly tied to the person's notability. Inclusion is permitted in derived, more specific infoboxes that genuinely need it for all cases, such as one for religious leaders."

• Per WP:BLPCAT: "Categories regarding religious beliefs (or lack of such) should not be used unless the subject has publicly self-identified with the belief or orientation in question, and the subject's beliefs are relevant to their public life or notability, according to reliable published sources" ... "These principles apply equally to lists, navigation templates, and Infobox statements".

• Per WP:CAT/R: "Categories regarding religious beliefs or lack of such beliefs of a living person should not be used unless the subject has publicly self-identified with the belief in question (see WP:BLPCAT), either through direct speech or through actions like serving in an official clerical position for the religion."

• Per WP:LOCALCON, a local consensus on an article talk page can not override the overwhelming (75% to 25%) consensus at Template talk:Infobox#RfC: Religion in infoboxes that nonreligions cannot be listed in the religion entry of any infobox.

The forty candidates are:

Extended content

Source of list: United States presidential election, 2016 Name: Farley Anderson: No Wikipedia page, nothing to do. Name: Jeb Bush: Infobox Religion: Roman Catholicism Religion name mentioned in Body? Yes, but all links cited are dead. Discuss on article talk page. Name: Ben Carson: Infobox Religion: Seventh-day Adventist. Clearly meets all requirements for inclusion, nothing to do. Name: Darrell Castle: Infobox Religion: No religion entry in infobox, nothing to do. Name: Lincoln Chafee: Infobox Religion: Episcopalian. Religion name not mentioned in body; religion entry in infobox should be removed. Name: Darryl Cherney: Infobox Religion: No religion entry in infobox, nothing to do. Name: Chris Christie: Infobox Religion: Roman Catholicism. Religion name mentioned in body, self-identifies as Catholic.[22] Discuss on article talk page. Name: Hillary Clinton: Infobox Religion: Methodist. Religion name mentioned in body, self-identifies as Methodist.[23] Discuss on article talk page. Name: Ted Cruz: Infobox Religion: Southern Baptist. Religion name mentioned in body, self-identifies as Southern Baptist.[24] Discuss on article talk page. Name: Sedinam Curry: No Wikipedia page, nothing to do. Name: Carly Fiorina: Infobox Religion: Nondenominational Christianity. Religion name not mentioned in body; religion entry in infobox should be removed. Name: Jim Gilmore: Infobox Religion: Methodism. Religion name not mentioned in body; religion entry in infobox should be removed. Name: Lindsey Graham: Infobox Religion: Southern Baptist. Religion name mentioned in body, but citation fails direct speech requiement.[25] Discuss on article talk page. Name: James Hedges: Infobox Religion: No religion entry in infobox, nothing to do. Name: Tom Hoefling: No Infobox, nothing to do. Name: Mike Huckabee: Infobox Religion: Southern Baptist. Clearly meets all requirements for inclusion, nothing to do. Name: Bobby Jindal: Infobox Religion: Roman Catholicism. Religion name mentioned in body, self-identifies as "Evangelical Catholic."[26] Name: Gary Johnson: Infobox Religion: Lutheranism. Religion name mentioned in body, but citation is a dead link. Discuss on article talk page. Name: John Kasich: Infobox Religion: Anglicanism. Religion name mentioned in body, self-identifies as Christian[27] but citation doesn't have him specifying anglicism in direct speech. Discuss on article talk page. Name: Chris Keniston: No Wikipedia page, nothing to do. Name: William Kreml: No Wikipedia page, nothing to do. Name: Gloria La Riva: Infobox Religion: No religion entry in infobox, nothing to do. Name: Lawrence Lessig: Infobox Religion: No religion entry in infobox, nothing to do. Name: John McAfee: Infobox Religion: No religion entry in infobox, nothing to do. Name: Kent Mesplay: Infobox Religion: No religion entry in infobox, nothing to do. Name: Martin O'Malley: Infobox Religion: Roman Catholicism. Religion name mentioned in body, comes really close to self-identifying[28] but I would be more comforable if we could find a citation with unambigious direct speech. Discuss on article talk page. Name: George Pataki: Infobox Religion: Roman Catholicism. Religion name not mentioned in body; religion entry in infobox should be removed. Name: Rand Paul: Infobox Religion: Presbyterianism. Religion name not mentioned in body; religion entry in infobox should be removed. Name: Rick Perry: Infobox Religion: Nondenominational Evangelicalism. Religion name mentioned in body, but this page is a classic case of what happens when you don't follow the self-identification rule. Someone took a reference that says "Perry now attends Lake Hills Church more frequently than he attends Tarrytown, he said, in part because it's closer to his home"[29] and assigned him as being a member of Lake Hills Church based on that slim evidence. Discuss on article talk page. Name: Austin Petersen: No Wikipedia page, nothing to do. Name: Marco Rubio: Infobox Religion: Roman Catholicism. Religion name mentioned in body, but this page is a classic case of what happens when you don't follow the self-identification rule. Someone took a reference that says "Rubio... attends Catholic churches as well as a Southern Baptist megachurch."[30] and assigned him as being Roman Catholic based on that slim evidence. Discuss on article talk page. Name: Bernie Sanders: Infobox Religion: Infobox religion already decided by RfC. See Talk:Bernie Sanders/Archive 13. Name: Rick Santorum: Infobox Religion: Roman Catholicism. Religion name mentioned in body. Many citations about him being catholic, but I couldn't find a place where he self-identifioes using direct speech. Religion name mentioned in body, Name: Rod Silva (businessman) No Infobox, nothing to do. Name: Mimi Soltysik Infobox Religion: No religion entry in infobox, nothing to do. Name: Jill Stein Infobox Religion: Reform Judaism. Religion name not mentioned in body; religion entry in infobox should be removed. Name: Donald Trump Infobox Religion:Presbyterian. Infobox religion already decided by RfC. See Talk:Donald Trump/Archive 1#Donald Trump Religion Name: Scott Walker Infobox Religion: Nondenominational Evangelicalism. Religion name mentioned in body, self-identifies as "born-again Christian".[31] Discuss on article talk page. Name: Jim Webb Infobox Religion: Nondenominational Christianity. Religion name not mentioned in body; religion entry in infobox should be removed. Note: Citation in infobox fails self-identification requirement.

My goal is to determine whether Wikipedia's requirements are met for the above forty pages, and to insure that we have citations to reliable sources that meet the requirements.

Any help finding sources would be most appreciated. I have posted a query on many of the article talk pages. --Guy Macon (talk) 08:02, 9 May 2016 (UTC)

• As the closer of the RFC in question I don't think it would be appropriate for me to offer opinions on its implementation, but pinging Wehwalt as the editor with probably the most experience working with US politician articles at Wikipedia's higher end. ‑ Iridescent 20:06, 9 May 2016 (UTC)

• At Talk:Hillary Clinton there are comments that claim that your close is consistent with a position of "religion is relevant for every politician". You may wish to either confirm or correct that claim. --Guy Macon (talk) 21:37, 9 May 2016 (UTC)

• Arguably that is the case for US politicians at the higher levels. It is impossible for them to get elected without their religion being brought up and picked over by the pundits and journos. Only in death does duty end (talk) 00:02, 10 May 2016 (UTC)

• The US has never elected a president who did not profess a belief in Christianity at least to some extent. It's still relevant in American politics in a way, say, it is not in Australia, which has elected at least one atheist prime minister. Note the fascination with Obama's religion, from the Rev. Wright to today. I would say it is relevant to the office, at least until we elect a president without religious belief.--Wehwalt (talk) 01:28, 10 May 2016 (UTC)

• I don't think anyone disagrees that religion is still relevant in American politics. For that reason, there is likely to be at least some information on a candidate's religious beliefs in their article. What we're trying to determine here, however, is whether these candidates are also so notable for their religions that we should activate the reserved |Religion= field for them — just as we would for Ministers, Rabbis, Popes, Priests, Cardinals, Bishops, etc. Keep in mind that if religion is not already a significant part of Mr. Joe Politician's notability (i.e.; mentioned in the lead as a defining characteristic), it doesn't automatically become part of his notability when he declares his intent to run for US Presidency. The problem I expect the OP will run into, repeatedly, is that many editors don't realize that 'Religion' categories and fields in infoboxes are indeed reserved for people who are notable because of their religion; instead, editors wrongly believe that as long as a subject's religion is known and sourced, go right ahead and use the |Religion= field. Xenophrenic (talk) 04:30, 10 May 2016 (UTC)

• Sigh. It appears that some of the editors who are working on Hillary Clinton do not agree, and are making good-faith claims that religion is automatically a defining characteristic of every US presidential candidate. It looks like I am going to have to post Yet Another RfC because they insist that the RfC at Wikipedia:Village pump (policy)/Archive 126#RfC: Religion in biographical infoboxes (and WP:BLPCAT, and WP:CAT/R, and WP:LOCALCON...) don't apply to US presidential candidates. And then, of course, whatever the result of the new RfC is, it won't be accepted either. So, what to do? I could really use some help here. All I want is sources that show compliance with our policies, but it keeps turning into a quagmire on every individual page. --Guy Macon (talk) 13:34, 11 May 2016 (UTC)

Guy, your comments don't accurately reflect my position there, but as I'm the only one taking it I guess that's understandable. Improve the close of that RfC so that it clearly affirms a consensus on the notability point of your multi-point proposal, and I'll oppose inclusion at the Clinton article. As I said there, "This user abides by consensuses they disagree with." As for "quagmire", I looked that up in the dictionary and there was the Wikipedia logo. ―Mandruss ☎ 14:20, 11 May 2016 (UTC)

Basic Data Page (A4 or 2xA4 max)

There are many excellent pages on Wikipedia BUT as an general-knowledge user rather than being an expert in any specific area I find that many articles are so large as to be very difficult to obtain the key data.

The introductory paragraph(s) vary greatly in quality - some are perfunctory, others begin to include quite small details.

When I look at, for example, Florence Nightingale - I don't need ALL 23 pages of the detail; nor do I need all the data for many topics I have had to look at recently. And I believe the assembled expertise of Wiki can build this secondary resource very well and very effectively and to the benefit of the Wiki-world.

SUGGESTION

That major articles and articles over, say, 8 pages are allowed or expected to have a 'Basic Details' section immediately after the introduction. Perhaps an alternative would be to have a section in addition to Article and Talk.

The aim would be to EXCLUDE the references as part of the print and to have a maximum of say two pictures - albeit that one picture can equate to a 1000 words.

I have created pages for this project to see how easy it is. I am very willing to create a page on almost any topic to show that this BasicA4 version is viable and useful.

(A Third alternative would be for this to be somewhat equivalent to the Childs' Wikipedia which has many fewer articles.) JK Joking99a (talk) 09:49, 10 May 2016 (UTC)

The WP:LEAD is this, or expected to be so. --Izno (talk) 11:17, 10 May 2016 (UTC)

But LEAD doesn't supply this and isn't even often anything approximating a worthwhile summary - such as an A4 page might offer. How do I push this idea a little further? Joking99a (talk) 10:44, 12 May 2016 (UTC)

The response to "it's not often good enough" is for you to fix it, or at least tag it with {{lead too short}}. Pushing your idea is unlikely to go anywhere, and a proposal would likely be WP:SNOW-closed, because we already have a guideline which says "write a good summary in the lead", but you are always welcome to develop your idea and then propose it in a WP:RFC. --Izno (talk) 11:14, 12 May 2016 (UTC)

For me to 'fix the short or overlong or poor introductions' - I would have to be skilled at all the articles in which I have sometime only a casual interest. And there are a lot of experts in wiki-world who with encouragement would do a better job. Oh well, In the next few weeks 'll put in a few and see what happens. Or, more likely, i'll build up a set and post them in a bunch - wot u think Joking99a (talk) 18:44, 12 May 2016 (UTC)

Proposal to upgrade essay WP:BRD to official policy in edit warring issues.

A simple proposal. That BRD be upgraded to official policy. As an essay it is useful and thought - provoking. As policy I believe it would greatly increase discussion, editor retention through early and perhaps positive engagement with I.P's with potential to be useful and would lead to a steep drop in edit warring over a relatively short period of time. Just a rough initial series of thoughts here. If it gains any traction the community can discuss just how it would fit into existing policy. My initial thought is that it would replace 3RR as the bright line in edit warring issues, or that they can be used more in tandem. which the community can refine. Refusing to discuss a revert should be the trigger. It will give admins the power to nip (what are now) long drawn out and time-consuming visits to be board in the bud. Refusal to communicate is usually the major part of edit - warring. This would require communication at the earliest stage, and would weed out I.P's who are potentially WP:HERE from those who will just be a drain on the project's resources. It would also encourage more experienced registered editors with a documented reluctance to communicate to actually give their rationale for edits. Thoughts? Irondome (talk) 23:11, 10 May 2016 (UTC)

Please review Wikipedia:Village pump (policy)/Archive 120#RfC: elevation of Wikipedia:BOLD, revert, discuss cycle to guideline status, held about a year ago. --Izno (talk) 13:25, 11 May 2016 (UTC)

Izno Appreciate that. Looks to be covering similar ground. I doubt if consensus has shifted since then..Irondome (talk) 14:14, 11 May 2016 (UTC)

RfC: MOS vs COMMONNAME

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

---

Proposed:

Resolve that style elements are not essential parts of the names of things. Modify WP:COMMONNAME to state that it defers to MOS as to style elements. ―Mandruss ☎ 10:22, 11 May 2016 (UTC)

The question remains unresolved. I know this because I'm not seeing any links to an unambiguous, community-level consensus in discussions. All I'm seeing is the same arguments being made in local discussion after local discussion.

That lack of resolution is causing undue conflict and costing untold editor time.

The issue is an open wound, and the project seriously needs an unambiguous consensus here, one way or the other. This is fundamental and foundational, and that means it should be addressed and resolved first—not allowed to fester indefinitely because it is highly controversial—even if that is difficult and painful. ―Mandruss ☎ 10:22, 11 May 2016 (UTC)

RfC survey: MOS vs COMMONNAME

• Support as proposer. 1. This is consistent with the application of MOS by other entities that have MOS. 2. Style elements are not necessary for disambiguation. 3. Style elements do not change essential meaning. 4. It does not elevate MOS to policy status if a single policy explicitly defers to it. 5. The project would benefit greatly from the elimination of this vast battleground, which diverts and distracts from more important issues. ―Mandruss ☎ 10:22, 11 May 2016 (UTC)
• Oppose this or any other proposal to make MOS compliance mandatory. The MOS is a cluster of arbitrary and sometimes contradictory proclamations written by whoever happened to shout loudest at the time the section in question was written, not a "manual of style" in any meaningful sense of the word, and shouldn't be taken remotely seriously. If you want the MOS and Wikipedia's usual practices to match with regards to a particular area, change the MOS to match our practices, not the other way around. ‑ Iridescent 10:29, 11 May 2016 (UTC)

  (adding) I'm assuming that by "style elements are not essential parts of the names of things", what you're proposing is that (for instance) Wikipedia have an article on Imac rather than iMac. You may want to make that clear. ‑ Iridescent 11:14, 11 May 2016 (UTC)

  Why is this argument advanced so seriously oh-so-often? The counter-argument is trivially {{sofixit}}--if you have a serious concern that the MOS is not internally consistent, or that it does not follow best English practices (or best Wikipedian practices--not the same things), you should work to change that, not base all future arguments related to the MOS-as-a-concept on this supposed fact. --Izno (talk) 11:36, 11 May 2016 (UTC)

  Because I consider the MOS a pointless talking shop and have got through the last decade ignoring it without suffering any apparent ill effects, so I couldn't care less what the half-dozen people who take it seriously (it's always the same names there) happen to have it saying at any given time. ‑ Iridescent 12:31, 11 May 2016 (UTC)

  Basically, you're admitting your argument is irrelevant to the discussion at hand? K. --Izno (talk) 12:36, 11 May 2016 (UTC)

  You may want to make that clear. I didn't feel the need to make it clear that there would be rare legitimate exceptions to this as with anything else. This is about a default policy. And I'm frankly surprised to see an editor with your experience, Iridescent, make that argument. ―Mandruss ☎ 13:21, 11 May 2016 (UTC)

• Oppose Style very often is an essential part of a name so the premises is flawed. We should not be trying to dictate to the world how it should work, we should just be summarizing how it actually does work. Dmcq (talk) 11:58, 11 May 2016 (UTC)
• Opposed - If anything, the conflicts between COMMONNAME and MOS should be resolved in the other direction. Our MOS guidance should defer to COMMONNAME.

To my mind, the single most important sentence in MOS is contained in the nutshell - where it says: "... it is a generally accepted standard that editors should attempt to follow, though it is best treated with common sense, and occasional exceptions may apply."

The problem is that this key sentence is often ignored by our fellow editors who focus on conforming articles to MOS guidance... they think of MOS as a set "firm and fast RULES" - rules that should have no exceptions. That attitude needs to change. I strongly believe that, in situations when a significant majority of reliable sources all present a name using a particular stylization, that common stylization becomes included as part of the COMMONNAME. And if the common stylization it is contrary to what is indicated by MOS guidance... then we should make an exception to (otherwise good) MOS guidance, and follow the sources. Blueboar (talk) 12:19, 11 May 2016 (UTC)

• Oppose I'm completely with Blueboar on this one. It should be the other way round if we are going to explicitly state a preference. COMMONNAME already describes the accepted standard. If it is in conflict with the MOS, the MOS either needs to be ignored or adjusted. Only in death does duty end (talk) 12:42, 11 May 2016 (UTC)
• Oppose. MOS is for WP, only. COMMONNAME is derived from everyone else. There's no way WP can impose MOS on the outside world. I suppose there might be a few cases where the common name isn't very common, and some sources "fix" the name in ways that might conform to MOS, but those will be rare exceptions, already handled by IAR. --A D Monroe III (talk) 13:31, 11 May 2016 (UTC)
• Oppose per all. Johnbod (talk) 14:20, 11 May 2016 (UTC)
• Oppose First and foremost, decisions should be made based on the usability of the encyclopedia, hence COMMONNAME. MoS does help with usability, as a consistent(ish) style across WP can make reading easier, but it is not the priority. —  crh ₂₃  (Talk) 14:27, 11 May 2016 (UTC)
• Reject the premise – those who think that a "versus" relationship exists here are confused. Dicklyon (talk) 15:31, 11 May 2016 (UTC)

  @Dicklyon: I agree there there is confusion, but there is a "versus" relationship at the root of the discussion. I asssume we agree that capitalization is part of style and not part of a name. Then there are two ways to decide on the wording and capitalization of an article title. (1) Use WP:AT (not just COMMONNAME) to decide on the title of an article (2) apply capitalization as per the MoS. (2) Use WP:AT to decide on the title including how it should be styled, regardless of the MoS. These are genuine alternatives; the choice between them is real. Peter coxhead (talk) 16:46, 11 May 2016 (UTC)

  Both WP:AT and MOS:CAPS agree that we use sentence case for titles unless it's a proper name. I suggest using the discussion section below if you find a case where a difference between them was relevant to a title decision. Dicklyon (talk) 17:08, 11 May 2016 (UTC)

• Oppose. Using the common name is an important principle of accessibility on Wikipedia while MOS is a guideline, something that helps editors format and structure the content they contribute. We should primarily think of our readers and only secondarily of our editors. --regentspark (comment) 16:02, 11 May 2016 (UTC)
• Oppose per Blueboar. The tail should not way the dog. oknazevad (talk) 17:03, 11 May 2016 (UTC)
• Oppose per Blueboar, who outlined my feelings much better than I could have. Calidum ¤ 19:19, 11 May 2016 (UTC)
• Support in spirit some clarification, but also reject the "versus" premise. There's an entire essay about why already, at WP:COMMONSTYLE. It is true that AT and the naming conventions guidelines defer to MoS on style matters (they do so in over a dozen places). However, "style" is broad and diffuse without a clear definition, and this is actually also true of proper names (the linguistic and philosophy definitions of the concept diverge), and how to determine what is the most common is often itself controversial. So there is necessarily a bit of overlap. MOS:TM, MOS:CAPS, etc., and WP:AT and the NC guidelines, already appear to adequately account for this. E.g., use "iPod" and "PlayStation", not "Ipod" and "Playstation", because the vast majority of reliable sources use those spellings (that's an MoS rule, independent of AT). What I do support strongly is that WP:COMMONNAME does need to be clarified that it is not a style policy, even if some style matters can sometimes – rarely – be part of a common-name determination on a WP:COMMONSENSE basis. I'll address specifics in the discussion section below.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:53, 11 May 2016 (UTC)

'There's an entire essay about why already, at WP:COMMONSTYLE'? Which you wrote. Dmcq (talk) 16:32, 12 May 2016 (UTC)

And? Every essay was written by someone. Surely you realize they do not appear by magic out of nowhere. The point of essays is that they lay out once, and clearly, an argument we don't want or need to restate over and over again, and the point of referring to them is "go read this instead, so we don't waste time on this rehash again".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  18:00, 12 May 2016 (UTC)

• I am agreed with SMC just above at "support in spirit some clarification, but also reject the 'versus' premise", as well as his extended comments below and conversation with Blueboar. --Izno (talk) 11:19, 12 May 2016 (UTC)
• Oppose per Blueboar et al. –Davey2010^Talk 12:46, 12 May 2016 (UTC)
• Comment - Ok, it appears I asked the wrong question. As I see it now, the best approach is to SNOW fail this and start over with a new RfC (which I will leave to someone better qualified to frame this issue, I nominate SMcCandlish). I stand by my statements that we need dearly some kind of resolution here. ―Mandruss ☎ 13:51, 12 May 2016 (UTC)
• Oppose per almost everyone. A new RFC isn't needed, seems to be enough. Randy Kryn 17:14, 12 May 2016 (UTC)

  We have a SNOW consensus that COMMONNAME should not defer to MOS on style. That's great; the problem is that, apparently, no one but me felt that it should do so, or that that was even a viable question. So we have made no progress whatsoever as to the problem I described in the opener. We've had a bit of constructive discussion, but it was off topic within this RfC. There is no concise alternative proposal, and we couldn't !vote on it here if there were, not without creating an unworkable mess. This RfC was a misfire, and I don't think it seems to be enough. ―Mandruss ☎ 17:51, 12 May 2016 (UTC)

  I'm pretty sure that's not what you have. Any assertion to that effect would draw out the defenders of the MOS, just as an assertion that it should draws out the defenders of TITLE. The problem is not a "versus" relationship between these policies and guidelines, which actually work pretty well together, but rather between the people who want to shift the balance of responsibility between them. Better to just keep on coexisting, working together toward consensus results in article style and titles. We still have no examples of where this breaks down. COMMONNAME is a strategy in support of the Recognizability criterion. Following the recommendations of the MOS is a strategy in support of CONSISTENCY among other things. All worth considering, as TITLE says. Nowhere does it empower COMMONNAME to override other considerations. Dicklyon (talk) 18:20, 12 May 2016 (UTC)

  (edit conflict) We don't have consensus for that either. COMMONNAME doesn't address style at all. Negative reaction to an RfC misapproaching the issue is not consensus for an "anti-MoS" change in the extreme opposite direction, especially when many of the comments are about the erstwhile RfC itself and the lack of conflict between AT and MOS, rather than whether any changes should be made to either. It would be nice to see COMMONNAME clarified, but the approach to doing that is probably to work it out with AT, MOS, and RM regulars, who understand the effects of nuanced changes at these policypages. Village Pump is like ANI, a pot of emotional responses with insufficient background information and experience most of the time. The "common style" issue has been discussed before, and is nowhere near resolution yet. Aa recently at Jan. 2016 it was seriously proposed (with more support that most would have expected) to merge most of AT back into MOS. I more specifically raised the narrow issue you raised here, Mandruss, in late 2015 at WT:AT, and the response was basically "meh". That's probably because earlier in 2015 both MOS:TM and MOS:CAPS were adjusted, after substantial negotiation, to include wording that more closely aligned with COMMONNAME, in explicitly taking into account majority source usage, at the expense of some consistency. In Feb. or March of this year COMMONNAME was copyedited to stop burying its lead and otherwise being confusing, and this automatically brought it more into line with MoS (or, rather, corrected misinterpretations of it as conflicting with MoS). And so on. Incremental changing making the perception of conflict more and more moot.

  Two years ago, virtually every day people were screaming about a "conflict between MOS and AT", and now the issue hardly ever arises. When it does, it can almost always be traced directly to the WP:COMMONSTYLE fallacy, the failure to distinguish between what the common name is ("PlayStation", however styled, vs. "PlayBox" or "WorkStation") and how it is styled ("PlayStation", "Playstation", "Play Station", "pLAYsTATION", "PLAYSTATION", "Play-STation", "Play-station", etc., etc.). The standards are different. COMMONAME wants us to choose the most commonly found name in reliable sources and run that through the criteria, which it will usually pass. It might have not that much of a majority (most common-name debates are about whether the statistical research to determine which name is more common was valid, because few people know how to use N-grams, etc., correctly). MOS:TM (and MOS:CAPS, etc.) expects that if a stylization does something non-standard in English (like using capitalization in the middle of a name, or starting a name with a lowercase letter, or using some kind of non-letter character in place of a letter, etc.) that it will be avoided unless it is found consistently in the vast majority of sources, not just a slight majority.

  This is not a "conflict", it's a completely different analysis, of a separate matter. Failure to understand this is, as I noted elsewhere, is a general semantics problem, like being unable to understand the difference between the proper construction of a room and whether is painted (styled) white or off-white. Generally, people actually can tell the difference, and just want to pretend they can't because they have an interest in a promotional, non-neutral presentation of something; or they don't or won't understand that a specialist style for specialists to use with each other is often not how we write encyclopedic prose for the broadest audience ever; or they falsely believe that WP is a vote or a democracy swayed by off-WP demands ("It's 'SONY', dammit!"), or must do everything exactly the way some paper publications do it, especially those not really independent of the subject, but mired in it. WP's job is to summarize in encyclopedic style the facts as found in reliable, independent, secondary sources, not to ape the impenetrable, obtuse style of technical and legal publications, or the hipsterish, hyperbolic style of entertainment journalism and blogging. So, I don't see what we need another RfC for. AT and MOS work together much better today than they did only a year ago.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:03, 12 May 2016 (UTC)

  Ok. I saw a lot of policy debate in article talk—disagreement about what the policy actually says. Not how it applies to that article, but what it means for all articles. This essentially turns article talk into dozens or hundreds of scattered extensions of this page and other community-level venues, with a ton of overlapping and conflicting discussion. I saw that as extremely inefficient and counterproductive. I felt that kind of thing should be done here, once. If the community is ok with that, I'll just live with it. Now, are we prepared to close? ―Mandruss ☎ 19:29, 12 May 2016 (UTC)

• Oppose: Echoing Blueboar and everyone who followed in assent that this is entirely backwards. COMMONNAME must not be held hostage to MOS. Fylbecatulous talk 21:26, 12 May 2016 (UTC)
• Strong oppose per Iridescent. MOS is routinely at variance with what everyone does, and its dictates are handed down by a tiny minority of people who feel like continually arguing over minutiae and then imposing their will on everyone else. Aside from general MOS provisions, such as WP:ERA and WP:ENGVAR, there's no reason to bow to the MOS types on article titles when we shouldn't be bowing to them on content. Nyttend (talk) 01:16, 13 May 2016 (UTC)

RfC discussion: MOS vs COMMONNAME

• Comment Personally I think pushing too hard for standards is damaging. Unless there is a clear reason otherwise I think articles should be left as they are written and not changed by people who know nothing about the topic. Yes the MoS is liberally sprinkled with exceptions like if the subject habitually said something else then it should be like that - but someone will go around anyway pointing to the MoS and changing it without knowing as much as the original author -and the author if still around will be beaten down by having some TLA WP refernece stuck into the change summary. Dmcq (talk) 12:39, 11 May 2016 (UTC)

What about the scores of very knowledgeable editors who lack the writing skills to create a quality article? Are those who can write well to excuse themselves from improving the article because they lack knowledge of the topic? That, I think, more than anything in the MOS, would be at odds with real-world practices. Also, I had to look up TLA just now and, although it took ten seconds, I think I'll be alright. Primergrey (talk) 13:08, 11 May 2016 (UTC)

Hopefully these very knowledgable editors actually know or read up enough to contribute. No I'm principally worried about people who'll for instance if something is called X-3 will put in a minus sign and change the 3 to 'three' because small numbers should be spelled out. Dmcq (talk) 14:31, 11 May 2016 (UTC)

It's not happening, since it's clear that doesn't pertain to serial or model numbers, per MOS:NUM. The concern doesn't seem warranted. What's the evidence of a problem in this regard? Show us someone trying to rename the B-2 bomber article to "B-two". As for the earlier point in this sub-conversation: The vast majority of WP content is written by non-experts in the field in question. This is possible because WP is based mostly on secondary sources not primary. It takes no expertise to review the all major books on a topic and summarize what they're saying. It takes a great deal of expertise to wade through 2,000 journals worth of primary, unreproduced research and try to figure out what may have validity and what is bogus. There's a reason this is not Academipedia. Experts are of great use on WP in correcting Dunning–Kruger effect incorrect assumptions about source material (including the secondary), and weeding out secondary material that does not actually reflect the consensus in the field in question. But it is true that many scientists and other specialists are not good writers, and few people at all are great writers of encyclopedic material, which is a discipline unto itself, albeit a volunteer hobby for most who engage in it. That doesn't make 5 or 10 years of intensive experience at it less of an acquired and honed skill.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:03, 12 May 2016 (UTC)

• Comment I think it would be helpful to the discussion if it were spelt out exactly which bits of "style" guidance in the MoS are under consideration. I guess from previous discussions that these include capitalization, the use of hyphens and various kinds of dashes, the use or non-use of periods/full stops in abbreviations and acronyms, and the use or non-use of commas in contexts like "Smith, Jr". What else?

Another of my concerns is picking out WP:COMMONNAME from WP:AT; stylization also bears on some of the other principles, like precision and consistency. For example, we could re-open the discussion of how to style the English names of organisms based on showing that for a particular organism the title case style was the most common, even though for most organisms of the same kind the sentence case style was the most common. (I quickly found examples using Google ngrams: e.g. "European robin" beats "European Robin" but "Manx Shearwater" beats "Manx shearwater".) If COMMONSTYLE is to be used, it should be applied to categories of article title, not individual ones. Peter coxhead (talk) 15:34, 11 May 2016 (UTC)

Another "what else" is character substitutions. This sort of this is already covered at MOS:TM pretty well.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:03, 12 May 2016 (UTC)

• Comments: The key point is that the most common styling/stylization of something is not automatically used at Wikipedia, but often eschewed, because the most common styling is frequently not independent of the subject, but outright promotional. In other cases, it may be a highly specialized style that is confusing to encyclopedia readers and found only in ivory-tower journals (or in in-universe geekery materials, or buried in technical jargon that assumes a decade of professional experience, or whatever – by no means is all "specialized", very-narrow-audience publishing of an academic character). In yet others, it may be a pop-culture topic, with most coverage appearing in low-end entertainment press publications, that use informal, efficiency-at-all-costs journalistic style, which has little in common with the encyclopedic register (news style is mostly about getting the most content into the smallest columns as possible, for quick visual scanning; encyclopedic style is about maximum clarity in communication). Worse yet, much of that newsprint, especially in pop-culture topics (entertainment, sports, etc.) is often try-to-sound-hip-or-clever-at-all-costs even more than it is expediency-driven, and its clarify and neutrality terribly suffers as a result.

  In short, WP, like all serious publishers, has a house style, and it applies by default regardless what the topic is, absent very strong reasons to override it, and when (not very often) overriding it helps rather than hinders reader needs (not editor, wikiproject, or external third-party desires).

  The vast majority of the time that people make bogus "COMMONSTYLE" arguments, it's when they're pushing something that does not belong here. Often it's inappropriately promotional (e.g. capitalizing "SONY" to mimic the logo), jingoistic (stripping diacritics from the name of a sports figure who uses the diacritics, just because Americans are less familiar with the proper spelling and the sport governing body is too lazy to use them itself in tournament charts), or an attempt by specialists to force WP to write for its broad readership the same way the specialists write to each other in their own journals (most commonly this is a) Overcapitalization Of Things The Specialists Find Important In Their Context; b) the dropping of hyphenation of compound modifiers in cases where specialists know its a compound modifier but a 7th-grader does not, as in "medium-chain fatty acids" which many scientists want to write as "medium chain fatty acids"; and c) the use of obtuse and often redundantly wordy terminology instead of plain English – "myocardial infarction" at every occurrence instead of "heart attack" which is better in a non-medical article, "party of the first part" instead of "first party", etc.).

  :This is not a conflict between MOS and AT, it's a conflict between encyclopedists who understand the nature and audience of the publication, and people who (often subconsciously) try to misuse the encyclopedia as a tool for things that others will interpret as snobbery, aggrandizement, and/or browbeating.
   — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:02, 11 May 2016 (UTC)

yes we do have a house style... But it is a house style that we can change if there is consensus to change it. If there is a consensus that we should follow source usage for stylization of names, then our "house style" should be changed to reflect that consensus. Blueboar (talk) 21:31, 11 May 2016 (UTC)

A three-part response:

There is no one source usage for much of anything. When there is a near-universal option, of course we use it, rather than make up something (thus iPod, PlayStation, and Deadmau5, not "Ipod", "Play Station", or "Deadmaus", which are almost unattested in RS). When a non-trivial number of the RS use one or more alternatives to an odd stylization, we use a less promotional/ridiculous/confusing option (thus Alien 3 not "Alien³" and Pink (singer) not "P!nk"). (MOS:TM already covers all this in quite a bit of detail.) When the sources are not uniform in a stylistic treatment, we have no reason to go with a visually aggrandizing, silly, or obfuscatory option, and plenty of reasons not to. The huge and stressy RfC about capitalization of common names of species settled this issue over two years ago (as did plenty of RfCs before that, and more since).

WP consensus is to use whatever sourceable style best serves the encyclopedia readers' needs. It can't rationally be any other way. Yes, theoretically, we could have a change of consensus to do everything the most common way, like a techno-hipster theme overall (e.g. [32]), andhaving banner ads all over the place, and HUGE SCREAMING ALL-CAPS HEADINGS, and stupid-but-funny cat GIF animations, and social networking features, and sneaky user-tracking cookies, and writing like bloggers and sports journalists, and photos and icons all over the place crowding our the text, and breaking up ever article into a "1 of 24 >" pane series so content is doled out a mobile-screenful morsel at a time, and yadda yadda yadda. Of course, we don't do any of these things, in spite of how common they are. The COMMONNAME policy fragment is about using commonly-recognizable names. It is not a policy to use the most numerically common style, or stylization, or capitalization, or layout, or font, or typographic effects, or coloration, or [insert whatever else here]. Virtually nothing about WP is done the most common way, but rather the best way we can muster for an encyclopedic purpose and audience (and, secondarily, a volunteer and largely untrained and nonprofessional editorship, though even that consideration has greatly reduced over time, as both regular editors get better at it, and the number of brand new people arriving to try editing for the first time has shrunken greatly now that the novelty has worn off). If anything, COMMONNAME sticks out, like some weird hairy growth on the nose of policy.

WP:COMMONNAME could actually be deleted with no harm to the project. Few people bother to actually read it and think about it. It is not a central policy concern of WP:AT in any way. It's nothing but a default to try first as the most likely candidate to fit the actual naming criteria at WP:CRITERIA. It is not itself one of the criteria at all, and those criteria would remain and still be applied, in the absence of the COMMONNAME wording that refers to them. It is actually superfluous instruction creep that has done little but generate drama and fanaticism. In the end, all of this flag-waving about how style "should" be part of COMMONNAME is just a bunch of pointless extra distraction about what is itself an underlying pointless distraction. We do not need a section in the policy that says "Try this first, as a shortcut for complying with the actual policy requirements" if people are just going to fetishize it and battleground indefinitely against any infidels who do not accept it as somehow replacing the actual policy requirements it was written simply as a funneling tool for. Mistaking COMMONNAME for the actual naming criteria is like taking a road trip to California, reaching the "Welcome to California" sign at the state border, then going home because you've seen California now.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:07, 12 May 2016 (UTC)

Examples?

I think that part of the problem is some people feeling more aligned with MOS or TITLE – but is there a problem, or just a perception? It might help to look at examples. If you know a case where there was a discussion of conflict between MOS and TITLE (or the COMMONNAME) section, list it here so we can look and understand what was at stake. I found one to start with:

• Sunn O))) – At Talk:Sunn_O)))#Requested_move_2, entire rationale for moving back from Sunn (band) to the stylized trademark (still pronounced "Sun") was given as "COMMONNAME". Personally, it looks to be squarely in the domain of MOS:TM, and could have been resolved within the recommendations there, which already says "When deciding how to format a trademark, editors should choose among styles already in use by sources (not invent new ones) ..." As Frungi wrote there, "Support unless we can cite some substantial reliable sources that do not include the decorative characters. Everything I’m seeing in e.g. Google News does include them, so it seems to me like we’re inventing a style by using 'Sunn' bare." So it looks like no modification of MOS is needed to get it to agree with the result that people were looking to get from COMMONNAME. The move was supported "per MOS". No conflict. The discussion was primarily over whether plain "Sunn" is a style in use or not, and it was decided not. No "MOS regulars" objecting, as far as I can see. Dicklyon (talk) 00:53, 12 May 2016 (UTC)

• Dot the i – At Talk:Dot_the_i#Requested_move_2, both COMMONNAME and MOS:CT were invoked. Both lost to the lack of consensus. They were both on the same side, of moving to Dot the I, but an interpretation of a blood splat over a capital I on a movie poster was taken by many editors as evidence that the lowercase i was intended. No conflict, just harmony between TITLE and MOS in this case, and conflict with fanboys. Dicklyon (talk) 05:59, 12 May 2016 (UTC)

• Mandruss has recently been working on styling per WP:JR, and may be reacting to comments by Blueboar on the talk page about that; he suggested "I don't dismiss the WP:COMMONNAME argument. When the majority of sources that are independent of the subject present the name with a comma, so should we... As that is the most recognizable variation." and "My view has consistently been that we should adopt a similar standard to COMMONNAME when it comes to issues like this." But COMMONNAME does not propose any such standard, so this idea went nowhere. And NONE of the related recent RM discussions had anyone claiming that COMMONNAME was something to consider with respect to the comma styling question, and all closed in favor of following the preference expressed by the MOS; these:
• Talk:Andrew_L._Lewis_Jr.#Requested_move_04_April_2016
• Talk:Robert_Downey_Jr.#Requested_move_04_April_2016
• Talk:Feodor_Chaliapin_Jr.#Requested_move_2_April_2016
• Talk:Benjamin_O._Davis_Sr.#Requested_move_2_April_2016
• Talk:Larry_Mullen_Jr.#Requested_move_20_March_2016
• Talk:Desi_Arnaz_Jr.#Requested_move_20_March_2016
• Talk:Arthur_Ochs_Sulzberger,_Jr.#Requested_move_2_April_2016
• Talk:USS_Frank_E._Petersen_Jr.#Requested_move_7_April_2016
• Talk:Harry_K._Daghlian_Jr.#Requested_move_20_March_2016
• Talk:Dale_Earnhardt,_Jr.#Requested_move_17_April_2016
• Talk:Alan_Hale,_Sr.#Requested_move_18_April_2016
• Talk:Barnett_McFee_Clinedinst_Jr.#Requested move 24 April 2016
• Talk:Martin_Luther_King,_Jr._Day#Requested_move_22_April_2016
• Talk:Harry_Connick_Jr.#Requested_move_04_May_2016
• Hundreds of other comma restylings have gone unchallenged; nobody has suggested that any of the names became less recognizable without the comma; nobody (that I can recall) has suggested looking to see what a majority of sources do (doing so would mean nullifying the MOS, which a few people would like, but there was a big consensus to prefer the commaless style, as essentially all modern style and grammar guides recommend, so this would not fly). I see no actual conflict between TITLE and MOS here, even if Blueboar does and would prefer to throw out the MOS. As with MOS:TM, WP:JR makes allowance for exceptions if a name is found that is consistently styled one way in sources; but no such have been found so far. Dicklyon (talk) 19:48, 12 May 2016 (UTC)

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

Designations or qualifiers for authorities cited

In a conversation with a fellow Wikipedian about editing a biographical article, I raised the question, whether it were necessary, when citing an expert on her or his field of study, to identify that field? For instance, if I'm editing the article on Thomas Jefferson, and I want to quote something Dumas Malone wrote about Jefferson, must I refer to him as "historian Dumas Malone", or "biographer Dumas Malone"? I acknowledged the need to describe an authority in connection with forays outside his or her field, such as a novelist writing about an historical figure, or a literary scholar speaking about dance; but I thought it redundant to refer to, e.g., "historian Alfred E. Neuman" when citing Neuman on history.

My fellow Wikipedian thought I was wrong, and said that he had been told by a GA reviewer that he must go even farther, and describe what kind of historian he was citing, as, "twentieth-century historian Alfred E. Neuman", "American historian Alfred E. Neuman", or perhaps "historian of comedy Alfred E. Neuman".

I searched Wikipedia for a policy or discussion concerning this question, but didn't come up with any, so I'm coming to the Village Pump to ask,

1. Is there a policy governing this question, and if so, where can I find it?
2. If not, is there a talk page or forum, other than this one, where a discussion of this question has happened or would be most appropriate?
3. If not, is this the most appropriate forum for such a discussion? (In which case, I'd like to start a new RfC and formulate the question a bit more carefully.)

I look forward to your guidance. J. D. Crutchfield | Talk 18:49, 11 May 2016 (UTC)

I am unaware of any such policy or guideline so if there is hopefully somebody will correct me. The first thing that sprung to mind was WP:CREDENTIAL but that really doesn't apply here since we are using the phrases like "twentieth-century historian" not as a title but as a qualifier (as you note). I suspect this is just a matter of editorial judgment. It sounds like a good idea to sometimes introduce individuals who are not famous to orientate readers. This helps answer any skeptical "Why should I care what Joe Bloggs' thinks?" questions that might bother them. But this is not a black-n-white rule because sometimes it will be clear from the surrounding text that we're supposed to assume the person has some relative background to qualify their opinion. For example if we're in a paragraph talking about critics reviews of a film, we don't need to introduced each person as a film critic because it will be assumed they are film critics within that context. So any GA reviewer always requiring qualifiers ("film critic") and even secondary adjectives ("Chicago Triune film critic") may have taken the idea too far. This example makes it clear that there's probably not any rules in the form of policy or guidelines on the matter as the solution is context-sensitive. Therefore I am going to say it is not necessary to introduce them with the qualifier, just frequently a good idea. I cannot define what good prose is, but people generally know it when they read it. Try to write good prose and sprinkle in qualifiers as it seems the text demands. As for the best location of a discussion, this too is often unclear. The manual of style talk pages might have been a better spot for this question but since you've started it and it's sort of policy-related (as you've framed it) it seems fine by me here. Jason Quinn (talk) 07:20, 12 May 2016 (UTC)

Opinions differ on this. I think most heavy content-writers don't qualify obvious names, only those of people who are not the type of expert on might expect in that context. Where the date the person was writing or speaking is significant I prefer to just give that. But some people think qualification is always expected, which it isn't - see FAC, where a range of styles are accepted. I suppose on some very broad subjects there is no "expected" type of expert, so it is worth always qualifying. Another problem is that "historian Dumas Malone" is grating to many British English readers (it should be " the historian Dumas Malone"), so best avoided per whichever policy that is. Johnbod (talk) 14:19, 12 May 2016 (UTC)

Suppressed RevDel'ed edits

Theres nothing in talk but why were these edits suppressed? Nothing in talk or otherwise for removing the content additions from history? [33][34]. What is WP doing with lack of accountability? My page someone claims its content vio but that can be reworded by consensus instead of suppressing itLihaas (talk) 16:08, 13 May 2016 (UTC)

Wikipedia:Oversight#Complaints explains what to do. --Jayron32 16:42, 13 May 2016 (UTC)

@Lihaas and Jayron32: This isn't an Oversight issue, it's a revision deletion issue. According to the revision deletion guidelines, discussion of those actions should happen on the administrators' noticeboard. {{Nihiltres |talk |edits}} 16:57, 13 May 2016 (UTC)

Why did you bring this here? You were specifically invited by the editor to open a dialog with them if you had any questions about the removal or thought it was in error. It appears you underestimate how seriously we take copyright violations at Wikipedia and have a misunderstanding regarding the nature of our licensing policy. We cannot "reword" copyright violations because the violation "taints" any subsequent derivative work. Copyright-offending material must be deleted. Jason Quinn (talk) 18:07, 13 May 2016 (UTC)

The logs for both pages say that the redactions were done by Diannaa, due to copyright issues. עוד מישהו Od Mishehu 06:16, 15 May 2016 (UTC)

@Lihaas: The edit was detected on April 30 by a bot as being a potential copyright violation, and was reported here. I removed the content on the 5th of May and revision-deleted it under criterion RD1 of the revision deletion criterion and left a short note on your talk page. While in an ideal world it would be nice to post on the article talk page first and discuss how the content should be re-worded, in reality this is not going to be possible, as there's 75 to 100 copyright violations being detected by this bot every day. The content is readily available at the source newspaper article here, or if you wish I could send you a copy of the removed material via email. If you feel my actions violated policy and you wish to bring them to the attention of the wider community, I suggest posting at WP:AN as recommended in the revision deletion policy page. — Diannaa (talk) 13:45, 15 May 2016 (UTC)

Arbcom Probation Templates

I just noticed that several articles that had been on article probation, but no longer are, still had the associated notices on their talk pages and were still included in the Category:Articles on probation. (For those interested, the particular articles should be relatively easy to find from Talk:First_Baptist_Church_(Hammond,_Indiana)#Removing_Arbitration_Probation_Template.)

I would like to propose that, if it is not already part of the policy, that we modify the policy and procedure for Arbcom sanctions so that articles under probation have the notice removed when they are no longer under probation. I imagine there are likely instructions somewhere for what to do when a decision like that is rescinded. I noticed that we strike out the decision. The instructions should be changed to explicitly note that articles ought to have the notice removed from their talk pages and removed from the category at the same time that the original sanction is struck on the respective Arbcom page.

I'm not sure if this particular case was just an oversight and it is the general policy to do that, but if it is not the case, then it ought to be modified. Zell Faze (talk) 05:36, 14 May 2016 (UTC)

Havent looked through any relevant policy pages, but this looks like a good idea. עוד מישהו Od Mishehu 06:13, 15 May 2016 (UTC)

RfC: Wikidata in infoboxes, opt-in or opt-out?

Some editors have brought up issues with Wikidata in infoboxes being included in this way. Should such inclusions continue to be "opt-out"? Curly Turkey 🍁 ¡gobble! 20:59, 15 May 2016 (UTC)

Background

In 2013 Wikipedia:Requests for comment/Wikidata Phase 2 determined "to permit Wikidata inclusion when there is no existing English Wikipedia data for a specific field in the infobox". This has been interpreted so that

• such data will be included in Infoboxes by default if such data exists, and it will be included silently, without any notice on people's watchlists.
• such data can be excluded only by including an empty parameter: e.g. "|isbn=". If the parameter is absent (rather than empty), inclusion of WikiData will still happen automatically.

Note: This discussion is not about whether we should use WikiData, but about how such data should be imported. If you issues with WikiData itself, that should be a separate discussion. Curly Turkey 🍁 ¡gobble! 20:59, 15 May 2016 (UTC)

The above is a biased presentation of the issues in contravention of WP:RFC, which requires the filer to "include a brief, neutral statement of or question about the issue". It is untrue that "such data will be included in Infoboxes by default if such data exists, and it will be included silently, without any notice on people's watchlists" and it is also untrue that "such data can be excluded only by including an empty parameter: e.g. "|isbn=". If the parameter is absent (rather than empty), inclusion of WikiData will still happen automatically." The implementation is entirely customisable by the infobox coders and can be 'opt-in' or 'opt-out', depending on what the users of the template want. --RexxS (talk) 10:38, 17 May 2016 (UTC)

Please note this. I doubt there's a credible excuse for this attempt to derail the discussion. Curly Turkey 🍁 ¡gobble! 11:12, 17 May 2016 (UTC)

There's no excuse for your attempts to railroad this discussion, either. I'll move my refutation to a "Background" section, along with your move your non-neutral commentary. Let's see if other editors are unhappy with that. --RexxS (talk) 11:23, 17 May 2016 (UTC)

!Votes (Wikidata)

• Switch to opt-in, per below. Curly Turkey 🍁 ¡gobble! 01:05, 15 May 2016 (UTC)
• Switch to opt-in. Ruslik_Zero 08:19, 15 May 2016 (UTC)
• Switch to opt-in. Editor participation in such additions is important for verification, appropriateness, size of infobox, etc. Peter coxhead (talk) 08:24, 15 May 2016 (UTC)
• Switch to opt-in (mostly per below). — Rhododendrites ^talk \\ 12:40, 15 May 2016 (UTC)
• Continue opt-out: it is the whole point of having structured data – every editor does not have to re-invent the wheel. Assume WP:GOODFAITH that the structured data is verified just like any other facts in Wikipedia. –BoBoMisiu (talk) 13:37, 15 May 2016 (UTC)
  • BoBoMisiu—my rationale below mentions nothing about whether the data is verified. Please respond to the actual rationale, which has nothing to do with good or bad faith. Curly Turkey 🍁 ¡gobble! 20:52, 15 May 2016 (UTC)

@Curly Turkey: I read what is written again. The question is "about how such data should be imported", the rationale is described by you as "editors lose control over the articles they edit", i.e. about who controls how and what data is displayed. The example of ISBN to me seems like the ideal use of structured data with little reason to exclude it. It is easier to correct structured data in a silo than to correct many articles that cascade from it. Another template that uses structured data is {{authority control}} – would your proposal also require an editor to opt-in for those kinds of templates which are not infoboxes but just as unverified? Nigel Ish's comment about Wikidata not being sourced may be a system problem or a classification problem but, just as with other content, editors can change it. –BoBoMisiu (talk) 23:02, 15 May 2016 (UTC)

BoBoMisiu—It is easier to correct structured data in a silo than to correct many articles' ...': again, you've misunderstood what the RfC is about. This is not about overriding what data is in Wikidata with local data—it's not about replacing the value for ISBN at Wikidata with a local value (let's assume we have no desire to do so). Nor is it about the reliability of Wikidata (let's assume it's perfect). It's about how we choose what to display, whether inclusion of each individual field should be explicit or automatic. Curly Turkey 🍁 ¡gobble! 23:15, 15 May 2016 (UTC)

@Curly Turkey: I think I understand, and used {{authority control}} for comparison. I think it should be automatic, i.e. continue opt-out. If it displays incorrect content than correct the wikidata. If classes of infoboxes need to exclude some wikidata, then those templates should be changed; but if instances of infoboxes need to exclude some wikidata, then it should be overridden in the instance. If the concern is editors do not see content of new or changed wikidata fields, then that is a wikidata watchlist problem. I see the difference between the data and the presentation of the data. –BoBoMisiu (talk) 23:31, 15 May 2016 (UTC)

BoBoMisiu: If it displays incorrect content than correct the wikidata.—the fact that you keep bringing this up shows you are still misunderstanding the what the RfC is about. We are assuming the data is correct, and that Wikidata is a good thing. This RfC is strictly about the display of this data in infoboxes. Curly Turkey 🍁 ¡gobble! 00:27, 16 May 2016 (UTC)

@Curly Turkey: I think I understand. I assume all structured data is a good thing; I do not assume all structured data is correct; I think opt-out should continue for presenting that data in templates, including infoboxes. If I am misunderstanding, then is the RfC about aesthetics of a larger box? –BoBoMisiu (talk) 01:32, 16 May 2016 (UTC)

Aesthetics would be one argument, but there are other concerns (such as: is every piece of data even appropriate for an infobox?). When I say "we are assuming the data is correct", I mean the argument to opt-in is not based on the correctness of the data—that would be an argument against Wikidata itself, which is not what this RfC is about. Curly Turkey 🍁 ¡gobble! 01:46, 16 May 2016 (UTC)

• Continue opt-out. A better solution would be to better link to Wikidata from the infoboxes. That is the entire point of the project, and editors are not losing control over their content - they should just be filling it in elsewhere. If Wikidata was fully integrated and used properly, then we wouldn't need to re-invent the wheel for every project using the same data. This is a clear step away from that. Ajraddatz (talk) 20:02, 15 May 2016 (UTC)
  • Ajraddatz—it's not about re-inventing the wheel or abandoning WikiData. Please respond to the actual rationale, which has nothing to do with keeping data on Wikipedia separate from WikiData. Curly Turkey 🍁 ¡gobble! 20:52, 15 May 2016 (UTC)
    • I did respond to the rationale, as you had written it below. Particularly the part about editors losing control over their content, which is just wrong. I agree that there needs to be some steps towards more effective integration, but I don't think this is the way forward. Ajraddatz (talk) 23:20, 15 May 2016 (UTC)
      • Ajraddatz: "control" strictly in the context of how the data should be included in infoboxes, not where the data should come from—the assumption is that Wikidata is good. There is no reinventing of wheels proposed. Curly Turkey 🍁 ¡gobble! 00:24, 16 May 2016 (UTC)

• Switch to opt-in: It needs editors to determine whether information in Wikidata is relevant and appropriate. What's put in infoboxes in En:Wiki needs to confirm with consensus here. As an example, consider all the fuss about whether or not the "religion" field gets filled in on biographical infoboxes. We have guidance as to when such optional fields are used. Autofilling fields means that this guidance may not be repected and could lead to problems (for example, opinions over someone's nationality or religion may differ between different language wikipedias). Also Wikidata is fundamentally unsourced and not a reliable source, while data fields on Wikidata are liable to change without warning and discussion, which can break things here (WP:Ships had problems with this - see Wikipedia_talk:WikiProject_Ships/Archive_44#Wikidata_.E2.80.93_again and Wikipedia_talk:WikiProject_Ships/Archive_46#wikidata_and_ship_infoboxes.Nigel Ish (talk) 20:20, 15 May 2016 (UTC)
• It depends. For template fields which should almost always be filled in – e.g. map image in {{infobox road}}, {{authority control}} identifiers – Wikidata should be included automatically, with the possibility of an override for rare cases which do not conform (opt-out). However, if the number of exceptions is not insignificant, and they can't be worked around (by using parser functions or lua to validate if the wikidata is appropriate – e.g. to not automatically include ISBN unless the publication year is after 1970s, which would stop older books having an ISBN displayed), then it should be opt-in. (And if the data in Wikidata is garbage, or not up to enwiki standards – e.g. Nigel Ish's WP:Ships examples – then it shouldn't be included at all) - Evad37 [talk] 03:24, 16 May 2016 (UTC)
• Continue opt-out, because well, it's sure going to screw up Template:Infobox road, which was designed to function this way. Or if not, at least provide an option so that individual templates do not have this new standard unwillingly enforced on them. --Rschen7754 03:39, 16 May 2016 (UTC)
• Continue opt-out (i.e., Wikidata as default unless an infobox opts out). I'm sympathetic to the proposal, but it looks like the core issue is getting consensus on each infobox's talk page on what parameters should default to Wikidata, as it's clear that the Wikidata shouldn't light up the whole infobox, but that call is for local consensus to decide. The bigger issue right now is turning on the firehose and getting the kinks worked out—looks like we're going one infobox at a time? @Ferret, has been working on arbitrary access with {{Video game review score}}s, and {{infobox video game}} is up next. On the technical end, I hope that someone with the chops is looking into how to have watchlisting on enwp simultaneously watchlist the wikidata entry. Time is nigh for toollabs:crosswatch. czar 05:26, 16 May 2016 (UTC)
• Continue opt-out I thought on a basic level this was to be decided on a infobox by infobox basis with local consensus, and for that matter, on a field by field basis. I don't see a reason to force opt-in across the board, if the infoboxes for particular projects prefer opt-out. If a particular field causes trouble on enwiki, the maintainers of that infobox can just remove Wikidata from that field till consensus develops. In some cases, Wikidata may just never be suitable. Each infobox can decide to do things as their needs dictate, and it should be easy enough in most cases to include a single parameter to cut off (i.e. opt out) of any wikidata population. -- ferret (talk) 12:21, 16 May 2016 (UTC)
• Continue opt-out: However, the method to opt out needs to be easier (as suggested) than by filling in ALL the empty params. A nice simple |wikidata=no (or similar) should suffice. As an encyclopedia, we have a duty to provide data that's both complete and accurate. Wikidata gives us this in spades, and it should be rare that we need (not want) to exclude it. Fred Gandt · talk · contribs 12:26, 16 May 2016 (UTC)
  • it should be rare that we need (not want) to exclude it—that statement needs backing up, and there's a lot more to editorial discretion that IDONTLIKEIT. There's little more to indiscriminate automatic inclusion than ILIKEIT. Curly Turkey 🍁 ¡gobble! 12:56, 16 May 2016 (UTC)
    • I didn't say it will be or is rare; Do you disagree that it should be rare? Whether we LIKEIT or not, if the (Wiki)data is applicable, verified and accurate, we should be including it (accepting what should be rare exceptions, when editorial discretion takes over). Fred Gandt · talk · contribs 14:13, 16 May 2016 (UTC)
• Broadly, opt-out. In response to each of CT's points below:
  1. This is an issue of two things in conjunction: arcane template syntax and the rollout of Wikidata, if in fact these fields are not being filled in because of "thousands of editors" electing not to have them filled in (a claim deserving of a {{dubious}}). Once we're at the steady-state of including Wikidata, these issues will fall by the wayside due to watchlist integration and correct implementation of the links at Wikidata.
  2. "Long lists of parameters" is strawman fallacy--correct coding of an infobox prevents this as an issue.
  3. This is an issue of education and of "trying what works". Because so few templates have converted to use Wikidata, no-one has worked out the best way to deal with discovery of Wikidata (which may be a good thing? it depends on your POV). There is also work on-going on the back end e.g. with Capiunto. In the meantime, the documentation page for an infobox should be very explicit about the expectations it has.
  4. Bringing up the specifics of ISBN muddies the water of this RFC. I don't see value in discussing it here. --Izno (talk) 12:42, 16 May 2016 (UTC)

  Izno: You'd better reread strawman fallacy. As implemeted now, long lists of empty parameters are the only way to prevent these fields from being automagically filled in later on. Curly Turkey 🍁 ¡gobble! 12:56, 16 May 2016 (UTC)

  And what concrete educational plan do we have? Curly Turkey 🍁 ¡gobble! 12:56, 16 May 2016 (UTC)

  Concrete examples are "muddying the water"? Then what are we supposed to discuss? Curly Turkey 🍁 ¡gobble! 12:56, 16 May 2016 (UTC)

  Please don't interleave your comments within mine as it muddies attribution. I numbered my comments for ease of response. I have subsequently WP:REFACTORed. In reply:

  One parameter inclusion for any set of template aliases will be enough to stop an inclusion from Wikidata. This is the strawman point. Perhaps your original point was unclear, as that is what I responded to. Attempting to prevent inclusion of all parameters seems like you'll be attempting to disrupt to make a point/is a bit beansy, since it's clear that Wikidata is meant to replace infobox data inclusion to some (or all, as appropriate for the infobox and article) extent. As for automagically later, they will only be "automagic" in the sense of one of the following: Either a) an editor removes the data from Wikipedia, in which case you will be notified by watchlist or b) an editor has already removed the data from Wikipedia and someone is adding the data at Wikidata, in which case you will also be notified by watchlist. It is only during this (c) time period of starting to include Wikidata in infoboxes that there is any semblance of an unexpected piece of data making it into Wikipedia--and those can be handled on a case by case basis, either at the article level or at the template field level.

  We don't have an educational plan... but I don't think discussing it here in this comment makes any sense, since it's not directly topical to the question at hand. Maybe that's a per-infobox thing, or a new RFC, or a new subsection below. You can choose, since you're interested in investigating the question.

  ISBN is concrete, but so is the entirety of Template:infobox telescope, or template:infobox cheese, or a substantial chunk of Category:Templates using data from Wikidata... the implementation of which has been trivial. So my 20+ good fields to your 1 bad field indicates that there are kinks, and that ISBN is a kink, and not the general case. This is why it's my belief that it's not worth discussing here, in a general RFC. --Izno (talk) 13:33, 16 May 2016 (UTC)

  Izno—you're still showing an extremely poor understanding of what a strawman is. A prime example is your remark about "prevent[ing] inclusion of all parameters".

  Your accusation of disruptiveness is straight out of nowhere. What's being disrupted?

  So my 20+ good fields to your 1 bad field—huh? Please look at the example for The End of the Road I left at Template talk:Infobox book. Curly Turkey 🍁 ¡gobble! 13:57, 16 May 2016 (UTC)

  Your "many of which are redundant" can be (ambiguously) interpreted as "I have a number of template parameter aliases" as I interpreted or as you apparently interpreted it. The former is a strawman.

  Respond to the point please, if you have an actual response.

  I can show you literally hundreds of template parameters that have had Wikidata implementation added without issue. You can show me... 3. The point I am making is that ISBN is a more-or-less a special case, which will need to consider the Wikidata guidelines regarding inclusion of certain data on certain data items. So again, it's a special case and therefore doesn't need discussing here. --Izno (talk) 14:05, 16 May 2016 (UTC)

  I don't where you get "3", and you still obviously have no idea what a strawman is. Your comments are getting less and less coherent, which makes them especially difficult to respond to. If you can't point to where I've attempted to be disruptive, then please strike the comment. Curly Turkey 🍁 ¡gobble! 14:19, 16 May 2016 (UTC)

• Opt-in and I really like the Parameter=Wikidata idea. This keeps it clear where the data is coming from, makes it obvious and easy to remove, and if a value is incorrect it points people in the right direction for figuring out how to correct it. It's easy to include Parameter=Wikidata when a template is typically copy-pasted in in the first place.

A good exception is something like Authority Control which normally should not include any parameters. In that case it's obvious to check the template page to figure out what's going on. Alsee (talk) 13:01, 16 May 2016 (UTC)

• Opt-in. We had a problem recently with Wikidata at the infobox of Night (book), a featured article. Night is a book about Elie Wiesel's time in concentration camps with his father during the Holocaust. I noticed that the infobox was suddenly listing the genre as "autobiographical novel." I had left the field empty because scholars can't agree on the genre, and Holocaust deniers call it a novel in their efforts to fictionalize it. The author has strongly denied that it is a novel.
  It transpired that a Wikidata bot had lifted the genre data from the Italian Wikipedia, which does call it a novel. Because the infobox had no genre field, the addition to Wikidata caused it to be added to the English Wikipedia too. See the discussion.
  What was very annoying was that I couldn't see how to remove it, because when I looked for the words "autobiographical novel" in the article, they weren't there. It also wasn't easy to see when the change had been made; when I looked through the article history, the Wikidata addition was showing up in old versions of the article. This is caused by a MediaWiki feature to do with the way it handles templates.
  So the current situation means (a) articles are being edited remotely, including featured articles, sensitive articles and BLPs; (b) the edits are being made without reliable sources; (c) the edits don't show up on watchlists unless you watchlist Wikidata, and a lot of us don't want to have to do that, so false or unsourced material could be there for a long time before anyone notices; (d) you can't see how to remove the new material by looking at the wikitext; (e) you can't locate when the change first appeared by looking at the history, because the way Mediawiki handles templates means that old versions of the article will appear to include the new material. SarahSV ^(talk) 15:21, 16 May 2016 (UTC)
• Opt-in per Sarah. Ealdgyth - Talk 16:59, 16 May 2016 (UTC)
• Opt-out — must be kept in order to deliver any functionality at all. Wikidata is an international collaboration across languages, requiring editors to opt-in for each and every parameter would undermine the entire purpose of it. If templates include wrecklessly many parameters, they should instead be fixed — so as not to display useless data at all. We need to think about the future of using Wikidata on Wikipedia — and the only way to ensure that Wikidata will be useful is to continue opt-out.

Wikidata is already being put to use is creative and useful ways in the Template:Infobox medical condition(new) at Gout — and removing this functionality from default would hinder using the amazing open source resources that can be "harvested" for simple data statements. Carl Fredik 💌 📧 18:02, 16 May 2016 (UTC)

• opt-out per Carl Fredik rationale--Ozzie10aaaa (talk) 18:56, 16 May 2016 (UTC)
• Opt-in. The machinery for the opt-out option is inadequate. Notably, editors receive no notification the infobox data has changed when migrating to Wikidata; they only receive notification for changes that have come after and that is only if they know to enable the display of Wikidata changes on their watchlist. Furthermore, editors might not be interested in all of the changes that are made to data on Wikidata - which are most often technical in nature - but only in those that affect the article content. To make matters worse, to hide information retrieved from Wikidata, you've got to insert a blank property in the template invocation. This is totally opaque to most people. Izkala (talk) 19:14, 16 May 2016 (UTC)
• Opt-in per SarahSV. Mike Christie (talk - contribs - library) 19:22, 16 May 2016 (UTC)
• Opt-in per SarahSV. Simon Burchell (talk) 19:34, 16 May 2016 (UTC)
• Broadly, I think that these should be opt-out, but we need an implementation such that we can force specific parameters to be empty if needed, and maintenance tools that reflect the new cross-wiki-transclusion reality. {{Nihiltres |talk |edits}} 21:00, 16 May 2016 (UTC)

  Nihiltres, can you clarify? Are you saying your !vote is opt-out, but that you believe we need to ask for these additional things, or is your !vote opt-out only if these things are provided or promised? Mike Christie (talk - contribs - library) 21:14, 16 May 2016 (UTC)

  @Mike Christie: I mean the former; my !vote is not contingent on software improvements. {{Nihiltres |talk |edits}} 21:21, 16 May 2016 (UTC)

• Opt-out, let's expand the Wikidata infobox project per BoBoMisiu, Ajraddatz, czar, Izno, CFCF, and Ozzie10aaaa. Here are my own reasons -

• Wikidata infoboxes connect all language Wikipedias. This is a big deal. This realistically will increase the reach of Wikipedia by a billion people and further establish Wikipedia (and the concept of non-profit, advertising-free media) as the dominant publication in every language that does not have an extremely wealthy publishing sector.

I have no special loyalty to English Wikipedia, and am ready to say that English Wikipedia should make some compromises if that benefits other language Wikipedias. The compromise requested in this case is that when the feature does not work, and it usually should, then English Wikipedia contributors have to do the labor of turning it off. Turning it off should take one edit and not more than a few seconds for someone who knows how to do it. I am ready to advocate for English Wikipedia taking on this risk, because I think that usually the Wikidata content will be welcomed and because when it is not welcome, I think it will be easy to turn it off.

Crowdsourced human contributor translation of information across languages will not be a viable way to share information cross-wiki in the foreseeable future, except for the present opportunity to share some basic data with Wikidata infoboxes. English Wikipedia can enjoy the privilege of setting standards for how those boxes will appear. Other languages will have much less say in the matter, and are likely to accept the translation and presentation of that originates from English Wikipedia choices.

• Wikidata infoboxes increase quality control. The sort of data which goes into infoboxes will usually be more stable and have higher verification standards than typical Wikipedia content.
• Wikidata infoboxes attract institutional oversight Portal:Gene Wiki has done this with Wikipedia articles on genes. Other institutions will follow. I think that it is reasonable and conservative to anticipate that adopting Wikidata infoboxes will attract content donations in fields of science, medicine, economics, library information, and popular media. This kind of information in the past would have cost large sums of money to create, and now expert institutions are prepared to give it away if they can identify media partners who will share the content to a large audience. What happened with Gene Wiki can happen again in many other fields. Research institutions already contact Wikipedia organizations regularly to propose data sharing collaborations. Wikipedia volunteers are important, but it is also important to establish compelling reasons for the world's experts to invest labor in the development of free public information at the direction and under the oversight of the Wikipedia community. The Gene Wiki team made fantastic and generous contributions to Wikipedia that I hope can serve as a model for what is expected of other organizations who would donate data.
• Wikidata infoboxes follow contemporary social trends Technology commentators talk about how concepts of open data and Semantic Web will inevitably drive the development of the media that most people consume. I agree - this is inevitable. Storing basic data in a format that is machine-readable and which generates clear, uniform presentations on various Wikipedias is an option worth serious consideration.
• Wikidata infoboxes were a major reason for the establishment of Wikidata Integration with the information presentation of various language Wikipedias was always part of the end game for Wikidata, and before Wikidata, the idea of having a shared database for shared information is an idea older than Wikipedia, the World Wide Web, or the Internet. I think that Wikimedia community culture has its own internal pressures which lead contributors to want Wikidata infobox integration. It might happen sooner or later, but under some circumstances, I expect this to happen. If anyone opposes the idea, then I think a good way to oppose would be to critique the system and call for restrictions on it, rather than to argue that it never happen. When these things get established it is much easier to write early rules than to prohibit the entire system. If anyone wants to demand some wild compromise or concession then now might be a good time to make a request.

Blue Rasberry (talk) 21:15, 16 May 2016 (UTC)

• Leave it up to editors to decide. We gain nothing by forcing either opt-in or opt-out on every implementation of wikidata-aware infoboxes, and we don't need petty bureaucrats telling each different group of infobox editors "You can't do it that way because the RfC decided your way is wrong." There are no wrong ways to implement Wikidata-awareness in infoboxes, because every template has a different audience with different needs and flexibility in approach is key. --RexxS (talk) 23:21, 16 May 2016 (UTC)
• Opt-in Due to the problems outlined above. BLP specifically - there is no way an external project should be able to effectively include unsourced information in a BLP without being manually checked by a wikipedia editor first. The BLP policy actually requires that information on a wikipedia article is reliably sourced, and Wikidata does not comply with this in general practice. So any automatic inclusion currently is prohibited by policy for BLP's. I would not object to it being opt-out if the opt-out method is made a lot easier. The previously mentioned 'wikidata=no' parameter being one option. Only in death does duty end (talk) 11:01, 17 May 2016 (UTC)

Rationale (Wikidata)

• Lots of problems:
  • Many editors leave out these fields deliberately—silently filling in these parameters overrides the decisions of potentially thosands of editors without even letting them know.
  • Many infoboxes have long lists of parameters, many of which are redundant. Keeping an infobox compact would mean loading up the source with parameter after empty parameter, cluttering up the source and making it more unfriendly to large numbers of editors, particularly new ones.
    • This is a particular problem with newly-added parameters—as most of us can't afford a crystal ball, we can't possibly predict all the parameters we should exclude.
  • To most editors, if data such as the ISBN appears in an infobox without being specified, it's not in the least obvious why it displays or how to suppress it. Most editors are unaware of the Template namespace, and even if they are aware, may not be able to guess the name of the parameter they want to suppress.
  • Many parameters may not be appropriate for infoboxes, for example ISBNs or page counts for books that have many editions, ISBNs for books first published before ISBNs were introduced in 1970, or clutter like Dewey Decimal numbers, etc.
• In short, editors lose control over the articles they edit, without even realizing it has happened. A better option would be to make this all opt-in, specifying only the parameters to be included, via something like "|isbn=yes" or "|isbn=WikiData". for those who want complete autofillin, perhaps something like a "|WikiData=all" or "|autofill=yes"—an option that perhaps opens the door to specifying particularly common subsets, as well (for example: "|autofill=minimal" for a bare-bones box). Curly Turkey 🍁 ¡gobble! 01:05, 15 May 2016 (UTC)
• There's no evidence that lots of editors leave out many fields deliberately. This is just anecdotal hearsay. Until we have a means of ascertaining the extent to which fields are intentionally suppressed, this issue should not become a barrier to progress. Template:Infobox telescope has many fields that automatically populate with the Wikidata values when the parameter is omitted, and I've not seen a single complaint yet that editors have lost control of their articles. it's been so successful that astronomy editors in Lithuania are adopting it for use on their wiki. I don't doubt that there are other topics where that approach won't work as well, but I'm firmly opposed to telling the editors like Mike Peel, who have worked really hard on creating that infobox template, that they can't implement their infobox that way, because this RfC - populated by editors who have never touched Template:Infobox telescope - may decide that there's only one proper end to crack a boiled egg. --RexxS (talk) 23:44, 16 May 2016 (UTC)
  • There's no evidence that lots of editors leave out many fields deliberately—there's plenty of evidence in the years-long disputes over infoboxes—there's nothing anecdotal about it. What's unenlightening is cherrypicking Template:Infobox telescope, with 184 transclusions, versus Template:Infobox book, which has 37,393, which doesn't include articles that don't even use an infobox, such as the FAs The Sun Also Rises, Mary: A Fiction, and The Monster (novella). Curly Turkey 🍁 ¡gobble! 03:40, 17 May 2016 (UTC)
    • There's no need to barrack every editor who presents a different view from yours - your motivations are transparent. Half the comments in this RfC are from you and you need to back off. There really is no evidence beyond your unsubstantiated claim, so I challenge you to give the diffs of where you can show that the "thosands [sic] of editors" intentionally left out fields from an infobox. I also don't appreciate the 'cherry-picked' ad hominem. Template:Infobox telescope is one that other editors have worked hard at, to create a working example of a wikidata-aware infobox, and you do a disservice to their efforts by belittling them. Their work is no less valuable because it's only used on a few hundred articles. --RexxS (talk) 10:28, 17 May 2016 (UTC)

      I can't provide evidence of thousands of editors, but I can certainly give you one. I've worked on a lot of magazine articles and articles about Anglo-Saxon kings. These have fields that seem logical but often need to be left out; for example, there's a "frequency" field for magazines which shouldn't be used if the magazine did not conform to a single frequency for the great majority of its existence. And take a look at Ælle of Sussex; almost nothing is known about him, and I would guess that very few of the available fields have accurate information available. People add this sort of thing to these infoboxes periodically, though; if you want I can find some examples by trawling through article histories, but please take my word for it. My concern with opt-out is that I want to know when an article I've been editing has its quality degraded so I can fix it. If watchlist mechanisms existed to alert me to this, I think that would address my objections, but as far as I can tell they don't. Mike Christie (talk - contribs - library) 10:37, 17 May 2016 (UTC)

      • But you're only one, and I'm only one, and the others are each only one, and we can't provide diffs (?!?) that we deliberately have left these fields blank. The entirety of RexxS's comment is ad hominem, and it's obvious no evidence will convince him of what he doesn't want to believe. Since he's (again) here only to fight, I'll be ignoring him. Curly Turkey 🍁 ¡gobble! 10:47, 17 May 2016 (UTC)
        • I expect the closer will be ignoring you as well. You make claims and then can't substantiate your hyperbole. The point of an RfC is to get opinions from other editors, so it's about time that you STFU and started listening to other editors, rather than ramming your POV down everybody's throats. --RexxS (talk) 11:08, 17 May 2016 (UTC)

Discussion (Wikidata)

• Rschen7754—could you elaborate? Is this an exception, or does your reasoning apply to, say, {{Infobox Person}}, {{Infobox Book}}, etc? Curly Turkey 🍁 ¡gobble! 03:44, 16 May 2016 (UTC)
  • I don't see why it is an exception, considering that a local consensus is required to enable Wikidata for a template in the first place. If the ships infobox is having an issue, then pull the Wikidata code from that infobox. No need to enforce a standard across all infoboxes that they don't necessarily want. --Rschen7754 03:47, 16 May 2016 (UTC)
    • But doesn't it go both ways? Just because it works well for roads, why is that reason to enforce it on people, books, and bands without discussion? Curly Turkey 🍁 ¡gobble! 04:14, 16 May 2016 (UTC)
      • Nothing forces the use of Wikidata on those other cases. If you want to add the freedom to choose either opt-out or opt-in, that would be fine, but the proposal as you have written does not allow that. --Rschen7754 04:16, 16 May 2016 (UTC)
        • You'll want to take a look at {{Infobox book}}, then, where it was added without discussion. The rationale is that Wikipedia:Requests for comment/Wikidata Phase 2 mandates this across the board. Curly Turkey 🍁 ¡gobble! 04:18, 16 May 2016 (UTC)
          • From my reading: "There is sufficient support for option 3 however, to indicate that this modification should be done carefully and deliberately, at least at first." Option 3 clearly requires the use of local discussion. Also, from skimming over the related discussion, this does not appear to have been done "carefully and deliberately". --Rschen7754 04:36, 16 May 2016 (UTC)

• Does anyone have an update on the phases and rollout, etc.? Is the plan to turn on Wikidata access by default for all infoboxes, or is this a case by case implementation? If the latter, where are the directions that an editor can bring to an infobox talk page for consideration and implementation? czar 05:28, 16 May 2016 (UTC)
  • It depends on who takes initiative. As far as {{Infobox road}}, it's our eventual plan to turn it on for more fields, but we're waiting for some stuff to be done on the Wikidata dev side (Capiunto, I think it's called) to make life easier. --Rschen7754 05:43, 16 May 2016 (UTC)
• I wonder if this discussion is too soon. Before any progression goes too far I would like to see wikidata work with existing templates commonly used in infoboxes e.g. {{death date and age}} The use of wikidata in templates like {{Infobox person/Wikidata}} means that age now has to be calculated and added manually. I'd also likethe ability to watch the wikidata page for a page I watch here on my wikipedia watchlist before I would be more happy about the source being split between two stores. I think the basic premise is good but there need to be more tools available for monitoring and checking first. Nthep (talk) 07:49, 16 May 2016 (UTC)

  There is an option in your preferences to add Wikidata changes to your watchlist (exception: not an "enhanced" recent changes/watchlist--this is phab:T46874). --Izno (talk) 12:09, 16 May 2016 (UTC)

  Template:Infobox person/Wikidata was only intended as a test-bed to try out methods of data-awareness. Nevertheless setting |birth_date={{death date and age|yyyy|mm|dd|yyyy|mm|dd}} in an article will allow you to use local values there, exactly as you would with Template:Infobox person, because any local parameter overrides the value fetched from Wikidata. --RexxS (talk) 23:32, 16 May 2016 (UTC)

I like the idea of "isbn=WikiData". It makes it clear to an editor where the data is coming from, plus it gives them control over whether they want it. Without this, data will be appearing out of nowhere, and editors will have no idea how it got there. 217.44.215.253 (talk) 11:50, 16 May 2016 (UTC)

• User:CFCF can you please explain how opt-in would prevent people from doing what was with the infobox at Gout? Jytdog (talk) 18:26, 16 May 2016 (UTC)
• While I'm not averse to using Wikidata within Wikipedia articles - I do wonder about verifiability. The purpose of an infobox is to summarise key information from the article. The infobox guidelines at MoS state that the information should be already in the article (and cited) or referenced in the infobox (unless "obvious"). It is unclear to me whether the proposed mechanism:
  • checks whether the data has a reference on Wikidata?
  • checks whether the reference meets the requirements of a reliable source?
  • inserts a suitable reference into the article?

Difficult to decide on opt-in or opt-out options without knowing the answers... Robevans123 (talk) 20:15, 16 May 2016 (UTC)

I agree with that Robevans123. Wikidata is cool in theory but the devil is in the details. Jytdog (talk) 20:24, 16 May 2016 (UTC)

• CFCF—could you explain what's happening at Gout? There's no documentation at Template:Infobox medical condition(new), and when I looked at the source at Gout, it looked like a traditional infobox. Curly Turkey 🍁 ¡gobble! 21:31, 16 May 2016 (UTC)