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)

• Comment: Parenthetical notes in an article title (unless the parenthetical notes are part of the article title) should only be used to distinguish between multiple articles with the same title. I can't think of a time when I would add a parenthetical dab to a title of an article when it didn't belong, merely to clarify something. Perhaps if some examples of contentious article titles were posted, we could see the nature of the dispute here. --Jayron32 03:11, 25 March 2016 (UTC)

This isn't a pertinent concern, since the disambiguation in question is always or at least virtually always done with natural, comma, or descriptive disambiguation (can anyone think of any exception?). For about two years, adherents to parenthetic disambiguation pushed for this at naturally ambiguous animal breed article titles as a WP:LOCALCONSENSUS gambit, and consistently failed to gain consensus for that (see WP:BREEDDAB for partial list of RMs and outcomes).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:53, 17 May 2016 (UTC)

• No guidance. This kind of guidance is a can of worms - loads of unintended consequences. We should not "pre-disambiguate" an article because "it sounds too generic" or "that doesn't sound like it is an X" or "that sounds too similar to X". If there is an existing encyclopedic topic that shares a name with another topic, there is potential ambiguity, and we refer to WP:DAB's guidance. If there's only one topic, then WP:DAB does not come into the equation. The examples given to illustrate the contested guidance show that. "Flemish giant" - with no context - sounds like it might be a tall person from Antwerp. While this may be true, tall people from Flanders is not an encyclopedic topic. So instead, Flemish giant redirects to Flemish Giant rabbit - a domestic rabbit breed.

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

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

"If you prefer 'Flemish Giant rabbit' for WP:CONSISTENCY purpose or something else, that's fine, but it's not actually disambiguating anything." OK, by your narrow definition, this is not actually disambiguating anything, in that there is no confusion what article you want if you say Flemish giant. Note, however, that by a broader definition, quite often that extra word that is "not necessary" does a lot of good in terms of improving precision and reducing ambiguity. Did you look at the railway station example I added? The point is that that minimalist titling that some espouse leaves things looking imprecise, and we have many examples of consensus naming conventions that don't interpret precision and ambiguity in this narrow B2C way. Dicklyon (talk) 03:52, 25 March 2016 (UTC)

Projects are allowed to develop naming conventions. They usually are exceptions to the precision/ambiguity criterion of WP:AT - see WP:USPLACE, WP:Naming conventions (UK Parliament constituencies), etc., referenced at WP:PRECISION. So, yes, consistency, or naturalness or some other consideration can override precision. But it should remain an exception that doesn't swallow the rule. Dohn joe (talk) 04:03, 25 March 2016 (UTC)

I'm pretty sure projects don't change, supercede, or make exceptions to policy and guidelines. And WP:PRECISION isn't overridden by having the article title "unambiguously define the topical scope of the article". People seem to ignore that provision, and treat precision as a negative when they could use a shorter title without a collision. That's the B2C algorithm, and it's nonsense. Dicklyon (talk) 05:03, 25 March 2016 (UTC)

I'd never seen Wikipedia:Naming conventions (UK Parliament constituencies) until today. I can't believe it exists. Curly Turkey 🍁 ¡gobble! 05:09, 25 March 2016 (UTC)

Your singular personal belief is not required to make things exists. The world, and the things in it, exist outside of your consciousness. --Jayron32 05:18, 25 March 2016 (UTC)

And the world outside the Wikipedia:Naming conventions (UK Parliament constituencies) basement has moved strongly against this pointless "disambiguation"—WProjects like WP:CANADA and WP:INDIA dropped this silliness years ago. So, what were you saying about "singular personal beliefs"? Curly Turkey 🍁 ¡gobble! 05:25, 25 March 2016 (UTC)

And yet, it still exists. Notice how you had a feeling or an emotion (you thought it "silly") and nothing changed. The world works like that: reality continues to keep being real despite you having feelings about it. It's odd you haven't learned that. --Jayron32 16:17, 25 March 2016 (UTC)

You don't appear to have a point. Curly Turkey 🍁 ¡gobble! 21:18, 25 March 2016 (UTC)

What Dohn joe is missing is that Algerian Arab was disambiguated to Algerian Arab sheep on the basis of it simply being naturally ambiguous. It only became a disambiguation page later. His 'So in this case, "sheep" serves to disambiguate, while "rabbit" does not' point is completely invalid. He doesn't appear to understand what "ambiguous" and "disambiguate" means. Neither do many of the other correspondents here. Fortunately, RM respondents often do. That's why Argentine Criollo, Welsh Black, British White, Florida White, and many other such names were disambiguated to more WP:PRECISE titles, despite no other article directly vying with them for the shorter ones.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  04:03, 26 March 2016 (UTC)

• No guidance. WP:DAB was created to address a very specific situation – what to do when two or more articles share the same name. Everything else is covered by WP:AT and its spin-offs. For example, I'd consider Flemish Giant to be an inappropriate title (or at least less appropriate than Flemish Giant rabbit) because it fails WP:AT's "precision" criterion ("The title unambiguously identifies the article's subject..."). No extra guidance needs to be added to allow for titles like Flemish Giant rabbit, and any such guidance would be outside the scope of WP:DAB. DoctorKubla (talk) 09:39, 25 March 2016 (UTC)
• Retain the guidance – and this RfC is non-neutral and grossly misleading due to major errors of omission: No policy rationale presented for removal, only false claims that consensus wasn't established. The material describes actual practice at WP:RM for 15 years, and actual requirements of various naming conventions (e.g. WP:USPLACE). Attempts to delete it are based on lack of basic understanding of the word "disambiguation" (it means "to resolve ambiguity"), patently false claims that previous discussion did not happen and that consensus wasn't established, and a minority, extremist view that WP:CONCISE trumps all other article naming criteria in every case, no matter what, despite the clear wording of the WP:AT policy. The RfC falsely paints a picture of a slow editwar. Actual review of the history shows two back-to-back consensus discussions, two different attempts to by parties that the RfC falsely paints as opponents to integrate the material into WP:AT policy itself, normal WP:BRD process and revision, 8 months of acceptance, the two drive-by attempts at deletion predicated on false claims and unawareness of previous discussion, which were reverted by multiple parties. See #Discussion (disambiguation) for details. This RfC, whatever its intent, would reverse much longer-standing portions of multiple stable naming conventions like USPLACE and WP:USSTATION, just for starters, yet none of the affected pages were notified. Three quarters of a year of stability is plenty evidence of consensus, especially after three consensus discussions refined the material to its present state.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:04, 25 March 2016 (UTC)

• Recognize that disambiguation is more than one thing. Keep the guidance, as it deters those who try to use the omission (of recognition of this common practice of making titles non minimally short in order to make them more precise and less ambiguous) to drive toward a precision-is-bad minimality. 2620:0:1000:110A:71BE:75D9:749D:32C9 (talk) 19:42, 25 March 2016 (UTC)

That IP is me. Sorry for forgetting to log in, and expressing myself so poorly. The point is that disambiguation of this "unnecessary" sort is used, widely, in wikipedia, and is even encouraged in various naming guidelines and conventions, for the purpose of supporting the WP:CRITERIA or precision and recognizability. Those who argue against this use of disambiguation seem to want to take a very narrow view of what ambiguty is, and put zero value on precision. This approach is epitomized by the decade-long campaign of B2C for "title stability", described by him at User:Born2cycle#A_goal:_naming_stability_at_Wikipedia, where he espouses moving toward a system of unambiguous rules, essentially removing from editors the discretion to make titles more precise or less ambiguous than the shortest possible title that does not have a name conflict. To support this approach he has spent years rewording the recognizability, precision, naturalness, and consistency criteria to essentially minimize their value, leaving concisenss as the main criterion. I find this approach abhorrent. Dicklyon (talk) 16:44, 26 March 2016 (UTC)

There is ambiguity, and there is ambiguity that is relevant to WP:DISAMBIGUATION. They are not the same. Don't conflate them. The only ambiguity that has ever been relevant to WP:DISAMBIGUATION is when two are more titles on WP share the exact same WP:COMMONNAME. --В²C ☎ 21:33, 27 March 2016 (UTC)

See dictionary material I helpfully provided for you. What you just posted doesn't even parse. Disambiguation is removal of ambiguity. All ambiguity is relevant to disambiguation, and all disambiguation is relevant to ambiguity. Disambiguation doesn't magically refer to "only the ambiguity I want it to mean". You don't get to make up your own version of the language on the fly.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:00, 1 April 2016 (UTC)

• No guidance from disambiguation should be created for article titles generally. If someone is looking for information about the Flemish Goose, which is very large and sometimes referred to as the Flemish Giant, then it is good to have the search box suggesting "Flemish Giant rabbit" as the only possibility before the person clicks and starts reading and is disappointed. Ditto for the Flemish Giant cross-stitch pattern. A recent example of a too-short page title that I came across was Hybrid name, which I moved to Hybrid name (botany) because on the talk page are such comments as "Why is this article written entirely from the point of view of plants, as if hybrid animals don't exist? We need to redress the balance." and the page itself had a tag "The examples and perspective in this article may not include all significant viewpoints. Please improve the article or discuss the issue. (May 2010)". The situation has clearly confused a few readers because although hybrid animals such as Ligers do exist, there is no special way of naming them, whereas for plants there is a detailed set of rules for creating scientific names. Sminthopsis84 (talk) 20:58, 25 March 2016 (UTC)
• Retain guidance as it stands - This isn't even a properly presented RfC. What is the problem with the current guidelines and why does it need to be re-evaluated per WP:PG? All I'm seeing here is WP:JUSTDONTLIKEIT or something for the DRN (which would be rejected). --Iryna Harpy (talk) 21:53, 25 March 2016 (UTC)
• No guidance. I feel that this sort of guidance should be integrated into WP:AT itself, if ever. I've been here on Wikipedia for a long time and I've always understood the WP:DAB guideline to only apply whenever two or more articles have ambiguous titles, and not merely because a non-ambiguous title sounds ambiguous. So such additional guidance that touches singularly on precision should be placed into WP:AT, where a more holistic look at the 5 criteria of good article titles should lead to better titles. Otherwise, the guidance placed on WP:DAB will seek to emphasize precision over the other criteria. —seav (talk) 03:26, 26 March 2016 (UTC)
• Injection of some facts and reliable sources, since at least half the respondents here don't seem to understand what "disambiguate" means. It is not a made-up Wikipedian neologism, for "resolve a title conflict between two articles" (resolving such conflicts is simply the most common use of disambiguation on WP; it has never, in the entire history of the project, been the only one).
  1. Definition of disambiguate at Dictionary.com (Random House Dictionary [US] and Collins English Dictionary [UK]): RH: "to remove the ambiguity from; make unambiguous: In order to disambiguate the sentence 'She lectured on the famous passenger ship,' you'll have to write either 'lectured on board' or 'lectured about.'"; Collins: "to make (an ambiguous expression) unambiguous".[1]
     Definition of ambiguous: RH: "1. open to or having several possible meanings or interpretations; equivocal: an ambiguous answer; 2. Linguistics. (of an expression) exhibiting constructional homonymity; having two or more structural descriptions; 3. of doubtful or uncertain nature; difficult to comprehend, distinguish, or classify: a rock of ambiguous character; 4. lacking clearness or definiteness; obscure; indistinct: an ambiguous shape; an ambiguous future." Collins: "1. lacking clearness or definiteness; obscure; indistinct; 2. difficult to understand or classify; obscure."[2]
  2. Definition of disambiguate at OxfordDictionaries.com [UK & US]: "Remove uncertainty of meaning from (an ambiguous sentence, phrase, or other linguistic unit): 'word senses can be disambiguated by examining the context' ".[3][4]
     Definition of ambiguous: "(Of language) open to more than one interpretation; having a double meaning: 'the question is rather ambiguous', 'ambiguous phrases' ".[5][6]; "Not clear or decided".[7]. Note that the definition some people want to apply here as if it were the only one does not appear to be a language-related one: "Unclear or inexact because a choice between alternatives has not been made: 'this whole society is morally ambiguous', 'the election result was ambiguous' ".[8]
  3. Definition of disambiguate at Dictionary.Cambridge.org [UK & US]: "specialized to show the ​differences between two or more ​meanings ​clearly: Good ​dictionary ​definitions disambiguate between ​similar ​meanings."[9]
     Definition of ambiguous: "having or ​expressing more than one ​possible ​meaning, sometimes ​intentionally: The movie's ending is ambiguous. ... His ​reply to my ​question was ​somewhat ambiguous. The ​wording of the ​agreement is ambiguous. The ​government has been ambiguous on this ​issue."[10] "having more than one possible ​meaning, and therefore likely to cause confusion: Many ​companies are ​appealing against the ​ruling, because the ​wording is ambiguous."[11]
  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)

Per WP:NATURAL policy, the proper titles would use natural disambiguation as first choice. But in both cases ("Harvard Memorial Hall", "Indian National Pension Scheme"), it results in a new ambiguity (which I needn't spell out here). The obvious solution is WP:COMMADIS: "Memorial Hall, Harvard" (adding "University" seems superfluous, per WP:CONCISE), and "National Pension Scheme, India", or WP:DESCRIPTDIS in the latter case, "National Pension Scheme of India". Both "Memorial Hall, Harvard" and "National Pension Scheme of India" actually border on alternative NATURALDIS, and are attested in sources.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:04, 17 May 2016 (UTC)

• Retain the guidance since the lengthy discussion above and below has convinced me that this is useful guidance to editors in encouraging a better and less frustrating experience for our readers. BushelCandle (talk) 06:59, 3 April 2016 (UTC)
• No guidance as I agree wholeheartedly with DoctorKubla. -- Tavix ^(talk) 12:24, 5 April 2016 (UTC)

• Retain the guidance. I am also irked by the Memorial Hall (Harvard University) example provided by EEng and similar ones – articles about obscure things with common-sounding (i.e. wikt:ambiguous) names do benefit from some extra WP:PRECISION. Doing otherwise easily confuses the readers (as the context is often not enough to quickly conclude what the topic is, and matches displayed in the search box do not provide any hint about the topic) and editors (quite easy mislinking) alike. Of course, case-by-case examination is always welcome, but we do not apply WP:CONCISE at all costs. No such user (talk) 15:35, 6 April 2016 (UTC)
  • I, for one, do not call for applying WP:CONCISE at all costs. To the contrary. I call for applying it primarily as a "tie breaker". When considering all other WP:CRITERIA there is no clear answer, then go with the more concise one. It is that simple. But the main point her is that all this is WP:AT consideration; it has nothing to do with WP:DISAMBIGUATION. --В²C ☎ 20:07, 7 April 2016 (UTC)

• Retain the guidance. It's reasonable to note that some titles may be ambiguous or likely to confuse a reader even if they don't exactly match any other titles, and I'm fine with having at least a modicum of text into the guideline to explain this. I understand that some prefer the term "disambiguation" to be defined more narrowly as just the mechanical process of distinguishing between otherwise identical Wikipedia titles, but I don't think that's particularly useful. There can be (and often is) a difference between what's merely technically ambiguous and what's actually ambiguous, and the latter can be a valid consideration when determining the best title for our readers. ╠╣uw [talk] 19:01, 11 April 2016 (UTC)

• Change names The simplest thing to do would be to change the names. — Preceding unsigned comment added by Shinyapple (talk • contribs) 01:22, 30 April 2016 (UTC)

• Retain guidance What useful purpose is served by inherently ambiguous titles, even when this is the sole article? Pincrete (talk) 21:37, 6 May 2016 (UTC)
• Retain Guidance Why would we remove relevant information that helps users avoid pointless move discussions. I have seen time and again pointless move requests to ambiguous titles that fail precision.  InsertCleverPhraseHere  03:23, 15 May 2016 (UTC)

And numerous RMs have closed with the opposite result. Calidum ¤ 03:48, 16 May 2016 (UTC)

Not in the case of naturally ambiguous titles. They get resolved one way or another, and this way is much more common that the deleters here understand or admit. (Often a notably different alternative name is available, but when one is not, all that is left is some form of disambiguation).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:08, 17 May 2016 (UTC)

• Retain guidance (and apply with common sense). There are situations where reduction of ambiguity is desirable even though there may be only one article with the title. This doesn't mean every potential ambiguity must be "pre-disambiguated", but we should not prohibit this. older ≠ wiser 17:11, 17 May 2016 (UTC)
• No guidance; at least, not on connection with disambiguation. If there should be guidance of this sort at WP:AT, that is a different discussion. bd2412 T 17:23, 17 May 2016 (UTC)
  • One that was already had about a year ago, and consensus did not agree to import this wording from the guideline. Deletionists don't get to nuke stable guideline wording they don't like by re-proposing failed merges to policy, then pretending that's an argument against retaining it where it was originally. Could kill any guideline on sight with that tactic. Guidelines are guidelines for a reason, because they are not policy material. A simple observation of fact, that WP disambiguates for more that one reason (though one reason is certainly the most common) is not a policy matter, but a guideline matter. It does not tell us to do or not do anything, it describes actual practice.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  18:15, 17 May 2016 (UTC)
• No guidance: As a user of Wikipedia, even years before I joined, it was clear that the bizarre term "?disambiguate" on Wikipedia meant to figure out the title of the article you were looking for when multiple articles have similar titles. I thought it was some term a bunch of geeks made up, proud of their $10 word a bit like the International Obfuscated C Code Contest. (When I first learned C and heard the term "obfuscated", I was confused, and apparently, that was intentional.) I always assumed there was a better more common sense way to describe how to find the correct title than "disambiguation", but now we just accept it. I read a lot, and I have, never, ever seen the word "disambiguate" used anywhere else, although "obfuscate" sometimes. Good writing should avoid unnecessary $10 words [18]. To find more than one use for this $10 word on Wikipedia is a mistake. The word "disambiguate" needs to be "disambiguated"! --David Tornheim (talk) 12:21, 4 June 2016 (UTC)

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 [19] but retaining the agreed short version from prior discussions [20], which had already been accepted for two months. It remained uncontroverted for 6 more months, clearly long enough for consensus to be established, especially in a much-watchlisted guideline we use every single day.

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

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

• Comments (since there seems to be confusion): Wait! You mean I just don't like it doesn't mean we can change things just because? How about used in conjunction with and while ignoring all rules.

We have many policies and guidelines and a single one can not be used in disregard of others. I was under the impression we can not ignore all rules, if it is against consensus, even if we don't like it, unless we can sneak it in under the radar. FYI -- we should not really (according to policy) attempt to make or change policy by using WP:BRD unless we "ignore" the policy on Proposals and Good practice for proposals. The first states: "Proposals for new guidelines and policies require discussion and a high level of consensus from the entire community for promotion to guideline or policy.". The second: "If consensus for broad community support has not developed after a reasonable time period, the proposal is considered failed. If consensus is neutral or unclear on the issue and unlikely to improve, the proposal has likewise failed.".

Further, the procedural policy explains the process in detail that is located in the second part. A request for comments here is only one part of that process and not a determining factor for an outcome. Some confusion at Wikipedia:How to contribute to Wikipedia guidance#Policy discussions seems to be at odds with policy and may contribute to errors. Policy (Good practice for proposals) states the process for any proposed changes to policy:

1)- The first step is to write the best initial proposal that you can.

2)- Authors can request early-stage feedback at Wikipedia's village pump for idea incubation and from any relevant WikiProjects.

3)- Once it is thought that the initial proposal is well-written, and the issues sufficiently discussed among early participants to create a proposal that has a solid chance of success with the broader community, start an RfC for your policy or guideline proposal in a new section on the talk page, and include the {rfc tag along with a brief, time-stamped explanation of the proposal.

4)- A RfC should typically be announced at this policy page (and/or the proposals page, and other potentially interested groups (WikiProjects).

There appears to be some confusion at Wikipedia:Centralized discussion concerning sequence or location but policy seems clear.

DAB: Does cover the topic question above as well as WP:AT. Although there are editors that seem to prefer parenthetical disambiguation, or unnecessary use of such on article titles (Britannica style), this has not been established by any broad consensus but more just the opposite according to policy natural disambiguation is preferred and parenthetical disambiguation as a last choice. The etymology of "disambiguation" would be "not unclear" which would be "not clarified". An article title should be precise enough to unambiguously define the topical scope of the article, but no more precise than that.. Recognizable, natural, and concise goes along with this. DAB states: "Disambiguation is also sometimes employed if the name is too ambiguous, despite not conflicting with another article (yet),". Consistency also goes along with these and gives more than one reason why we have Flemish Giant rabbit, Continental Giant rabbit, French Lop, Lop rabbit, Angora rabbit, and so forth. Certainly using the more common name according to references. Common sense is also thrown in there somewhere.

Conclusion: We should not attempt to change or change policies or guidelines on a whim or by any local consensus. The process is made somewhat complicated to prevent easy changes. DAB and AT do a fine job. I think if editors disagree then they should probably follow the above procedures. Otr500 (talk) 12:39, 26 March 2016 (UTC)

The portion of WP:DAB that you quote was added a couple of days ago. A clear consensus in support of this recent addition would neatly resolve the difficulty of having an orphaned sentence in the lead that isn't explained in the body of the guideline.--Trystan (talk) 18:50, 27 March 2016 (UTC)

It's also based on material present in the original, longer version. The WP:GAME here is to keep whittling away at the material in hopes that it can be made to seem out-of-place in its context. If context is restored, it's obviously belongs where it is. This was true 8 months ago, when the context material was originally reduced, on the basis (Francis Schonken's objection) that the example article titles were "unstable". This wasn't actually true then, and 8 months have proven conclusively that it's not true now, so the original rationale to decontextualizing the sentence has evaporated. Better yet, later editors like Dick Lyon have pointed out that entire NC guidelines, like USPLACE and USSTATION, rely on the exact same principle and have for years, so the examples Schonken didn't like almost a year ago were could have been replaced at any time anyway. A challenge against this provision now is a challenge against multiple naming conventions that have been stable for years.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:59, 1 April 2016 (UTC)

Request for closure

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

• Shall this long expired RfC ever be closed, or shall it languish here for eternity? RGloucester — ☎ 00:23, 12 May 2016 (UTC)
  • All the above effort should have been put into something that actually matters. 217.44.215.253 (talk) 11:57, 16 May 2016 (UTC)
    • It matters plenty, since dispute keeps erupting about this, on policy and guideline talk pages, and in RMs, and elsewhere. The real time drain is the recurrent disputation, not the attempt to resolve it with an RfC. In the end, this can only reasonably close one way, or be consensus-reviewed without a close (not all RfCs must have formal closure and consensus determination by common sense doesn't require it) in one way: to retain the guidance. Let's review:
      • It's been stable for a year+; the original objections to it were mooted by later tweaks (i.e., objections ceased, and the changes the original objectors insisted on were accepted, resulting in a consensus).
      • We've since learned it agrees with multiple long-term naming conventions that weren't even considered when it was written and which were not taken into account by any objections, then or now.
      • It codifies actual practice that has been ongoing the entire time WP has existed.
      • In just a few topics we’ve bothered looking at, the last two years or so produced somewhere between dozens and a hundred RMs that did exactly what the wording suggested, before and after the wording, and with and without naming conventions behind them. The community gets it, even if some editors do not or will not.
      • The wording was clarified and improved further in response to issues raised by the RfC (though there has been back-and-forth reverting about this [23], [24], [25], followed by excessive rewriting (without discussion or consensus) that has tried to eliminate every trace of the wording at issue, in mid-RfC, as shown in this multi-edit diff; this has been very partially reverted [26] to preserve some hint of the material, pending RfC closure.
      • Nothing at all negative has happened on the basis of this wording despite this RfC languishing unclosed (it has not been over-applied to do stupid things, nor was it applied this way before the RfC, and cases which actually need this sort of disambiguation of naturally ambiguous names have been proceeding as if nothing happened. Or they had been. Now confusion and dispute has arisen in the wake of attempts to delete the material during the RfC; e.g. this other RfC has quite a number of editors in favor of such disambiguation in certain kinds of song-title cases, while others suddenly don't seem to think it is possible/permissible, obviously because of FUD surrounding the WP:DAB wording. [Not all support/oppose at that RfC relates to this matter, however; some of it is about WP:CONSISTENCY vs. WP:CONCISE, etc. But at least half a dozen participants are making arguments clearly rooted in the wording at WP:DAB that some are trying to delete, consensus and process notwithstanding.]
      • The numbers are in favor of retention, though not by landslide, to the extent that is seen as meaningful.
      • The RfC itself is misleadingly and non-neutrally worded (in favor of deletion); the contravenes WP:RFC and requires a closer to account for the bias (or to close the RfC as invalid on its face).
      • Supporters have provided source, policy, and RM precedent backing, while deleters have not. Various opposers to inclusion in the guideline have actually wanted to move it into AT policy (going all the way back to its original inclusion in WP:DAB), but this proposal was already rejected at WT:AT. Re-proposing failed ideas when nothing has changed is a waste of time. And one does not get to delete guideline material by proposing an implausible move-and-merge to policy that is sure to be rejected, then claim that this somehow has something to do with whether it can be deleted from the guideline. By that rationale any guideline could be nuked by proposing a such a doomed move and claiming that the material suddenly had no consensus of any kind.
      • WP:NOT#BUREAUCRACY, WP:EDITING and WP:CONSENSUS are policy (it does not require some local-consensus's permission to codify actual practice in guidelines; this is what guidelines are for, and no one owns them).
      • Finally, the arguments presented here are far stronger for retention than for removal. The latter are primarily predicated on WP:IDONTLIKEIT, factual errors about RM outcomes, confusion about what disambiguation means, and an insistence, with no basis, that the WP:DAB page cannot possibly be about anything but article title collisions even if the word itself has broader meaning.

In short, there really is no case for removal. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 16:42, 17 May 2016 (UTC) [updated 18:19, 17 May 2016 (UTC)]

• So, my first request for closure was more than a month ago...doesn't that seem a bit beyond the pale? Would someone close this thing out, please? RGloucester — ☎ 17:52, 26 May 20(UTC)

RGloucheser, there is nothing to "close". The thread was never actually marked as an RFC, even though people started to !vote as if it was. Just stop responding, and the thread will be moved into the archives like any other old discussion. Blueboar (talk) 18:06, 26 May 2016 (UTC)

Yes, it was an RfC. The RfC tag is automatically removed after 30 days (i.e. ages ago), when RfCs expire and are meant to be closed. Closure is required, or else there is no resolution to the question asked by the RfC. RGloucester — ☎ 18:13, 26 May 2016 (UTC)

Sorry... my mistake. If you are willing to go with a non-admin, I would be willing to formally close. Blueboar (talk) 19:00, 26 May 2016 (UTC)

The "automatic" removal - actually a bot edit - is here, and within seconds it was removed from the RfC listings. There is a request for closure at WP:AN/RFC#Wikipedia:Village pump (policy).23Wikipedia:Disambiguation and inherently ambiguous titles, filed over a month ago. --Redrose64 (talk) 19:05, 26 May 2016 (UTC)

I don't think any WP:AT/WP:MOS regular like Blueboar should close it. Anyone who regularly works on these policypages is apt to have very strong opinions about how they "should" be, when there is nothing to analyze here but the consensus process, disconnected from what the topic is: Wording was introduced; it was discussed; it was modified by those objecting to it; they stopped objecting after modification, resulting in a consensus; it remained stable all year; someone who did not participate in any of these discussions attempted to delete the agreed-upon, stable text without new discussion or even being aware of previous discussion; multiple editors reverted that; that deletion idea has been discussed, and arguments for and against removing or retaining the wording in some form have been aired; which are stronger, from a WP:POLICY, WP:PROCESS, and WP:COMMONSENSE, especially given that the main alternative proposal is "move it into WP:AT", a proposal that was already rejected in the first discussion? The answer is pretty clear, so even if we don't get a formal closure, consensus to keep the wording has not actually changed.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:52, 29 May 2016 (UTC)

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

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.

Some editors have brought up issues with Wikidata in infoboxes being included in this way. Should such inclusions continue to be "opt-out"?

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) UPDATE: Also note this. Curly Turkey 🍁 ¡gobble! 12:05, 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)

I believe that this is an accurate summary of prevailing practice and a natural consequence of the previous RfC. The adopted option 4 reads, '[this option modifies] only a selected field, and only when there is no existing data in that field ... Modification to any Wikidata content in the field could be done either centrally at Wikidata, or by adding information to that field locally, which would override the data from Wikidata'. ('Selected' here means a parameter in the template that has been enabled for use with Wikidata.) Our implementation is - in fact - more conservative, allowing for an empty value to override Wikidata. Izkala (talk) 12:00, 17 May 2016 (UTC)

!Votes (Wikidata)

• Switch to opt-in, per below. Curly Turkey 🍁 ¡gobble! 01:05, 15 May 2016 (UTC) Opt-in by default, with opt-out to be determined by consensus for individual infoboxes. When I opened this RfC, it was because Izno told me at Template talk:Infobox book that opt-out that the result of the RfC was "an 'opt-out' mechanism, not an 'opt-in' mechanism" across Wikipedia, and therefore undiscussed changes at Template:Infobox book was following the RfC. It appears that is not true—although this should be made explicit somewhere to avoid these undiscussed changes in the future. Curly Turkey 🍁 ¡gobble! 22:49, 17 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 (i.e. allow for both opt-in and opt-out). 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-outAllow for both opt-in and 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 Neither 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)
  • Changed vote to better reflect my position. Same rationale, in line with several other recent comments like RexxS and Happy5214. -- ferret (talk) 22:33, 17 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)
  • @Kusma and SlimVirgin: I keep needing to repeat myself on this: A preference to watch Wikidata edits from your local watchlist already exists (though it currently lacks integration with the "enhanced" watchlist, and there are some other bugs and kinks that need to be worked out). Please do not misinform other users, and please review your watchlist preferences to set the preference accordingly. --Izno (talk) 14:05, 17 May 2016 (UTC)
    • When I last tried, enabling that option overwhelmed my watchlist with junk, making the watchlist useless. If anyone has Wikidata enabled on a watchlist with over 1000 articles, they might like to say how it works now. Johnuniq (talk) 23:21, 17 May 2016 (UTC)
      • For what it's worth, I have it enabled with 738 articles currently with no issue (in my opinion). -- ferret (talk) 23:28, 17 May 2016 (UTC)
  • Separately, @SlimVirgin: regarding point e, you can review when that change was introduced at Wikidata, so arguing that MediaWiki templates don't recall the correct version of things relative to the historical page you are reviewing is something of a strawman. --Izno (talk) 14:05, 17 May 2016 (UTC)
    • An example was given of the inappropriate words "autobiographical novel" appearing in an article. The first step in tracking down how that happened is to examine the article history. A good procedure is to look at some old revisions, but that was useless because the inappropriate words magically appeared in all old revisions. What is the easy procedure for an editor to find where those words came from? Johnuniq (talk) 23:27, 17 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)
  • Striking my !vote. Per RexxS below, there's no need to force the same rule on each and every infobox. Though subtly and not-so-subtly incorrect information might sneak its way in from time to time, and though the tooling is lagging far behind, both of these issues can be circumvented through careful planning or may be reasonably deemed to be outweighed by the benefits in some circumstances. Izkala (talk) 13:24, 17 May 2016 (UTC)
• Opt-in per SarahSV. Mike Christie (talk - contribs - library) 19:22, 16 May 2016 (UTC) Striking for now. I now think I don't understand the issues well enough for me to !vote usefully. I'll be back if/when I get to that point. Mike Christie (talk - contribs - library) 18:31, 18 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.<brCrowdsourced 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)

"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." - Really? Why? One can more easily argue just the opposite. Johnbod (talk) 18:25, 18 May 2016 (UTC)

I see several important reasons why wikidata-driven infoboxes are likely to end up being more stable and contain higher verification standards. Its easier for people to get the data right because editing by filling in values in a form is much easier than editing data inside a wikitext template. Its easier for bots to get it right for essentially the same reason. Representing data in a database rather than mangling it into wikitext will lead to fewer errors and I would argue, eventually more editors. Because it is much easier to maintain a database as a database, authorities on specific domains should be more likely to help keep data up to date - particularly via automated methods. The other aspect here is the ability to add computable reference statements to support wikidata claims that might appear in infoboxes. A lot of anti-data people complain about wikidata having many un-referenced claims. Rather than complain, how about (a) adding references and thus solving the problem and (b) helping to code templates that make use of references in deciding whether data should be rendered or not. Because the data is in a computationally amenable form, the Lua code driving the templates can take advantage of this information and perform quality control when an article is rendered. For example, a template author could decide to only show content from wikidata that had references into sources that they judged to be high quality. This quality control would be over and above that performed by other bots that focus on patrolling and verifying the content in wikidata itself. --Benjamin Good (talk) 16:29, 20 May 2016 (UTC)

There is a bright future promised in the comment above, but we have to think what we want to do in the immediate future. At the moment, most of the data in Wikidata is unreferenced, and I haven't seen any templates that make any attempt to attempt to "add computable reference statements to support wikidata claims" (although RexxS has made good progress on modules to display whether wikidata claims have references). At the moment, Wikidata cannot be regarded as a reliable source (but there might be specific areas that could be).

I dislike the fact that editors who have concerns about "wikidata having many un-referenced claims" are being lumped together in a Luddite anti-data group. I am very much pro-data, and can see massive potential in Wikidata for sharing information between different wikipedias, improving quality, and making aspects of creating articles easier - but the key word is "potential", and quite frankly, as Wikidata stands today, I don't think it is ready for mass updating of infoboxes (but there are some areas where "obvious" data might usefully be included).

We should also not forget that infoboxes are intended to be a summary of what is in the article (and that should be supported by a reference). If something is not in the article, then it needs a specific reference, or the article should be updated (with an appropriate reference).

And by the way, I've just started to have a go with Wikidata, adding some items (with references). Using the current forms is fairly painful compared with entering wikitext... I will persist though and explore bots etc... Robevans123 (talk) 18:16, 20 May 2016 (UTC)

@Robevans123: I apologize for the luddite implication. Its easy to get frustrated and start creating "us" versus "them" when anyone that is bothering to spend their spare time chatting here is very much on the same side. I guess I'm a little confused why people here seem to think that data originating in a wikidata statement without a reference is, by default, less reliable than data sitting in Wikitext infobox also without a reference (where it was likely pulled from in the first place). But, that is beside the point. My motivation is to get more knowledge out to more people - both as text and as computationally re-usable claims in a database that could support WIkipedia and many other applications with massive social benefit. The claims used in wikidata are much more valuable when they have references. Adding references to the claims that would appear in infoboxes is a very achievable goal and one that it seems would solve many perceived and real problems with wikidata in all the contexts it is and will eventually be used. Lets figure that process out and realize that bright future, it could be much closer at hand than you might think. --Benjamin Good (talk) 22:12, 22 May 2016 (UTC)

@Benjamin Good: No worries! This whole RFC is very complicated now - different threads in different sections - I've said elsewhere that the manual data in infoboxes is not as well supported by references as it should be (and by implication that this is not "a good thing"). Since the extraction of data from infoboxes into Wikidata didn't include the references (and that would be quite difficult to do - you'd need to work out which bit of text in the article supported the infobox data, and possibly, if a sentence or paragraph has two or more references, which reference to extract...), then we're not really sure how good the extracted data is.

Of course, a lot of Wikidata is from infoboxes from this Wikipedia, and so is not that likely to be re-imported as it's already there. However, wikidata from other language wikipedias is likely to be imported, and with that, again we're not really sure how good the data is.

I'm intrigued by the possibility of an achievable goal of adding references to claims. I'll stick my hand up for helping with that process! I could see that it might well be possible to create some sort of tag (with no visible output) to link an item in an infobox to the reference that applies, but that would be human-intensive (unless you've got a really smart bot?). Regards Robevans123 (talk) 23:53, 22 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)
• Continue opt-out and increase use of Wikidata material as much as possible, per RexxS, Blue Raspberry and other clueful contributors. The WP:OWNership and "not invented here" displayed in this debate by those opposing such progress is lamentable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:13, 17 May 2016 (UTC)
  • Insulting half the editors voting here by claiming they are not 'clueful' and accusing them of ownership and NIH issues is neither constructive, civil, and is a personal attack. Address the arguments rather than attacking the editors. Given your previous repeated sanctions regarding infoboxs, you are more than aware of the requirements here. Only in death does duty end (talk) 13:24, 17 May 2016 (UTC)
    • I was thinking it was only a minority, but really: half of them? It's worse than I thought! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:23, 17 May 2016 (UTC)
• Opt-in – I encourage everyone commenting here to read this Signpost article. The key sentences are these two: "Half of all statements in Wikidata are completely unreferenced. Close to a third of all statements in Wikidata are only referenced to a Wikipedia." Once you read that, it's clear how problems like Sarah's pop up. Sorry Andy, but whether we invented it or not isn't relevant in my mind. The concept of Wikidata is noble and I'm rooting for the site's success, but my interest here is in making sure that the English Wikipedia isn't disrupted by the addition of unsourced/false information that we won't be able to track unless we commit ourselves to being active on another site. I feel like this site is being pushed on us a few years before being "ready for prime time", as it were. At a minimum, I encourage supporters of opt-out to consider a "wikidata=no" parameter, as discussed above, to make opting out easier. Giants2008 (Talk) 13:22, 17 May 2016 (UTC)
  • See below response to Kusma, you can watch for Wikidata changes on enwiki without visiting Wikidata. -- ferret (talk) 14:11, 17 May 2016 (UTC)
  • Bear in mind that the Signpost piece is a single editor's viewpoint, no more authoritative than any essay or talk page comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:23, 17 May 2016 (UTC)
• Continue opt out but try to find solutions for the problems explained by Sarah. For example, can we make any template that relies on Wikidata visibly state that it relies on Wikidata, at least until we are all used to it. Or make a preference "automatically watch Wikidata items for articles I watch". —Kusma (t·c) 13:27, 17 May 2016 (UTC)
  • There is, see your watchlist preferences for "Show Wikidata edits in your watchlist". If an article on your watchlist has its corresponding Wikidata updated, it will appear in your enwiki watchlist. -- ferret (talk) 14:11, 17 May 2016 (UTC)
    • ferret: That works only if the data is new (and editors happen to know there's such a box to check and don't mind having their watchlists flooded with Wikidata changes). If a change is made to the Infobox to add another field for importation from Wikidata, and the data's in Wikidata, then it won't show up on people's watchlists. Curly Turkey 🍁 ¡gobble! 14:15, 17 May 2016 (UTC)
    • Thank you. Too bad it doesn't work with "enhanced recent changes". —Kusma (t·c) 14:21, 17 May 2016 (UTC)
• Continue opt-out, or it's kind of pointless. The Night (book) case is a trivial error, and there are solutions for this (e.g. including the parameter, with an HTML comment that it's blank on purpose, in this case because the sources conflict). One problem cropping up, that people unnecessarily wrung their hands off about is not a good argument against stymying the rollout of major functionality. Yes, there will be kinks, as there always is when we do something new, and we always work them out. Business as usual.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:03, 17 May 2016 (UTC)
• Leave it up to editors to decide With Rexx on this one. We do not need all infoboxes to act the same. Different boxes may benefit from different functionality. Doc James (talk · contribs · email) 16:28, 17 May 2016 (UTC)
• Opt-in: per WP:V. Ed ^{[talk] [majestic titan]} 18:34, 17 May 2016 (UTC)

I don't follow — how? Carl Fredik 💌 📧 19:14, 17 May 2016 (UTC)

@The ed17: Do we need a citation to prove that California is a state in the United States? This is where a blanket "per WP:V" doesn't really work. --Rschen7754 00:50, 18 May 2016 (UTC)

If you want to talk geographically, yes. Not for California specifically, obviously, but Crimea? South Ossetia? Etc. Ed ^{[talk] [majestic titan]} 03:12, 18 May 2016 (UTC)

Or that File:California State Route 78.svg is a map of California State Route 78? Which is a particularly good use case, as it allows for maps to easily be shared across the different languages of Template:Infobox road. Just because there are some problematic cases doesn't mean we have to prohibit the uses that are actually working. --Rschen7754 05:35, 18 May 2016 (UTC)

Thank you, that's a great argument for opt-in. ;-) Ed ^{[talk] [majestic titan]} 18:19, 18 May 2016 (UTC)

How so? When opt-out was turned on for Infobox road, we immediately gained several road maps that enwiki did not have, mainly on roads in countries where English is not the first language. This is an easy way to counteract problems with systemic bias. And you want to prohibit this? --Rschen7754 00:17, 19 May 2016 (UTC)

"Opt-in" doesn't "prohibit" anything. Curly Turkey 🍁 ¡gobble! 00:23, 19 May 2016 (UTC)

It would prohibit the automatic inclusion of such maps, which is the real benefit here. --Rschen7754 00:44, 19 May 2016 (UTC)

It's a perfect argument for opt-in: "Just because there are some problematic cases doesn't mean we have to prohibit the uses that are actually working." There are problematic cases, so we'll opt-in for the uses that are actually working. Ed ^{[talk] [majestic titan]} 17:43, 19 May 2016 (UTC)

No, in fact it's not. Also it entirely defeats the purpose. Having it opt-in by default is the same as saying we shouldn't use it. There is no benefit to be gained if the opt-in needs to be manually performed, then it is not only useless, but a waste of time and money. Carl Fredik 💌 📧 17:48, 19 May 2016 (UTC)

I think you're referring to opt-in by template. However, this proposal as written is for opt-in by article, which would prohibit the uses that are actually working. --Rschen7754 18:31, 19 May 2016 (UTC)

I think also one of the issues here is that we aren't really clear about what Wikidata should be used for — some properties are simply poorly situated for relying on Wikidata, they shouldn't be included in templates/infoboxes at all, genre comes to mind. Carl Fredik 💌 📧 19:42, 19 May 2016 (UTC) 

• Neither - We don't need a project-wide policy on this. Individual WikiProjects can and should establish local consensus for their own infoboxes. Imposing so-called "opt-in" or "opt-out" mandates on all infoboxes does a disservice to Wikipedia. -happy5214 22:30, 17 May 2016 (UTC)
• Continue opt-out per BoBoMisiu: centralization and importation form almost the entire benefit of Wikidata, and it would be incredibly short-sighted to undermine that. Whatever issues arise with verification can be addressed narrowly as they arise, and will largely be obviated as the editor base becomes more familiar with the idea that factual statements are increasingly centralized. Already, users can opt for their watched Wikidata pages to appear on their Wikipedia watchlist; I think that under-recognized capability has a huge impact on the rationales for "opt-in" given here. —swpb^T 13:30, 18 May 2016 (UTC)
• Opt-in per SV and others. Johnbod (talk) 18:25, 18 May 2016 (UTC)
• Opt-in per the above discussion. Carrite (talk) 18:46, 18 May 2016 (UTC)
• Opt-in by default. I saw the discussion at Night (book) when it occurred and it concerned me. The issue is this: a Holocaust survivor writes an important and notable book that can't be identified as a specific genre because of its content and the author's intentions. That the genre was left blank in the infobox and then later the field filled in with an incorrect genre might seem trivial, but it's not trivial, because in this case it brings into question whether the author is writing a fictional account of a fictional event (the Holocaust) or not. This is not an issue of ownership but rather an issue of good stewardship of our content, and unless there's an easy way to see that the change was made (yes, there's the watchlist button, but what if someone isn't logging in every day?), then The ed17's comment is correct. We need to be certain elements in infoboxes are verified and that's difficult if the changes are being made remotely. Victoria (tk) 20:02, 18 May 2016 (UTC)
• Opt-out In the rare cases where we shouldn't have info (like the genre of Night), we should have to make it clear we don't want the info, rather than having it left out when it's available automatically. Jackmcbarn (talk) 18:36, 19 May 2016 (UTC)
• Opt-out, however I am sympathetic to the arguments of Sarah and others. Perhaps GA's and FA's should be opt-in by default, because we can assume that they are sufficiently maintained. however, especially on less-edited articles, wikidata updates in a clear net positive for the wiki as a whole. If technically feasible, wikidata updates should be noted in the page histories of the affected pages. Tazerdadog (talk) 22:50, 19 May 2016 (UTC)
• Opt-in per SV, Curly and others. Resolute 23:06, 19 May 2016 (UTC)
• Continue opt-out per BoBoMisiu, although I read Sarah's argument about Night. I agree with others that making Wikidata opt-out partially defeats the purpose of including Wikidata in the first place. APerson (talk!) 00:54, 20 May 2016 (UTC)
• Continue opt-out --Nouill (talk) 06:24, 21 May 2016 (UTC)
• Opt-out, with a couple of caveats. I would like to see the option of having an infobox include Wikidata values for parameters by default, but only if they are supported by a reference at the Wikidata end. Unreferenced data from Wikidata would not appear in the infobox. That would have a couple of benefits: it would prevent a huge initial flood of uncited (and possibly incorrect) data being added to infoboxes across the wiki; and it would lead in a natural way to an effort to improve referencing on Wikidata, rather than focusing on simply loading it up with more data. This wouldn't prevent all instances of incorrect data appearing suddenly in an infobox with no notice to the article editors, but it would surely eliminate most cases. To SarahSV's comment that she couldn't see how to fix the problem I would say that I sympathize, but that that's a one-time technical problem for each editor -- we all had to learn how to italicize an article title or indent a blockquote for the first time, and once we've learnt it it's part of our toolbox. This seems the same to me. If it turns out not to be technically possible to limit the use of Wikidata in parameters to ones supported by references, then I would still support opt-out. I have been mostly ignoring Wikidata for the last couple of years, and finally learned a little more about it this week, prompted by this RfC (and thank you, Izno, for answering my questions about it) and I can see why some people are arguing that anything but opt-out makes a mockery of the idea of Wikidata. That doesn't eliminate the problems it causes for content editors, as described by the opt-in supporters above, but I think we're going to be obliged to figure out how to deal with those problems, and we might as well start now. Mike Christie (talk - contribs - library) 10:48, 21 May 2016 (UTC)
• Opt-in, per Giants2008 and Sarah, due to systemic Wikidata verifiability issues. Regards, James (^talk/_contribs) 22:15, 23 May 2016 (UTC)
• Opt-in by default per all of Sarah's and Giants2008's arguments which are also mine. A box's parameters are often an editorial decision, both what to put in the parameters and what parameters to use. Some parameters are excluded because the "factoid" is cluttering trivia or not as straightforward as it seems and is better explained in context to avoid misleading the reader. Even when including data in a box, editors (you know, those humans who actually write Wikipedia) often have to make an editorial decision on what is the best available source to go with when different sources disagree. More importantly, there is a lot of incorrect/dubious information on Wikidata and it's sometimes buggy, and no, it is not easier to edit than the standard manual infobox in Wikitext. I tried to correct information on Wikidata Q3107911 for Giulietta Pezzi. I clicked on the sidebar link from the English Wikipedia and the whole Wikidata page (apart from the statements, I think), the directions, help links etc. were all in... er... Bengali. I see that was eventually fixed, but it is not straightforward to edit at all, even when it is in the correct language. At the very least make it incredibly easy to opt out. By the way, I have over 4000 articles on my watchlist of which well over 1000 are important to watch for changes. So no, I am not going to add Wikidata changes to my watchlist. Voceditenore (talk) 09:49, 24 May 2016 (UTC)
• Opt-in at least on a per infobox level, with clear instructions at the infobox template for how to over ride it on a per article basis. Folks representing WIkiData in this discussion are pretty much doing and saying exactly the kinds of things that only deepen the concerns of editors concerned about verification and manipulation, which is unfortunate. In any case at this point I believe that entry of WikiData needs to be carefully controlled. It is potentially a great tool but until more of an effort is made to a) show that WikiData is well-curated and b) that an opt-out approach really will result in a big net win over the inevitable downsides, it should be opt-in. Jytdog (talk) 21:23, 24 May 2016 (UTC)
• Opt-in: let the editor decide, as is always my position on these forced intrusions. Wikidata and infobxes can be two large allergies to me (sigh...) Fylbecatulous talk 13:31, 25 May 2016 (UTC)
• Opt-in, but with the intent of changing this down the road. The ability to use WikiData in infoboxes is a powerful tool, but one few people on Wikipedia understand how to use. SlimVirgin's example above illustrates that: SV is a veteran editor, & when someone like SV can't figure out how a feature of Wikimedia works in a reasonable fashion, then how will the newbie editor for whom VisualEditor was targeted? Making it an opt-out -- without any documentation or explanation what will happen -- will not only frustrate veteran editors, it will discourage the newbies & make the experience worse for everyone. (And before someone says that they can modify the infobox template to provide this documentation, may I remind everyone that templates are still a ramshackle mess, which the PTB still haven't managed to tame. Many are not only undocumented, but I doubt anyone even has a handle on how many there are. I've been editing Wikipedia for longer than most of you, & I still follow the instructions slavishly when I add images to an article. Templates are that messed up.) But to repeat myself, WikiData has the potential to be a powerful tool. If its potential & use is introduced properly I can see us all in a few years wondering how we managed without it. What is needed is for its advocates to figure out a way to introduce them to the rest of the community so that we can understand how to implement its power -- not flip a switch & wish us luck. And setting this to "opt-out" is flipping a switch & watching us learn the hard way what "rm -rf *" does to a computer running Linux. -- llywrch (talk) 22:27, 25 May 2016 (UTC)
• Neither this should rely on local consensus. The infobox editors and people close to the field know what is likely to be on wikidata and what's useful to include by default. My second preference is keep opt-out for numerous reasons above, but mostly that turning it to opt-in seems like it will make the previous consensus moot. If I have to figure out what's on wikidata and put the info in, why not just copy and paste the data already there? If we're going to use wikidata, we might as well use wikidata. Wugapodes [t^hɔk] [kantʃɻɪbz] 15:29, 1 June 2016 (UTC)
• Continue Opt-out practice - The whole point of wikidata is to improve articles across all languages in this manner. Now, I'd also like to comment on people's !votes for "allow the editors to decide"... this already appears to be the case. Wikidata is only going to be automatically entered into certain templates, not every template that exists, and so editors can clearly decide whether or not wikidata should be used for any given template. I see these !votes as moot, unless you had another meaning? Fieari (talk) 03:55, 2 June 2016 (UTC)
  • @Fieari: Such !votes (and "neither" and "both" !votes) are about not forcing there to be a single way Wikidata can be used across all infobox templates – i.e. allowing individual templates, based on local consensus, to either (a) use Wikidata through an opt-in mechanism, (b) use Wikidata through an opt-out mechanism, or (c) not use Wikidata at all. As opposed to an "opt-in" or "opt-out" !vote, which would allow only (a)&(c) or (b)&(c). Also pinging @RexxS and Doc James: who !voted "Leave it up to editors to decide" - Evad37 [talk] 13:03, 2 June 2016 (UTC)

• Opt-in by default, on a per-template basis. By this I mean that new and existing templates should not show any field from Wikidata that the template creators haven't explicitly given permission to appear on the article. I sympathize with the people who say not showing Wikidata's content by default defeats its point, and I normally would side with opt-out for that reason; but I think that Wikidata is simply not ready for such large-scale adoption, for all the reasons already stated by others, mainly that most content is unreferenced, and that even if all Wikidata was perfect, not all Wikidata fields should be shown at infoboxes anyway. Both are powerful arguments for hiding data by default and show it only after its explicit approval (either at each article or for a full template that allows it).

We need a slow and steady approach to deployment, rather than a "dump everything we got and we'll figure out how to fix it" one. When the WMF tried to force upon us the adoption of much simpler tools, the backlash was huge; why should we treat Wikidata any smoother?

We're talking about a tool that most of us don't know how to use, resembles anything like mediawiki, and which can silently push unreferenced content within articles that might not even be watchlisted by anyone. And frankly, the tool seems too immature to be comfortable for everyday use and massive adoption; every time I've tried to accomplish anything with it, trivial or not, it has been a pain in the ass. So please let's take a more conservative approach and enable it for smaller data sizes at a time.

WP:BLP alone would be a good reason to veto the opt-out behavior; I add to this that the WP:BURDEN of including content in articles falls onto those who want to include it, and there are good arguments challenging the verifiability of most content in Wikidata. I could agree to be more lenient with Wikidata content that can be shown to be referenced; I think the best way to allow it would be with some kind of "when_referenced=param1,param2..." parameter in templates that works like "fetch content from these fields for articles where its data has references, and hide it when it doesn't". I think this would grant maximum flexibility as RexxS suggested, without compromising the core WP:V policy. And incidentally, it would encourage Wikidata users to source as much data as possible, since unreferenced data would be invisible for all purposes (as it should be). Diego (talk) 10:21, 6 June 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)

      • @Mike Christie: I don't doSubt that there are numerous occasions where an editor has deliberately chosen to leave out an infobox parameter. I want to know if this happens most of the time, so that it makes sense for us to treat by default an omitted parameter as one that has been intentionally suppressed. I simply don't believe that is the case. If you are watching an existing article with a Wikidata-enabled infobox, then it makes sense to untick the "hide Wikidata" box in your watchlist. Any changes to that article's statements on Wikidata will then show in your watchlist. Those changes are much less frequent than changes on Wikipedia, and are clearly marked with a D. --RexxS (talk) 13:27, 17 May 2016 (UTC)*

        I've unhidden the Wikidata changes on my watchlist and will try to get a little more familiar with the way it works; if what you're saying turns out to be correct I may change my !vote, though I think somewhere above someone said that even unhiding Wikidata changes does not always show you a change that can affect an article on your watchlist. Incidentally, just as supporting evidence for my comment above, see this, from a couple of minutes ago. Mike Christie (talk - contribs - library) 17:42, 17 May 2016 (UTC)

        • Mike: In the context of this RfC, the problem may arise if a normal infobox is changed (I'd say upgraded) to a Wikidata-enabled infobox. At that point, the display in each article using the infobox has the potential to draw in additional information from Wikidata without that additional information showing on the watchlists containing those articles (subsequently, any changes to Wikidata will show on watchlists as D and will be spotted). The problem can only happen if the infobox implements a scheme where it fetches Wikidata for fields that are not already filled-in an article - the so-called "opt-out" scheme. Most of the time it is likely to be something obscure like an OCLC number that nobody will worry about, but Sarah gives an example of where she had deliberately omitted the genre field as problematic, but the Wikidata-enabled infobox re-inserted it without warning. It's a genuine concern, but banning 'opt-out' schemes wholescale in response is using a sledgehammer on a walnut. Infobox template editors will need to implement fetching Wikidata values carefully when they upgrade infoboxes. Where the number of transclusions is small, it should be sufficient to monitor the effect on the affected articles, so using an 'opt-out' template should be manageable. Where the number of transclusions is larger, I'd recommend using a more flexible implementation, for example like the demo at Template:Infobox book/Wikidata/Sandbox, which only fetches Wikidata when that is specifically enabled on an article-by-article basis by adding a |fetchwikidata= parameter. Since that also allows fetching Wikidata on a field-by-field basis, if required, it should enable editors to make use of it in their articles in the manner they choose. The bonus is that it can also suppress any field(s) with a |suppressfields=, so Sarah could explicitly ensure that 'genre' was never displayed in Night (book) by adding |suppressfields=genre. Sorry to be so lengthy, but you raise important issues that need consideration. --RexxS (talk) 18:32, 17 May 2016 (UTC)
          • RexxS, what happened at Night illustrates the problem with the current position. First the generic infobox was replaced with Infobox Book by Frietjes and Bgwhite over my objections. [27][28] Then Freitjes changed Infobox Book, without discussion, so that it fetched data from Wikidata. [29] In the meantime a Wikidata bot had fetched the genre from the Italian Wikipedia, [30][31] which calls Night a novel. (This is odd because the Italian Wikipedia is a translation of the article I wrote for the English Wikipedia, which explains that scholars can't decide on the genre and that Wiesel insists it isn't a novel.)
            So at each point of this process, people not familiar with the issues were deciding them. Everything that keeps Wikipedia safe – the watchlists, the featured-article process, the concept of stewardship, the ability to track changes by studying the history of articles – was bypassed. SarahSV ^(talk) 03:11, 18 May 2016 (UTC)
            • Yes, Sarah, I do understand the problems you encountered and I sympathise. What if we were to make available a scheme where generic infoboxes could be replaced with wikidata-enabled ones, but they would not fetch anything from Wikidata unless an extra parameter like |fetchwikidata=list; of; fields; to; fetch were added to each article to enable it? And if we gave editors the ability at each article to suppress one or more problematic fields in all circumstances by adding a parameter like |suppressfields=genre, so that they would never display? Do you think that would give you sufficient control at the article level to be able to steward the articles in the way you are comfortable with? If not, what else might you need to do that? I'm happy to try to find solutions if you can give me specifics. Cheers --RexxS (talk) 14:00, 18 May 2016 (UTC)
              • This looks like an eminently sensible and useful proposal. It still doesn't resolve the questions I raised below concerning how the data being imported from Wikidata is backed up by a reference from a reliable source. Is it possible to include a comment after the imported data giving the reference for that data? I took a look at the wikidata item for the Large Hadron Collider and found a number that were unsupported by any reference, a few that were imported from other (and English) Wikipedias (possible danger of circular references here), and one (discovery) supported by a link to the CERN website. If this was included in the comment, then it would be easy to check the source, and relatively easy to add a reference, and possibly include the data within the article. Robevans123 (talk) 18:05, 18 May 2016 (UTC)
                • @Robevans123: Well, the information we get out of Wikidata is only as good as the information that's put into it, and there are about 15,000,000 items there now, most of them imported by bots from infoboxes on the various Wikipedias. Of course, infoboxes are notorious for not displaying references (it's only a summary of the already-referenced article, right?), but it does leave a huge number of statements on Wikidata unreferenced. If I were to write a demo function that fetched any references, if present, and put them inside an html comment after whatever value is retrieved from Wikidata, do you think it would be used to help populate the missing references, or just as a blunt tool to bludgeon folks out of using Wikidata at all? --RexxS (talk) 18:46, 18 May 2016 (UTC)
                  • @RexxS: Well, in suggesting it I had hoped that it would be to help populate the missing references, but I can see that it could/would be used as a bludgeon. But then that might be justified... In my (limited) experience of actually checking data in infoboxes when I've expanded articles (often using {{infobox locomotive}}) I would say that ~5% are wrong, and often that more than 50% are not supported by anything in the text or referenced directly. And I've come across some that were wrong and claimed to be supported by a reference that did not have that amount of detail...

So, there is a problem with data in infoboxes. Do we then ignore the problem and decide to make it even worse? Or do we try and fix it? BTW while I was still a bit of a newbie I added refs to each parameter, but it was suggested that a few refs might be ok, but generally it would be better to have text in the article as the purpose of an infobox is primarily to be a summary of the article. Since then, I've only added parameters to an infobox if the info is in the article.

Just had a go at adding a date of death to Charles Spagnoletti on Wikidata. It's a bit long winded - would be nice to be able to easily copy a ref and re-use it, eg for date of birth...

As things stand if anyone wants "to bludgeon folks out of using Wikidata at all", then they can remove anything from an infobox that comes from Wikidata on the basis that it is unsourced... Robevans123 (talk) 20:14, 18 May 2016 (UTC)

If anybody wants to make a start on improving referencing at Wikidata, I've made a first draft of a tool you can paste and preview into an article that will show you which Wikidata claims are referenced and to what. It's at Module:Sandbox/RexxS/WdRefs. Let me know if you find any bugs or want any improvements. --RexxS (talk) 16:02, 19 May 2016 (UTC)

RexxS, thank you for your suggestions. The problem with |suppressfields=genre is that we would need to add it for all the missing fields; otherwise we're leaving open that a Wikidata bot might grab something wrong from another wiki. Another problem is that a small group tries to force these issues, which is why Night happened, so they would go around removing |suppressfields=. I would rather see separate Wikidata-enabled boxes, then editors can use them if they choose to, along with a "first major contributor" preference in case of dispute. SarahSV ^(talk) 15:16, 20 May 2016 (UTC)

Sarah, You would only need to add |suppressfields=genre; date_of_pub; isbn to suppress three fields and you'd only have to do it once. Surely that conveys your intention better than the present situation where you have no means other than an html comment to inform other editors that they should not be adding those fields manually? If you have a small group going around trying to push the 'genre' parameter, then they will add it, whether it comes from Wikidata or is added manually. If we have a separate Wikidata-enabled box, you'll simply move the locus of the dispute to an edit war over which box to use. That is principally a behavioural issue and needs dispute resolution in any case. It is very harsh to preclude Wikidata awareness to try to circumvent a problem not actually caused by using Wikidata. In addition, I'd strongly recommend against arguing for any "first major contributor" preference. That was only ever meant as a tie-breaker in WP:ENGVAR to decide between two equally-valued options in the absence of any clear deciding factors. The use of that principle outside of such circumstances simply stifles innovation and improvement of the encyclopedia. I've seen it used as a justification for not upgrading bare urls to {{cite web}} on the grounds that the original author used bare urls, despite the clear superiority of the template over the raw link. No, it's far better in the case of dispute to have the debate and decide whether or not an article should be allowed to fetch information from Wikidata by examining the pros and cons, rather than having "it didn't start that way" as a trump card over all other argument. --RexxS (talk) 16:07, 20 May 2016 (UTC)

You would only need to add ...—you can only add them if you know they exist. If someone adds a new parameter to a box used in 37,000 articles, how do you ensure that the editors of all 37,000 articles know that this new parameter has been added so they can judge whether it should be excluded? Someone could add |num_of_chapters=, |page_orientation=, |page_dimensions=, |binding= ... Curly Turkey 🍁 ¡gobble! 21:37, 20 May 2016 (UTC)

You misunderstand. I was suggesting a solution for Sarah's problem, which happens whether the information comes from Wikidata or through a manual addition. Adding a known field to the |suppressfields= blacklist is the way to make sure that a field is never displayed, no matter where it comes from. If you simply want to make sure that only the fields you have audited can be fetched from Wikidata then you explicitly name them in the |fetchwikidata= whitelist in your favourite article. If a new field is added to the infobox without you knowing, it still can't show up in your article until its name is added to the whitelist in the article. And if somebody alters the article's whitelist, you'll see that on your watchlist of course. --RexxS (talk) 22:20, 20 May 2016 (UTC)

• This entire RfC is based on the flawed premise that we have to have a rule forbidding an infobox to populate an infobox from Wikidata in a particular way. This is incorrectly presented as a binary decision and the opening statement is clearly not neutral. It has become obvious that Curley Turkey wants to force his preference for what he calls 'opt-in' on the community. His 22 comments to date show no inclination to listen to the opinions of other editors - the whole purpose of an RfC - but demonstrate a singular desire to push his POV. The falsity of his opening statement can clearly be seen by looking at Template:Infobox book/Wikidata/Sandbox, a demo infobox I knocked up yesterday evening in response to concerns expressed at Template talk:Infobox book #Wikidata. It is perfectly possible to arrange for any Wikidata-enabled infobox to choose which fields are fetched from Wikidata, or which to suppress, or which will use a local parameter value - and to do that at the individual article level. Nobody needs to be forced to implement any given infobox in any particular way, and one has to be suspicious of the motives of anyone who is trying so hard to convince the community otherwise. --RexxS (talk) 13:11, 17 May 2016 (UTC)

• When I initially read the first paragraphs of this RfC, my kneejerk reaction was to support the author, until I saw Rexx's comment, suggesting the RfC presentation was non-neutral. As editor who has never looked too deeply into the drama around infoboxes, but is aware of the deceptive tricks of WifiOne and what happened at BP to hide bias and COI, I am suspcious of the ability of editors to change any content without notice on the watchlist. I imagine other editors will have similar kneejerk reaction. So, my inclination was and is to vote Opt-In. However, Rexx makes some strong arguments against a one-size-fits-all approach not found in the question: If there is a consensus at the article for Opt-Out, that seems okay to me. So I agree with Rexx that the presentation of the quesiton is non-neutral and will lead to Opt-In !votes from people like me if they do not see Rexx's comments. I am still on the fence. What would be helpful is actual examples of articles where Opt-Out or Opt-In has or could be a problem. That would help me make a decision. --David Tornheim (talk) 13:53, 17 May 2016 (UTC)
  • Problems arose at Template talk:Infobox book, where ISBNs were being imported without notice, including for books that predated ISBNs. The change was made to the template without discussion, and changes to the infoboxes did not show up on watchlists. Curly Turkey 🍁 ¡gobble! 14:06, 17 May 2016 (UTC)

I think RexxS' Template:Infobox book/Wikidata/Sandbox is a practical approach.

@Curly Turkey: logic can detect the difference between an expression of a work and a work. {{Infobox book}} states that first edition of a work is preferred. So if that expression of the work did not have an ISBN, then it still will have an LCCN, etc. Moreover, viaf.org also IDs a work and the expression of the work – other institutional silos likely do too.

Wikidata should be able to assert attribution for metadata from reliable institutional databases, e.g. viaf.org or loc.org or bl.uk for published works. –BoBoMisiu (talk) 15:38, 17 May 2016 (UTC)

You're working from the assumption that we should include as many fields as possible for, say, a book or a person. That's not an assumption that has consensus. Look at Wikipedia:Village pump (policy)/Archive 126#RfC: Religion in biographical infoboxes—the consensus is to exclude religion in {{Infobox person}} by default, even when there is no doubt of the veracity of the religion. There are recent RfCs that reached the same conclusion, for example, about ethnicity. These are data that might be perfectly appropriate for Wikidata, but not for an Infobox. Curly Turkey 🍁 ¡gobble! 23:04, 17 May 2016 (UTC)

Curly Turkey raises a valid point and I agree that we mustn't assume that because data is available, we have to have it in the infobox. The problem may possibly be even worse in the case he cites. If it were simply a matter of deprecating the |religion=, then we could simply remove it from {{infobox person}}. However, that RfC specifically allowed the use of the parameter in certain cases, such as in the biography of a religious leader and in others where the subject's religion is intrinsically tied to their notability. That means we need a scheme that can cater for not having a parameter displayed by default, while allowing it under closely delineated circumstances. One thing that these discussions is crystallising for me is that we sometimes really need the ability to completely suppress the display of a particular field in a given infobox by default (with an exception to allow display on a per-article basis). I know how to do this if the infobox uses calls to a Lua module, but it may take some thought on how it could be implemented using the parser functions available in a normal template. --RexxS (talk) 00:16, 18 May 2016 (UTC)

@Curly Turkey and RexxS: no, I am assuming nothing about what should be mapped into infobox fields or how many should be presented to the reader. There are several interconnected topics being discussed, among them: the availability of wikidata, the reliability or veracity of individual wikidata properties, the attribution of wikipedia content mapped from wikidata properties (in effect also from sister projects), the mapping from wikidata properties into infobox fields, inconsistent community censorship of structured data among sister projects or languages (e.g. ethnicity, or religion, or genetic sex vs self-identified gender, or other identifiers that are rejected by some cultures but not others), data model of infoboxes, aesthetics of larger vs smaller infoboxes, and how individual editors add infobox code into articles (empty field vs removed field). Changing from opt-out to opt-in does not address those topics – opt-in acts like a v-chip preset with censorship activated instead of censorship deactivated. –BoBoMisiu (talk) 15:19, 18 May 2016 (UTC)

"Censoring" is not an apt comparison, as the information that is not added to the infobox is often in the article, where it is contextualized. |religion= is the perfect example—description of a person's religious beliefs can sometimes run to multiple paragraphs, assuming it's all consolidated in one place instead of throughout the article.

I'll give a non-controversial example (no politicians): Art Spiegelman. There is no doubt that he is a cisgendered male secular Jew. Despite the fact that his Jewishness is central to his public figure—and this is an article that averages over 400 pageviews a day—no attempt has been made to cram that into the infobox. These facts are not censored from the article by leaving them out of the infobox—if you come out of the article not knowing Spiegelman is a Jew, then an infobox is not going to help you. It's reasonable to have "male" listed in his Wikidata item, but it's harder to justify in an infobox, which is meant to summarize key facts about the subject, not bury those key facts amongst trivialities such as gender.

Other issues come into play—those in charge of the keys at {{Infobox book}} have decided that infobox will be for first editions (sans discussion) rather than general details about the book. Those of us who disagree have had the option of (a) not using an infobox at all; or (b) just leaving out the first edition-related parameters (isbn, pages, media, publisher). Now we've found out that option (b) has bitten us in the ass. If it had been opt-in, this never would have happened, and there'd be less opposition to Wikidata-aware infoboxes (I'd probably use them, in fact). The rug's been pulled out on us—trust has been betrayed. Curly Turkey 🍁 ¡gobble! 23:30, 18 May 2016 (UTC)

@Curly Turkey: nevertheless, as I wrote above, "opt-in acts like a v-chip preset with censorship activated instead of censorship deactivated" – it does not address the issues presented. The effect will be default censorship of the wikidata with optional inclusion. –BoBoMisiu (talk) 16:17, 19 May 2016 (UTC)

BoBoMisiu: No comparison—a v-chip blocks content. With opt-in, the content is most often not only still there, but often prominently so, in detail with in-depth contextualization. Curly Turkey 🍁 ¡gobble! 22:27, 19 May 2016 (UTC)

@Curly Turkey: I disagree with you, opt-in requires someone to toggle the censorship off for each instance. It is just like someone allowing a child to watch "TV-G" programs or the great firewall of China allowing its citizens to watch something about Tiananmen Square protests. It is about shutting off access to wikidata by default just like a white list firewall. It is segmentation by default. –BoBoMisiu (talk) 03:51, 20 May 2016 (UTC)

BoBoMisiu: It's like you didn't even read what I read. How could it possibly be anything like a TV-G program or the Great Firewall when the information is all right there before your eyes? Here we are watching tanks rolling over students with tickertape-like byline giving us the details while some CNN announcer is giving us a play-by-play—and you tell us there's "censorship" because there isn't a little box in the corner redundantly summing it all up (don't forget that infoboxes are meant to be redundant). Look at the Harvey Kurtzman article—is it "censored" because it doesn't mention he's a Jew in the box? Of course not—you don't even have to scroll down to see that he was born to Jewish immigrants. I'd call this hyperbole, but hyperbole requires stretching a kernel of truth—there is literally no amount of "censorship" happening with opt-in. Curly Turkey 🍁 ¡gobble! 06:02, 20 May 2016 (UTC)

@Curly Turkey: I did read this again and I still think is about shutting off access to wikidata by default. Yes or no? –BoBoMisiu (talk) 18:53, 20 May 2016 (UTC)

No. Access is still there—where do you think it'd have gone? Don't go calling the autofilling of templates "access". The indiscriminate (human) filling-in of fields has already driven enough editors from using boxes in the first place—look, there's an open FAC where the nominator has been convinced to remove one—and you'll only see more refusing to use boxes at all. This whole mess have convinced me to finally give them up, given the disregard and near-contempt shown for editorial judgement. I'm no Luddite—I make extensive use of templates and have contributed to Wikidata. Curly Turkey 🍁 ¡gobble! 21:30, 20 May 2016 (UTC)

@Curly Turkey: those are differences in editing style within individual articles – but not related to a big brother (default opt-in) controlling the relationship between the structures that contain that data and use it. The arguments use premises about individual content discrepancies to make sweeping generalisations about structural relationships. These are different types of things. An analogy is: premises about using stuff (i.e. wikipedia) found in containers (i.e. wikidata) does not lead to conclusions about who controls the relationship to the containers. Changing to opt-in will require someone to toggle that default censorship off in each instance to use the stuff found in those containers. The Zeta Jones discussion you point to is a good example of misunderstanding of what structured data is. An editor commented "everything in the current box can be found in the lede" – but content in a lede is unstructured because is outside of a data model. I think that example was more about aesthetics. –BoBoMisiu (talk) 20:59, 21 May 2016 (UTC)

You've missed the point: boxes are officially optional, and many editors are keeping them out already, so that forcing opt-out only gives people more excuses to leave the box out (and there goes all the structured data).* It's the straw that broke this camel's back, anyways—I won't use infoboxes anymore because I can't trust them to behave as expected. Infoboxes were conceived as a place to sum up the article, not a place to dump indiscriminate data.

You're still pushing the hysterical "censorship" angle with your "big brother" arguments, and it's not getting any more convincing. Literally nothing is being censored.

*(except, not really, because it's all linked to in the sidebar) Curly Turkey 🍁 ¡gobble! 21:18, 21 May 2016 (UTC)

@Curly Turkey: What do think of the suggestion made by Benjamin Good above, that the code for infoboxes be constructed so as only to display Wikidata values where they have a supporting reference on Wikidata? (I think we'd have to exclude "imported from xx.wikipedia" from counting as a reference.) That would only import data that someone had made an explicit effort to reference. How much of your concerns would that address? Mike Christie (talk - contribs - library) 00:39, 22 May 2016 (UTC)

@Mike Christie: No, I was explicit that my issue—the reason I opened this RfC—was not the quality or verifiability of the data, but the change in behaviour—the assumptions have all changed. It used to be that you could avoid having people filling in a field by leaving it out—leaving it blank only encourages people to fill it in. We'll never know how many editors crafted infoboxes under those assumptions, but it's come up enough times over the years to assume it's considerable. Opt-in would keep those assumptions intact while still allowing the boxes to be Wikidata aware. A smarter idea might have been to have new {{Databox XXX}}es that implement this stuff whatever way the Wikidata people want to, and gradually replace old {{Infobox XXX}}es where appropriate or desired—then we wouldn't have these mysterious, automagical changes happening. Infoboxes were conceived as a place to summarize key points in an article—that's not the goal of Wikidata or Wikidata-aware infoboxes, as you can see from this head-scratching "censorship" nonsense. Curly Turkey 🍁 ¡gobble! 09:06, 22 May 2016 (UTC)

@Curly Turkey: There is nothing hysterical about my comparisons. I understand the "boxes are officially optional" that seems to be a straw man. The proposal is not about the boxes but about explicitly blocking wikidata by default until someone does an opt-in to permit wikidata into fields in the boxes. –BoBoMisiu (talk) 15:11, 22 May 2016 (UTC)

"explicitly blocking"—you have a funny understanding of the word "explicitly". "Opt-in" would retain the behaviour we've come to expect while allowing full access to Wikidata. Calling it "censorship" and comparing it to "Big Brother"—yeah, that's mighty hysterical. Now you're saying opt-in is censorship, but leaving the boxes out entirely is not? You'll have to explain. Curly Turkey 🍁 ¡gobble! 21:39, 22 May 2016 (UTC)

@Curly Turkey: very well, I will explain. The current system wide setting is opt-out and does not block wikidata by default. Your proposal changes that to opt-in and does blocks wikidata by default. Blocking the flow of data between structures is censorship: your premises are "we can't possibly predict all the parameters we should exclude" and "editors lose control over the articles they edit" and "If someone adds a new parameter to a box used in 37,000 articles, how do you ensure that the editors of all 37,000 articles know that this new parameter has been added so they can judge whether it should be excluded?" from those kinds of premises your conclusion is to block all wikidata by default, i.e. place a wall between wikidata–wikipedia structures because "we can't possibly predict" everything "we should exclude". It is the comparable logic behind a v-chip and a whitelist firewall. I wrote earlier: "I still think is about shutting off access to wikidata by default. Yes or no?" The question you are asking about not including a box in an article, in contrast, does not change the relationship between wikidata–wikipedia structures. –BoBoMisiu (talk) 14:32, 23 May 2016 (UTC)

You've just restated all the same assertions I've already refuted. Luckily for us all, nobody else is picking up this absurd, hysterical, counterfactual "censorship" angle. Curly Turkey 🍁 ¡gobble! 23:05, 23 May 2016 (UTC)

@Curly Turkey: yes I restated what I think are your premises. I do not read anything that write as a refutation. I may be wrong but you do not answer that simple yes-no question I asked above that would refute me and I would concede. I asked: Is your proposal about shutting off access to wikidata by default. Yes or no?

About your example about book ISBNs in cases where works have more than one edition, a work is commonly described by its first edition. For example, Nineteen Eighty-Four uses {{Infobox book}} which has documentation that suggests "prefer ISBN of 1st edition" and "OCLC number (prefer 1st edition), use when book has no ISBN". I see that a different language first edition OCLC could become wikidata that is imported into that infobox. The problem is not about the relationship of wikidata–wikipedia structures but that wikidata:Q208460 describes the work and not the expression of the work. So when you follow the link viaf.org/viaf/175794909/ you see the work page with some expressions of the work but not all. From there if you follow the link viaf.org/viaf/95155403/ you see the author page with links to several records of works titled Nineteen eighty four. A wikidata or wikipedia contributor who adds the ISBN or OCLC of the 1st edition of the work would need to know that the 1st edition is the preferred edition to avoid the existing state in that instance of the infobox which has, for example, a 2003 edition OCLC added by a wikipedia contributor in 2009 and then imported into wikidata. It was nothing more than user error in that case. If wikidata later imports a record of the preferred 1st edition from a library catalog, the infobox will still retain the 2003 edition OCLC and 2013 ISBN instead of the preferred 1st edition OCLC without an ISBN. Again, the error was spawned was caused by human error of a wikipedia editor in 2009 and not changed by anyone since. Your proposal would not change anything in such a case. –BoBoMisiu (talk) 02:40, 24 May 2016 (UTC)

I answered your loaded question. Access would not be "shut off"—the indiscriminate loading of data would simply not be automatic. As it has always been—the auto-importing of this data is new behaviour and overrides the assumptions of the editors. Opt-in respects the decisions editors have made over the years while still enabling infoboxes to import all of this data. Regardless, all the data is but a click in the sidebar away.

Re: ISBN—I'm one of the many editors who doesn't agree with this "prefer first edition" schtick—the box should contain general information about the book, and thus not an ISBN, OCLC, page count, media type, etc etc etc. Whether the data is correct or in error is irrelevant—it doesn't belong in the infobox. Infoboxes were not conceived as an indiscriminate data dumping ground. Curly Turkey 🍁 ¡gobble! 03:14, 24 May 2016 (UTC)

@Curly Turkey: great sidestep on ISBNs and OCLCs by avoiding the standard way works are described, i.e. "prefer first edition". ISBN and OCLC are general information about books in the 21st century – the connection to authority records provides readers with structured data that libraries use to describe a work in standardized ways.

Your reply avoided the term by default and used indiscriminate instead. You still avoided the question – and I still see opt-in as blocking wikidata contributions by default, i.e. censoring.

Yes, opt-in "respects the decisions editors have made over the years" and opt-in rejects the contributions other editors have made over the years until someone else decides to permit those contributions – in other words it creates classes of contributions based not on the merit of the contribution but on the method or channel of contribution. Moreover, is irrelevant since every editor can make changes that in turn can be rejected. The real reason is that wikidata is disruptive innovation (what you call new behaviour) that confuses some people about their premises of control, you wrote: "we can't possibly predict all the parameters we should exclude" and "editors lose control over the articles they edit". The internet is arguably the most disruptive innovation ever that is why totalitarian governments block access to it because they "can't possibly predict". Likewise, from your similar premises you conclude blocking all wikidata by default, i.e. creating structural barriers between wikidata–wikipedia structures because "we can't possibly predict" everything "we should exclude". Technology is and will continue to change: the internet of things will become commonplace and the relationship between identifiable objects and their descriptions in wikipedia will evolve. Structured data in wikidata is the machine readable interface. Importing data from authoritative sources into Wikidata will eventually correct human editor contributions like the Nineteen Eighty-Four example above. To say that "all the data is but a click in the sidebar away" seems not to be open to the possibilities of innovation. There is a whole world of reliable meta-data out there but opt-in isolates wikipedia by default. –BoBoMisiu (talk) 14:57, 24 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)

  Thank you RexxS for the additional info. To me these seems like an easy way to implement wikidata. If you are happy with the Wikidata content then let the infobox fetch it. if not, override it with a local value or set it to empty. Then my concern is about the quality of data in Wikidata, too much seems to say "imported from Wikipedia" without the RS we insist on here having been carried over. That's not just a problem with Wikidata but for all of us and I suspect for many who have contributed to this RFC a fairly major stumbling block to opt-in. The mechanics are acceptable but the quality control is lacking. Nthep (talk) 11:29, 21 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)

Damn, it's not working as it should be (still beta, now borked) - but what it should do is simply pull a number of parameters from Wikidata. These are from a number of high quality sources that include this data in a structured format. Ideally the template would only pull the data if sources exist, this is being worked on.
As for the questions by Robevans123, I had not seen them before now and I agree that they are very important. Maybe Daniel Mietchen may have an answer? Carl Fredik 💌 📧 14:34, 17 May 2016 (UTC)

Implementation vs existence

It seems there are solid arguments against the current implementation of Wikidata in infoboxes, but not really much against the idea behind it. There's also a lot of support for the idea of Wikidata but not necessarily much for the implementation.

One major issue appears to be (I've had fun with it myself) that Wikidata magically appears in the rendered page, but with no apparent source, so where an editor might (rightfully or wrongly) wish to change that data, they first have to figure out where it comes from, then learn how to handle it, then learn which template param will override it, then add the (possibly empty) argument to the infobox.

A solution that may appease the opposition to the implementation, would be to have Wikidata (where instantiated) announce itself in the rendering of the infobox - something along the lines of a small "This information is partially sourced from Wikidata" linked to the most useful Help: resources and the responsible Wikidata entity (the [edit on wikidata] link in the corner isn't very informative or even what needs to be done in many cases).

This measure would empower editors to make editorial decisions about the use of the data more quickly and easily, and pave the way for development of a rich meta project that should be considered beneficial, not disruptive. Fred Gandt · talk · contribs 22:52, 19 May 2016 (UTC)

I'm all for empowering editors to make editorial decisions, but I don't agree that the [edit on wikidata] link isn't informative to an editor - a reader, maybe. Surely an invitation to edit the corresponding article on Wikidata is informative of what that link does?

I'd be quite happy to implement a longer notice saying "This information is partially sourced from Wikidata" as a test in any wikidata-aware infobox you'd like (but it can't be <small>...</small> as that would be below the 85% minimum text limit agreed for readability). However, I can't guess what "the most useful Help: resources" are that you have in mind, nor do you indicate which part of the notice you want linked to them and which part you want linked to the Wikidata item. If you can give me some specifics, I can make a trial for you. --RexxS (talk) 15:03, 20 May 2016 (UTC)

Not sure if this is a good idea or not, but perhaps what Fred Gandt's suggested can be combined with something RexxS was/is working on, Wikipedia_talk:Wikidata#Wikidata_references, so the line This information is partially sourced from Wikidata becomes the heading of a collapsed element containing references from Wikidata (for fields using wikidata) – i.e. as a very rough visual mockup:

Example
Foo	Bar
Baz	Qux
This information is partially sourced from Wikidata Foo (P123): Bar – SomeReference Baz (P789): Qux[reference needed]

with appropriate links to be added in appropriate places. - Evad37 [talk] 04:23, 21 May 2016 (UTC)

@RexxS: What I meant by not very informative, is that it doesn't indicate which magic values are affected or how to do anything about it locally. That's where the suggestion to link to help pages comes in, although the help needed may not currently exist and would thus need to be created. This is merely suggesting a place to start on a possible course of action. Evad37 has shown exactly the kind of initiative I hoped to encourage.

@Evad37: Great idea Fred Gandt · talk · contribs 06:27, 21 May 2016 (UTC)

This idea/possible implementation is looking very good. If the collapsed section also included a link to the Wikidata source such as Source: Ffynnon Gwenfai - Statutory List of Buildings (here's one I made earlier), then an editor would have access to the details to create a reference in the article (not quite as good as creating a reference automatically, but a good start). Robevans123 (talk) 09:48, 21 May 2016 (UTC)

Setting precedence

We have to consider the fact that whatever we choose here will set a precedence, whether we as a community choose to be for or against. WikiData is far from complete, it is still in its infancy and problems are being worked out every day - such as how to report updates to infoboxes, showing older versions of an article etc. But it also hold enormous potential, and can automate and help us as editors immensely.

The example I previously provided at Gout is able to pull different symptoms, differential diagnoses, treatment options etc. from databases which have been introduced to Wikidata. This endevour is pointless if it can only be done for one article at a time, and we still have the exact same issues.

I implore those who voted for opt-in to rethink, (and those not yet voted such as Jytdog and Doc James) not because it will immediately result in benefit for the encyclopaedia, but that it will ten years down the line. Institutional memory is very strong on Wikipedia, and what we choose matters for a long time. Turning WikiData back to opt-out once it has turned opt-in is going to be an insurmountable task. We tend to stick to what we once decided, especially when many of us vote - but when that vote is good in the short term, bad in the long term it damages the project So, lets put more time in revising the use of excessively detailed templates, and focus on what WikiData can do for us. Carl Fredik 💌 📧 14:04, 17 May 2016 (UTC)

I still don't understand what you did at Gout. Are fields there being automatically populated somehow? Jytdog (talk) 14:14, 17 May 2016 (UTC)

Yes, check out the Template:Infobox medical condition(new), which pulls a number of properties from WikiData. It is so far still only a beta-version, but it show useful and more importantly human-readable information (unlike the old infobox did). (BTW, not my work) Carl Fredik 💌 📧 14:26, 17 May 2016 (UTC)

So what actually happens when I remove Field = Rheumatology by editing the Gout article in the template section on wikipedia - because I have left it blank, the infobox pulls the 'Specialty' from Gout at wikidata and populates it accordingly. You can see from the switch from Rheumatology to rheumatology. However Gout's specialty field at wikidata is sourced to wikipedia, and the wikipedia article does not actually state in the article that Gout is in the Rheumatology field. Except in the infobox. Which is unsourced. (it probably doesnt need to be as its a sky is blue issue - for doctors anyway). In this case not an issue, but it clearly demonstrates the problem with the process. Only in death does duty end (talk) 15:05, 17 May 2016 (UTC)

The specialties are typically based on the ICD10 which groups diseases by them. Doc James (talk · contribs · email) 16:26, 17 May 2016 (UTC)

Except in this case, its not. Its clear circular (un)referencing and from the stats shown at signpost, this is the *norm* not the exception for data hosted at wikidata. Granted the medical wikidata appears to be better than other areas, but wikipedia is bigger than just the medical section. This was an example CFCF chose of it working well/correctly - and it shows the glaring shortcomings of an opt-out approach that could have quite serious consequences. Only in death does duty end (talk) 16:35, 17 May 2016 (UTC)

Then something has gone awry, because the data is imported from the ICD-numbers, we did that at Wikimania 2015. Carl Fredik 💌 📧 18:31, 17 May 2016 (UTC)

• Wikipedia's sourcing requirements for medical info are in some ways just as restrictive as our BLP requirements. As far as I can see Wikidata does not have those same restrictions for medical (or any other info.) I (and I suspect many others) are unlikely to ever want "symptoms, differential diagnoses, treatment options" automatically filled in on infoboxs from wikidata without a manual check that the information included abides by our sourcing requirements. I have yet to see an argument that explains how this would be prevented that doesnt include more work under opt-out, than under opt-in. Only in death does duty end (talk) 14:18, 17 May 2016 (UTC)

Sourcing requirements for medical info are far stricter than those for BLP, and only reliable data should be imported to WikiData at all. The whole point of Wikidata is to automatically import reliable information (and not just any crap), and any manual control at all makes the task exponentially more time-consuming. Carl Fredik 💌 📧 14:26, 17 May 2016 (UTC)

Well quite, but this clearly indicates maybe only a quarter of wikidata's data is referenced to a source independant of wikipedia. And thats only indicating they have a reference, its no indication they are 'reliably sourced' and compliant with our policies here. There is no indication that the unreferenced material on wikidata will be excluded from the automatic importation (which it really should be). The whole point of wikipedia is to present information that is verifiable and has been reliably sourced. Currently Wikidata does not do that. Only in death does duty end (talk) 14:31, 17 May 2016 (UTC)

A solution that the Swedish Wikipedia employs is to bring along all references on Wikidata (sv:Modul:Wikidata/sv:Mall:Wikidata, example [[]], can't find any example) and in such a manner also only accept sourced Wikidata entries. But at the same time, we use data on Wikipedia in almost all infoboxes that is unreferenced, and any Wikidata reference is better than having no reference on Wikipedia.

Another solution is something like what exists on Template:Infobox drug, with a verification button (in that case poorly implemented and confusing, but existing). Carl Fredik 💌 📧 14:40, 17 May 2016 (UTC)

"we use data on Wikipedia in almost all infoboxes that is unreferenced, and any Wikidata reference is better than having no reference on Wikipedia." The problem with that is circular - Wikidata imports data directly from multiple wiki-projects (including directly from infoboxs) and the reference is the projects article - so any 'filter out unreferenced' import to wikipedia is still going to have issues when a huge amount of the actually referenced data is unreliably sourced. There are issues with "any Wikidata reference is better than having no reference" when functionally data in an infobox on wikipedia does not have to be referenced directly when it has been referenced in the prose. However data that isnt in the prose and has been imported from wikidata is currently likely to be either unreferenced or badly/unreliably referenced. The general consensus on wikipedia is that information should not be included. Opt-out would actively cause more checking required on the wikipedia end for very little payoff. Only in death does duty end (talk) 14:53, 17 May 2016 (UTC)

Now you missed the point. I would not consider Wikipedia a reference on Wikidata, I don't even know that it is? Carl Fredik 💌 📧 15:11, 17 May 2016 (UTC)

See my above comment RE Gout. Only in death does duty end (talk) 15:13, 17 May 2016 (UTC)

User:CFCF - how does that work? Cuz...

I'm wondering why the Template:Infobox drug box at Fluoxetine doesn't display the wikidata for price but does (if I'm not mistaken) (I don't think it uses wikidata for the chemical formula because "|C= 17 |H= 18 |F= 3 |N= 1 |O= 1" overrides anyway, I guess. (I wonder how to make it display both/if it's yet appropriate to delete the "|C= 17 |H= 18 |F= 3 |N= 1 |O= 1" and let wikidata take over.) I don't see anything like {{#property:P274}}, {{#property:P2284}} or {{#property:P<anything>}} in the source of the infobox template. --Elvey^(t•c) 07:29, 1 June 2016 (UTC)

ArticlePlaceholder

Magic Unicorn, said to present Wikidata information on Wikipedias

Just this week a variation of what is proposed here is made live on other language Wikipedias. See

• mw:Extension:ArticlePlaceholder
• (Wikidata) ArticlePlaceholder now live on first 4 Wikipedias

See live examples as follows -

• Odia language
  • https://or.wikipedia.org/wiki/%E0%AC%AC%E0%AC%BF%E0%AC%B6%E0%AD%87%E0%AC%B7:AboutTopic?entityid=Q131074
• Neapolitan language
  • https://nap.wikipedia.org/wiki/Speci%C3%A0le:AboutTopic?entityid=Q2613697
• Esperanto
  • https://eo.wikipedia.org/wiki/Speciala%C4%B5o:AboutTopic?entityid=Q12345
• Haitian Creole
  • https://ht.wikipedia.org/wiki/Espesyal:AboutTopic?entityid=Q12345

What is happening in these cases is that Wikipedias with very little activity get information in infoboxes from Wikidata. Right now, the information hardly makes sense, and is intended to inspire a human to draft some sentences. Still, this demonstrates how information in Wikidata is planned to be shared in Wikipedias. Anyone with comments for the ArticlePlaceholder team go to the MediaWiki talk page at mw:Extension_talk:ArticlePlaceholder or to the Wikidata mailing list. I thought it would be useful to share this hear to give context to the discussion about sharing data in infoboxes here. Blue Rasberry (talk) 20:30, 18 May 2016 (UTC)

ArticlePlaceholder doesn't use infoboxes, and it only appears when there is no local article on the subject. If you want to see what can happen with infoboxes, then look at w:es:Jimmy Wales. The large infobox in that bio requires a single line of wikitext and zero parameters. WhatamIdoing (talk) 03:29, 22 May 2016 (UTC)

Very unsatisfied with process. Could changes be made that would improve Wikipedia ANI? (Better for 'Proposals?')

For context: Over one week ago I sought quick real-time help for the disruptive behavior of an editor at ANI...He had behaved against policy in a reference desk thread with another, apparently banned user, and I collapsed their back and forth..he then basically edit warred to uncollapse it over and over again (another thread “we need an adult” was initiated just a few days ago at ANI by another user complaining about him doing the same kind of thing elsewhere) Anyway, I came to ANI for help. He then filled that thread up with endless nonsense. The thread was open more than a week but an admin never came around to either A. put a quick end to his general behavior or B. declare, I suppose, that there was nothing wrong with it...Instead, all we had were a few non-admins addressing things in what seems to me not a particularly competent manner..the thread ended with him declaring that I had been blocked in a way to clearly suggest that I had been blocked for the thread, thereby somehow vindicating himself (which is entirely untrue)...a non-admin then closed the thread and repeated the claim in the closing statement that I had been blocked in a way that clearly suggested I had been blocked for the thread..this is an entirely misleading closing statement made by a non-admin..(I was blocked for policy of “canvassing” in regards to an unrelated AfD..I notified an editor who had done research relevant to the AfD which seemed to support deletion..that's a whole other story).

Admins are admins because they are theoretically competent editors..I would like to see A. only admins be allowed to close threads and write closing statements at ANI B. for there to be some kind of requirement or concerted effort for an admin to address within a certain time frame every thread and either end it appropriately or state more input is first needed and C. have admins be identified as admins in their signatures at least on this noticeboard so people can understand when they are receiving a response from an admin being that this is an admin notice board...It is hurtful to the Wikipedia project if people are running into a process like I describe above, as it will chase editors away..Thank you in advance for any replies/thoughts..(the thread in question was called simply “disruptive behavior” and was archived just a couple of days ago...I don't know how to link to just that thread)..68.48.241.158 (talk) 16:54, 26 May 2016 (UTC)

How exactly would one plan on on doing this conceptually though? B seems unenforceable (How would we hold people accountable to this? It's a volunteer project.) A would be extremely counterproductive to B - lessening the number of people who can address the issues is going to slow things down even further, not speed things up. I don't see how C would affect anything at all - all you need to do to see if they're an Admin, is usually just click on their WP:USERPAGE. Sergecross73 msg me 17:14, 26 May 2016 (UTC)

For C, if you create an account you can use a gadget that will show peoples groups when you hover over their username links. — xaosflux ^Talk 17:30, 26 May 2016 (UTC)

• Concerns raised at ANI are usually responded to faster than the OP indicates... so I suspect that his/her experience is non-typical. I don't think we should change our procedures unless it can be established that the issue is more widespread and systematic. Blueboar (talk) 17:49, 26 May 2016 (UTC)

perhaps it's an anomaly but I also can't imagine too many editors have gone all the way to complain about the very process; so it's impossible to know (ie first they run into a problem and bother to take it to ANI..they then go through the bother of dealing with the ANI thread...the ANI thread doesn't work well so they bother to look into the very process of ANI via where we are now..very unlikely..they just go away from Wikipedia editing)...I have read that Wikipedia is having a very hard time attracting new editors...so if fairly straightforward things could be done to make things more professional..68.48.241.158 (talk) 18:48, 26 May 2016 (UTC)

Well, plenty of people complain, its just that they either don't have a workable solution, or can't gather a consensus in their favor to enact the change. Much like this proposal. They're nice ideas, but how do you make it happen? How do you require admin to address AN/ANI concerns in a certain amount of time? And what happens if they don't? And who enforcing this? Sergecross73 msg me 18:56, 26 May 2016 (UTC)

Please read WP:NOTCOMPULSORY. WikiP is a voluntary organization not a "professional" one. I am sorry that you are not happy with the given situation. MarnetteD|Talk 19:06, 26 May 2016 (UTC)

not helpful imo..that's like saying nothing should ever be improved/attempted to be improved on Wikipedia because nothing is required to be..68.48.241.158 (talk) 19:10, 26 May 2016 (UTC)

It's definitely helpful, he linked to WP:NOT, which is a key Wikipedia policy that defines what it is and is not. And it quite perfectly defines a massive problem with your proposal - what exactly would your plan be to enforce point B of your proposal? Sergecross73 msg me 19:26, 26 May 2016 (UTC)

there would be no enforcement mechanism, obviously. It would involve, perhaps, a notice displayed at that space that states it is expected/encouraged that an admin will address each thread within a certain timeframe...perhaps a message sent out to all admins to inform them of the policy/encourage them to add the page to their watchlist etc so they can participate in making it happen..whatever...A is trivial you just announce the rule and enforce it...C would require coding for admins to be identified on just that page...so there you go..68.48.241.158 (talk) 19:51, 26 May 2016 (UTC)

So your plan to speed up the process at ANI is to have a notification that says "Hey volunteers, don't forget, you're expected to volunteer. And do so by x time."? And if they ask "And what if I don't?", the answer would be "There's no repercussions". That would elicit zero change from Admin. Admin are already helping as much or as little as they want to. Sergecross73 msg me 20:12, 26 May 2016 (UTC)

yes, I would expect many more admins to help out if was announced to them that this was the goal there that was going to be strived for..why not??? (I'm probably done going back and forth with you as you've clearly suggested you're not interested in being constructive along these lines, but only critical..so don't want to fill up the thread...you've weighed-in; I'll see if others come along)..68.48.241.158 (talk) 20:17, 26 May 2016 (UTC)68.48.241.158 (talk) 20:21, 26 May 2016 (UTC)

Because these are volunteers and honestly, this is not something that I would want Wikipedia to become. It's already implied on these boards that issues will be handled in a rapid manner, and they are both by admins and non-admins alike. RickinBaltimore (talk) 20:19, 26 May 2016 (UTC)

I was interested to see recently that WP:DYK states Review requirement (QPQ) – For every nomination you make you must review one other nomination (unrelated to you)—​​this is called quid pro quo or QPQ. DrChrissy ^(talk) 20:24, 26 May 2016 (UTC)

The B proposal not only doesn't make sense in Wikipedia's setting, but it doesn't even work in real life. To influence people, you need either positional power (police, your boss at work, a teacher, etc) or emotional power (family, friends) over people. Your idea lacks both. A random notification saying "Hey volunteers, volunteer harder now, because an anonymous editor is unhappy" lacks that entirely. It just isn't going to work. Sergecross73 msg me 20:37, 26 May 2016 (UTC)

Note: I've also made suggestions "A" and "C"....the above are addressing mostly "B" (which I think is very important)...suggestions other than my own are also welcome too of course..68.48.241.158 (talk) 20:25, 26 May 2016 (UTC)

C isn't necessary, its already very easy to find this information out, through the ways mentioned above. A isn't necessary either. Non-admin are very helpful in fielding questions before Admin even get there. Ironically, it was a non-admin who was first to notify you that the Village Pump was the correct area to have this conversation when you asked at an improper venue (AN's talk page), so you've literally seen this to be true. I'm sorry you feel that a non-admin gave you bad advice, but I'm not aware of this being a consistent, rampant problem that needs fixing. Do you have examples of this being a frequently recurring scenario? Sergecross73 msg me 20:31, 26 May 2016 (UTC)

I disagree that this discussion couldn't have occurred over there..but it's fine to have it here; doesn't matter. Dr. Chrissy just added something novel and interesting above..68.48.241.158 (talk) 20:39, 26 May 2016 (UTC)

That's not the point, the point was, a non-Admin gave you good advice faster than an Admin did, and he gave you the same advice Admin eventually gave you. And yes, I saw DrChrissy's post, and its a nice observation, but it doesn't negate my point. That situation is still different. They have a motivation to follow that rule - if you don't do DYK posts for others, they'll stop doing them for you. There's no such element in your proposal. Sergecross73 msg me 20:53, 26 May 2016 (UTC)

The point I was trying to make regarding the DYK page is that we have already invoked responsibility onto editors. This invoked responsibility could also be a part of becoming an admin. If admins don't close X number of ANI discussions in a year, they lose their admin rights. Part of my motivation for this is my perceived increase in the number of non-admin closures at WP:ANI when these clearly needed the eyes and thoughts of an admin. DrChrissy ^(talk) 21:02, 26 May 2016 (UTC)

Ah, I see, I didn't realize that's what you were suggesting. Yes, at least suggestions like yours are at least plausible in that they contain structure and logic to them. My main objection to the IP's plans is that they amount to little more than "Let do more good and less bad" without any realistic plan on how to get there. Sergecross73 msg me 21:15, 26 May 2016 (UTC)

because my suggestions contain no logic nor structure whatsoever...and admins will only do things if there are police officers waiting to arrest them..68.48.241.158 (talk) 01:31, 27 May 2016 (UTC)

That at least seems to make sense as a way of incentivising admin participation at ANI. Potential problems might be: 1) if admins are required to do certain adminny jobs, it might put off people who would otherwise go through RFA if they are not interested in the jobs that they are required to do as an admin. 2) Admins putting in their time and effort to close ANI discussions who are more interested/capable in other areas are a wasted resource. Assuming the number of hours an editor puts in a year is constant, each extra hour doing ANI stuff because requirements is an hour not spent doing something else. 3) Admins doing ANI stuff because requirements might put less effort/thought into it than they would if doing it because that is what they wanted to do. Caeciliusinhorto (talk) 16:08, 27 May 2016 (UTC)

see the link to the discussion I posted below...apparently a part of the problem is there is simply not enough admins and there has been a death spiral in their numbers...there are less than 600 active members over all of English Wikipedia!!68.48.241.158 (talk) 17:47, 27 May 2016 (UTC)

• It does not take a genius to work out with the dwindling admin pool and the amount of non-admin editors, that any proposal to restrict non-admin input at noticeboards is doomed to a messy failure. Only in death does duty end (talk) 11:11, 27 May 2016 (UTC)

then Wikipedia has itself a major problem that is far beyond what is discussed here..why are there fewer editors and therefore fewer eventual admins? could it be because possible poor practice like that described in the OP is driving people away?68.48.241.158 (talk) 11:21, 27 May 2016 (UTC)

<citation needed>. From what I can see the OP was given reasonable advice regardless of the source it came from. Of course since they didnt actually provide a link to the discussion in question, I cannot be certain I am looking at the right one. Only in death does duty end (talk) 12:30, 27 May 2016 (UTC)

it was called "disruptive editing" and was archived a few days back (note: more appropriate to discuss proposals etc then get into what that thread was itself actually about here)..68.48.241.158 (talk) 12:39, 27 May 2016 (UTC)

Your proposal is dead from inception. Only in death does duty end (talk) 12:42, 27 May 2016 (UTC)

well, okay..thank you for your thoughtful and helpful contribution to Wikipedia.68.48.241.158 (talk) 12:45, 27 May 2016 (UTC)

You're welcome. Only in death does duty end (talk) 13:04, 27 May 2016 (UTC)

Note: I noticed this thread which is along the same lines and has some relevance to this: https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard#Time_for_50-100_new_admins_ASAP.3F68.48.241.158 (talk) 14:17, 27 May 2016 (UTC)

• Support. Admin's who fail to meet this standard should be subject to having their tools removed. We need **better** admin's not more. — Preceding unsigned comment added by 107.77.228.51 (talk) 20:15, 27 May 2016 (UTC)

there's never anything wrong with having better admins...but appears we need more too..and you should probably clarify what exactly you're supporting..68.48.241.158 (talk) 20:23, 27 May 2016 (UTC)

• Admins who only do speedy deletions are still helping the project. De-admining them because they don't attend AN/I would be negative. And indeed many admins would throw in the bit if they felt compelled to contribute there.
• Restricting An/I to (parties and) admins is probably not a good idea. It would cut down on thread bloat though, so it's not without it's good points.
• The same applies to NACs, there might be a few less bad closes (out of a pretty small number) but it would increase the workload on admins, or backlog, or both.

All the best: Rich Farmbrough, 09:07, 28 May 2016 (UTC).

As a regular patroller at ANI, I'll throw my 2 cents in. A) Mandating that only admins can close threads is very likely to see a complete grinding of ANI, as a dispute resolution forum, to a halt. ANI is known as the drama board for a reason and the numnber of active admins who patrol it is already few and far between. Preventing experienced users from closing the simplest of threads will basically cause most, if not all, of them to stop patrolling the page. The few admins who do patrol the page would be crushed under the responsibility of not only discussing every thread but also summing them up. Given how much drama some of the threads generate as well as the amount of digging into diffs that may be required, admins are more likely than not to wash their hands of the whole thing and ignore it. Non admin editors assist on ANI by helping sift through diffs, analysing behaviours if sockpuppeting is involved, investigate COI's, delving for hoaxes, etc. If these editors are driven away and admins are left with the whole task, then were would ANI be? B) Mandating a time frame is more bureaucratic process creep and places yet another unfair burden on admins. With the addition of Proposal A, and the associated reduction in patroller numbers, this would further leave ANI devoid of admins. No admin in their right mind would want to be burdened with doing all of the investigation, assessment, analysis, summing up and closure of any thread within some arbitrary time frame, even if it is just to say "needs more input". That's like saying an admin is not only the detective, but forensics, prosecution, judge, jury and executioner. C) For registered editors, you can have popups enabled so that hovering over the link of any user will generate a popup window the bottom of which will list the user rights that editor has. Again, more unnecessary process creep. The way to help ANI is not to have more process, more admins, more bureaucracy, it's for editors to have better guidance in dispute resolution. As often as not, editors who post complaints on ANI get directed to DRN, 3O, Mediation, Wikiproject talk pages, etc. Furthermore, editors should be guided in structuring their ANI post in such a way, somewhat like how ANEW is structured maybe, to make assessment easier. In many cases, the posting editor has to be prompted for evidence and that slows down the assessment. At the end of the day, ANI should be the penultimate forum for disputes, with only Arbcom, and by extension WP:AE, as a higher forum of resolution, not the first port of call. Blackmane (talk) 12:06, 2 June 2016 (UTC)

• The best thing that could be done to ANI is to redirect it to WP:TROUT and start completely fresh. Bring back WP:MEDCAB, give WP:MEDCOM some teeth, bring back WP:RFC/U for ban proposals, and leave a new board for routine things that don't belong at AN or AN3. There's a reason things like WP:PITCHFORKS, WP:POPCORN, WP:CESSPIT and Wikipedia:Dramaboard all redirect to ANI. The Wordsmith^{Talk to me} 14:07, 2 June 2016 (UTC)

I initiated this thread before discovering that there are like 500 something active admins...and apparently falling every year...this is bad imo and potentially ruinous to Wikipedia for a number of reasons...part of the reason there are less new serious editors is because aspects of the site are a mess (like ANI perhaps) and this just chases people away...so you end up with a death spiral...68.48.241.158 (talk) 23:58, 2 June 2016 (UTC)

RfC: Editinterface rights for template editors

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

I am self-closing this discussion as WP:SNOW.

---

Templates and interface pages are somewhat similar. They both encompass variables and other similar things. Since there is a lack of pages protected with template protection (most protected templates are full-protection,) I think it would be useful to give editinterface rights to the template editors' user group. — Music1201 ^talk 03:57, 27 May 2016 (UTC)

Support (Editinterface rights)

Oppose (Editinterface rights)

• Why? This could cause some serious issues. Besides, there is very rarely reason for anyone, even admins, to edit the interface. --Rschen7754 06:42, 27 May 2016 (UTC)
• Oppose doesn't seem like there's much reward to mitigate the significant risks. Andrew Lenahan - Starblind 16:30, 27 May 2016 (UTC)
• Oppose This would make the group significantly more powerful than it is now, and it's given out too freely for this new right to be safe. Jackmcbarn (talk) 20:29, 27 May 2016 (UTC)
• Reluctant oppose I do see some small risks, mostly to the wiki-reputation of over-confident template editors. Also people would be less willing to grant TE.

I support the sentiment, though.

All the best: Rich Farmbrough, 08:55, 28 May 2016 (UTC).

• Oppose unbundling generally, but this in particular. Editinterface is one of the most "powerful" rights in the admin package, and even if it is unbundled those who hold it should still pass an RFA-like process IMO. Ajraddatz (talk) 07:54, 29 May 2016 (UTC)
  • The "power" in it is primarily in the power of a tiny number of current editors of these pages to filibuster everyone else. Changes to these pages are not more difficult to revert than changes to other pages, so there's no particular danger there. The principal risk is someone doing something malicious to site-wide Javascript, which would certainly have serious consequences for anyone who did that. The obvious preventative solution to that is making sure that the MediaWiki:Common.js file and skin-specific variants remain fully admin-level protected. Then competent editors could still work on migrating CSS out of templates and into classes without having to play kiss-ass with some self-appointed Minister of CSS.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:07, 29 May 2016 (UTC)
    • Changes to interface pages can only be reverted by other editors with the editinterface right, so your statement is incorrect. And unlike vandalism to specific pages, vandalism to the interface can disrupt viewing of the entire site, or even redirect people to other harmful sites. I've seen it all before. So I'd prefer that this ability be left to people who are able to pass a community vetting process. Ajraddatz (talk) 08:10, 29 May 2016 (UTC)
• Oppose. Editinterface is a (WP:BEANS) nightmare and we a) need a much higher level of scrutiny for granting it and b) should not grandfather in all current template editors who were not assessed against these skills. BethNaught (talk) 08:01, 29 May 2016 (UTC)
• Reluctant oppose: This should be an essentially equal-level (or maybe slightly higher level) but separate user right. There's not a lot of specific-competency overlap with template editing. I would strongly support unbundling this particular admin power into a new user right, since the current situation is untenable, with a tiny number of editors acting as obstructionist gatekeepers enforcing their own personal vision. I've gone into this in more detail in the discussion section.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:07, 29 May 2016 (UTC)
• Oppose: I'm a template editor, and I have absolutely zero idea what an interface page is, let alone what to do to it. I shouldn't have this right (on the other hand, full protected templates should be dropped to template-protected level if they aren't project-breaking levels of important. If it's below the level of {{WPBannerMeta}}, it should be template-protected. ~ Rob^Talk 00:24, 31 May 2016 (UTC)
• Oppose. This section of the project can have vast security implications for readers, so should continue to only be editable by those vetted by the larger community. This would unnecessarily "raise the bar" for template editors, and if it were to pass I think a reconfirmation of every templateeditor would be prudent. There is rarely a backlog of Mediawiki: editrequests (as reported by User:AnomieBOT/PERTable), with the only delay normally occuring in items under active discussion. — xaosflux ^Talk 11:40, 1 June 2016 (UTC)
• Oppose For an unfortunate reason. Several interface pages allow raw JS and CSS to be included. This is not only limited to well-watched pages like MediaWiki:Common.js. In turn this allows any rogue editor that is able to edit those pages to violate the privacy of any visitor to Wikipedia in manners well beyond what even a Checkuser would be able to. It is already somewhat scary that admins are able to do this without identifying themselves to the WMF. (Taking away these right from admins is of course unlikely to happen—maybe should not even happen—given the superprotect debacle.) Template editor rights on the other hand should be able to be handed out liberally, and that conflicts with the enormous potential of abuse when they would be able to edit certain interface pages. —Ruud 21:21, 3 June 2016 (UTC)
• Oppose - if not for the CS and JSS issues, I would probably have supported this; however, a template editor is not necessarily trustworthy enough to be allowed to edit those. עוד מישהו Od Mishehu 06:59, 5 June 2016 (UTC)

Discussion (Editinterface rights)

• I'm fairly certain this was explicitly rejected at some point, but the originating RFC doesn't appear to have anything about editinterface. --Izno (talk) 11:12, 27 May 2016 (UTC)

  No, but it does mention "MediaWiki space" (or similar) in a few posts, such as those by Jackmcbarn at 14:31, 12 October 2013 (UTC). Note the last thread, How are we defining what a template is?, which explicitly states that MediaWiki space is not included in the proposal. --Redrose64 (talk) 11:33, 27 May 2016 (UTC)

  @Izno: I think you may be thinking of Wikipedia talk:Requests for comment/MediaWiki editor, a completely separate proposal. Jackmcbarn (talk) 20:32, 27 May 2016 (UTC)

  Jackmcbarn, indeed, probably the one. --Izno (talk) 02:36, 28 May 2016 (UTC)

• It's more that this should be a separate user right, with higher standards than template editor, but below admin. I agree that taking this ability onto TE would make TE harder to obtain, when we need more not fewer constructive template editors, and that it would lead template-competent but CSS-incompetent editors to make mistakes (but, yes, that the primary consequences of these easily reverted errors would be to the editors' own reputations). The actual problem we have right now is that MediaWiki:Common.css and other such pages are effectively WP:OWNed by a tiny cabal of editors, who will filibuster anything they don't like, refuse to implement anything they don't like even when there's clearly a consensus for it, and when cornered into implementing something will implement it they way they want it implemented instead of the way consensus said to implement it. This has been a problem for at least 5 years, and something does need to be done about it. The most obvious solution is to quadruple (or so) the number of editors who can work on these pages, thus undoing the hegemony of the controlling WP:FACTION. At this point, it is virtually impossible to get even the tiniest tweak to an existing class, or the addition of a new class, unless one is very buddy-buddy with the OWNers, who regularly reject WP:ACCESSIBILITY fixes, and the addition of classes for templates (etc.) that they don't personally favor.

  These pages should be edited more like templates that have TE protection – various people authorized to do it, but all of them aware that changes to the page should be very well-considered and tested, and usually discussed first if there's any chance of them being controversial. But they are not really the same thing requiring the same technical competencies, so they should not be the same user right, just basically equal ones. Analogy: being a park ranger, a border control officer, a state university police officer, or a transit system cop would each entail working as a law enforcement officer, with similar powers, but different jurisdictions and (aside from some basics) very different training.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:48, 29 May 2016 (UTC)

  Site wide css/js pags are no place to be WP:BOLD. If there is a dispute resolution issue, there are venue to address that. — xaosflux ^Talk 15:27, 1 June 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.

Add new chapter Wikipedia:Categorization for topic categories

In this dicsussion [Link] Administrator User:Fayenatic london asked (me) to create text about the work with topic categories.
The initial reason is described in the linked discussion.
I wrote down my text there, I won't copy it to here unless you want me to.
The goal is to incorporate the info into Wikipedia:Categorization.
Please read and criticize.
CN1 (talk) 13:37, 31 May 2016 (UTC)

Inclusion of previous names in lead sections of transgender/non-binary biographies (RfC notice)

FYI

There's currently a discussion about whether transgender and non-binary people should have their former names included in the lead section of an article. Effectively the discussion is whether anyone with a changed name as well as transgender and non-binary people be treated the same, or differently in lead sections of biography articles. See the WP:BIRTHNAME for the policy.

For the discussion please go here. NottNott|talk 00:01, 1 June 2016 (UTC)

Birthname is a subsection of the MOS guideline. It is not policy FYI. Only in death does duty end (talk) 12:07, 1 June 2016 (UTC)

RfC: Clarification of BIO1E

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

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

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

Options:

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

RfC survey: BIO1E

• 3 or 4 as proposer. I feel that (1) the guidance is inadequate as written, and that (2) the criterion should be historical significance, not simply RS coverage of any kind. ―Mandruss ☎ 19:07, 2 June 2016 (UTC)

RfC discussion: BIO1E

• What you seem to be asking for is some kind of "super notability", based on what a particular subset of reliable sources have written about (or upon our own subjective opinion of what a particular subset of reliable sources might be writing about at some undetermined point in the future), rather than what we know reliable sources generally have written about. I don't see the merit, nor have I seen any indication that it is established practice so as to justify changing the guideline's description of what practice is. I think you're just reading too much into an example that was probably included for its obviousness rather than it setting the bar that all others must pass. We also already have WP:NOTNEWS, which I think is on point with your concern. postdlf (talk) 19:51, 2 June 2016 (UTC)

The guideline confuses me as written. Unless I'm unusually, almost singularly stupid, which is not outside the realm of possibility, it will confuse others as well. My primary goal here is to eliminate avoidable confusion and the resulting wasted time in discussions. Thus I would ask you to !vote 1, 2, or 1 or 2. If you can't see fit to do that, I included 5 just for you. ―Mandruss ☎ 19:58, 2 June 2016 (UTC)

• Endorse Postdlf's points that this example is chosen for its sheer obviousness, also about 'NOTNEWS'. Real problem is the difficulty in establishing what IS going to be long-term significant. Would a better clarifier be the purely practical one that until the volume of available material requires a seperate article, default should be to not create one? Trouble is too many editors see a seperate article as an endorsement of the individual's significance, rather than the most efficient way to present information IM(H?)O. Pincrete (talk) 14:58, 3 June 2016 (UTC)

Remove bot flag from inactive bots

I recently came across numerous flagged bots that last edited 5 to 6 years ago. Since flagged bots don't have their edits shown at recent changes, someone could hack the bot account making numerous vandalism-edits and it could go unnoticed for years. I don't see any reason why bot flags should not be removed for bots not making edits in the last 6 months. — Music1201 ^talk 05:04, 4 June 2016 (UTC)

Some bots are only backups for other bots so infrequently run. Our last major cleanup was last year, and we usually do a prune from time to time. If a bot's operator is still active that is another sign that they could use their bot. — xaosflux ^Talk 05:16, 4 June 2016 (UTC)

If this is actually meant to be a proposal to change the Wikipedia:Bot policy, I suggest you workshop your proposal over at WP:BON first. — xaosflux ^Talk 05:16, 4 June 2016 (UTC)

RfC about April Fools' Day jokes

Your input is invited on Wikipedia:Requests for comment/April Fools' 2 to discuss April Fools' Day jokes on Wikipedia. Feel free to add your proposals. Mz7 (talk) 18:00, 6 June 2016 (UTC)

RfC: Religion in biographical infoboxes of non-BLPs-in or out?

Proposal: Should the removal of the |religion= parameter as done here apply only to BLPs?

• Religion would remain as a category in the biographies of deceased persons and be included in the infobox based on consensus at each particular article.
• It will stay off the infoboxes of BLPs in accordance with the previous RfC. Display name 99 (talk) 22:24, 6 June 2016 (UTC)

Comments for / against

• Support, as the nominator. One of the reasons cited previously for removal of religion from the infobox was the controversy that it invites. However, non-BLP articles are generally less sensitive, and for the vast majority of them the religious affiliations of the subjects are not matters of dispute, but simple historical facts. I edit mainly historical articles, at which the parameter causes generally no controversy or strife. It is simply a random bit of information about the person, no different than birth date, office, etc. Display name 99 (talk) 22:24, 6 June 2016 (UTC)
• Oppose Unless the religion is of significant importance to a biography, and is solidly sourced, most biographies will not benefit from having this parameter in an infobox at all. "Random bits of information" are not a rational item for any real encyclopedia, any more than having an infobox parameter for shoe size is a generally useful "good thing." And I can imagine the rush to add "Roman Catholic" to everyone on the List of Saints. Sorry - the fact is that infoboxen loaded with admitted trivia are not sufficiently utile here. Collect (talk) 22:51, 6 June 2016 (UTC)
• Oppose - Collect has it right. A religion boxes should only be included if the religion is relevant to the subject's notability. The fact that William the Conqueror was Christian and Catholic is unnecessary trivia. Blueboar (talk) 00:13, 7 June 2016 (UTC)

Is the fact that he was born in Falaise, Normandy "unnecessary trivia"? Display name 99 (talk) 00:48, 7 June 2016 (UTC)

• Oppose - Because all of the strongest reasons the community gave in the recent RfC you linked still apply whether the subject is living or long deceased. Our rules on Categorization of People apply to all people, living or not, and they single out "religion" as one of the five "sensitive" and problematic characteristics that require careful, restrictive handling when Cats & Infoboxes are concerned — unlike "date of birth" or other merely "random bits of information". The religion-related Cats and Infoboxes should, by default, not be used unless religion is a defining characteristic of their public notability; like clergy or religious figureheads, and the religion would not be out of place in the lead sentence of the article. Creating exceptions to a project-wide common-sense convention will only reintroduce many of the same old problems. Xenophrenic (talk) 01:09, 7 June 2016 (UTC)

I have edited countless history articles, and cannot recall any dispute or challenge regarding the religion category. If the material is properly sourced, I don't see the issue. Display name 99 (talk) 01:23, 7 June 2016 (UTC)