Policy | Technical | Proposals | Idea lab | Miscellaneous |
The policy section of the village pump is used to discuss proposed policies and guidelines and changes to existing policies and guidelines. If you want to propose something new that is not a policy or guideline, use the proposals section. If you have a question about how to apply an existing policy or guideline, try one of the many Wikipedia:Noticeboards. This is not the place to resolve disputes over how a policy should be implemented. Please see Wikipedia:Dispute resolution for how to proceed in such cases. Please see this FAQ page for a list of frequently rejected or ignored proposals. |
« Older discussions, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127 |
Centralized discussion | |||
---|---|---|---|
Proposals: policy | other | Discussions | Ideas |
For a listing of ongoing discussions, see the dashboard.
Note: entries for inactive discussions, closed or not, should be moved to the archive. |
|||
Contents
- 1 Wikipedia:Disambiguation and inherently ambiguous titles
- 2 Basic Data Page (A4 or 2xA4 max)
- 3 Designations or qualifiers for authorities cited
- 4 RfC: Wikidata in infoboxes, opt-in or opt-out?
- 5 Separate pages created by new editors from pages created by established user
- 6 Promote WP:Tagging pages for problems to guideline
- 7 On the use of template Preloaddraft
- 8 RfC: Proposed draftspace deletion
- 9 Inconsistency between WP:Article Size and WP:Summary style
- 10 Unauthorized electronic trails by the fa and id Wikipedia
- 11 Very unsatisfied with process. Could changes be made that would improve Wikipedia ANI? (Better for 'Proposals?')
- 12 RfC: Editinterface rights for template editors
- 13 Behold, A Deeply Important and Profound Critique of Wikipedia
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)
- 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)
- 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)
- 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)
- 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)
- 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)
- "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)
- 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)
- 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)
- 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)
- 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).
- 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] - 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] - Definition of disambiguate at Dictionary.Cambridge.org [UK & US]: "specialized to show the differences between two or more meanings clearly: Good dictionary definitions disambiguate between similar meanings."[9]
Definition of ambiguous: "having or expressing more than one possible meaning, sometimes intentionally: The movie's ending is ambiguous. ... His reply to my question was somewhat ambiguous. The wording of the agreement is ambiguous. The government has been ambiguous on this issue."[10] "having more than one possible meaning, and therefore likely to cause confusion: Many companies are appealing against the ruling, because the wording is ambiguous."[11]:in "Business" tab - Definition of disambiguate at Merriam-Webster.com/dictionary [US]: "to establish a single semantic or grammatical interpretation for".[12]
Definition of ambiguous: "able to be understood in more than one way : having more than one possible meaning; not expressed or understood clearly; doubtful or uncertain especially from obscurity or indistinctness: eyes of an ambiguous color; capable of being understood in two or more possible senses or ways: an ambiguous smile; an ambiguous term; a deliberately ambiguous reply.[13] "Not expressed or understood clearly".[14]:Learner's Dictionary subsite
- 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]
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- @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)
- 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, 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)
- 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)
- 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)
- This reminds me of National Pension Scheme. (Surprise! It's specifically about India.) ╠╣uw [talk] 10:22, 12 April 2016 (UTC)
- Retain the guidance since the lengthy discussion above and below has convinced me that this is useful guidance to editors in encouraging a better and less frustrating experience for our readers. BushelCandle (talk) 06:59, 3 April 2016 (UTC)
- No guidance as I agree wholeheartedly with DoctorKubla. -- Tavix (talk) 12:24, 5 April 2016 (UTC)
- Retain the guidance. I am also irked by the Memorial Hall (Harvard University) example provided by EEng and similar ones – articles about obscure things with common-sounding (i.e. wikt:ambiguous) names do benefit from some extra WP:PRECISION. Doing otherwise easily confuses the readers (as the context is often not enough to quickly conclude what the topic is, and matches displayed in the search box do not provide any hint about the topic) and editors (quite easy mislinking) alike. Of course, case-by-case examination is always welcome, but we do not apply WP:CONCISE at all costs. No such user (talk) 15:35, 6 April 2016 (UTC)
- I, for one, do not call for applying WP:CONCISE at all costs. To the contrary. I call for applying it primarily as a "tie breaker". When considering all other WP:CRITERIA there is no clear answer, then go with the more concise one. It is that simple. But the main point her is that all this is WP:AT consideration; it has nothing to do with WP:DISAMBIGUATION. --В²C ☎ 20:07, 7 April 2016 (UTC)
- Retain the guidance. It's reasonable to note that some titles may be ambiguous or likely to confuse a reader even if they don't exactly match any other titles, and I'm fine with having at least a modicum of text into the guideline to explain this. I understand that some prefer the term "disambiguation" to be defined more narrowly as just the mechanical process of distinguishing between otherwise identical Wikipedia titles, but I don't think that's particularly useful. There can be (and often is) a difference between what's merely technically ambiguous and what's actually ambiguous, and the latter can be a valid consideration when determining the best title for our readers. ╠╣uw [talk] 19:01, 11 April 2016 (UTC)
- Change names The simplest thing to do would be to change the names. — Preceding unsigned comment added by Shinyapple (talk • contribs) 01:22, 30 April 2016 (UTC)
- Retain guidance What useful purpose is served by inherently ambiguous titles, even when this is the sole article? Pincrete (talk) 21:37, 6 May 2016 (UTC)
- Retain Guidance Why would we remove relevant information that helps users avoid pointless move discussions. I have seen time and again pointless move requests to ambiguous titles that fail precision. InsertCleverPhraseHere 03:23, 15 May 2016 (UTC)
-
- And numerous RMs have closed with the opposite result. Calidum ¤ 03:48, 16 May 2016 (UTC)
- 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)
- And numerous RMs have closed with the opposite result. Calidum ¤ 03:48, 16 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)
Discussion (disambiguation)
- More detailed background: Attempts to delete part of the guideline, which was established through standard consensus-building discussion and revision many months ago, are predicated on two obvious fallacies: 1) That "disambiguate" is a made-up Wikipedian neologism for "prevent article title collisions". Check any dictionary; it's a plain-English word meaning "to resolve ambiguity"; doing so to prevent title collisions is simply the most common reason we disambiguate and has never been the only one. 2) That WP:CONCISE is akin to a law, and that the most concise possible name must always be chosen no matter what. Actually read WP:AT policy – all of the WP:CRITERIA are considered, and balanced against each other; the overriding concern is not following any "rule" bureaucratically, but ensuring clarity for readers. The naming criteria "should be seen as goals, not as rules. For most topics, there is a simple and obvious title that meets these goals satisfactorily. If so, use it as a straightforward choice. However, in some cases the choice is not so obvious. It may be necessary to favor one or more of these goals over the others."
The previous debates about this guidance are misrepresented in the the summary in the RfC, which incorrectly paints it as a slow editwar instead of removal, discussion, refinement, acceptance, then much latter isolated attempts to delete it without a rationale. In the original discussions 8 months ago here and here, Red Slash tried to move it into policy itself at WP:AT (rejected), objections were raised about iit original length (it was shortened), and about particular examples it use (removed); the principal objector was Francis Schonken, on the basis of having made a proposal to rewrite AT in ways that would have integrated this and made various other changes (which did not achieve consensus at AT). After revision, the short version of this material was accepted in WP:Disambiguation without incident since that second discussion. This is standard WP:BRD operating procedure, and this revision and resolution process is how consensus is established. By August, the principal objector, Schonken, was removing attempts to reinserted expanded wording and examples [18] but retaining the agreed short version from prior discussions [19], which had already been accepted for two months. It remained uncontroverted for 6 more months, clearly long enough for consensus to be established, especially in a much-watchlisted guideline we use every single day.
It was drive-by deleted in Feb. by Born2Cycle, with a bogus claim that discussion didn't happen and consensus was not been established [20]. This is is part of his years-long, tendentious campaign to promote WP:CONCISE as some kind of "super-criterion" that trumps all other concerns – which WP:MFD has rejected three times in a row: 1, 2, 3. The recent attempt by Dohn joe to delete material was predicated on his unawareness of the February discussion (which is mischaracterizing as being against inclusion when it was not) [21], his misunderstanding of previous discussions (see WT:Disambiguation#Restored content on precision cut from lead, which covers much of what I've outline here in more detail), and more false claims that consensus was not established.
After 8 months of stability, the burden is on would-be deleters to demonstrate what the supposed problem is, and provide actual evidence that WP-wide consensus that such precision-and-recognizability disambiguations are permissible when necessary has somehow disappeared all of a sudden. This RfC, and two editors' PoV against this part of WP:DAB, would undo very long-standing naming conventions that call for this kind of precision-and-recognizability disambiguation, like WP:USPLACE and WP:USSTATION, and fly in the face of years of common sense decisions at RM, like the disambiguation of Algerian Arab (now a disambiguation page) to Algerian Arab sheep, and British White to British White cattle. Per WP:POLICY, the purpose of guidelines is to record actual community best practice, not try to force someone's made up idea about how things should be, like changing the meaning of English words, or preventing RM from doing what RM routinely does. Retaining this does the former, and removing it does the latter, both to pretend the word "disambiguation" doesn't mean what it means, and as to elevate concision above every other criterion, against the clear wording of policy. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 16:04, 25 March 2016 (UTC)
- Comments (since there seems to be confusion): Wait! You mean I just don't like it doesn't mean we can change things just because? How about used in conjunction with and while ignoring all rules.
- We have many policies and guidelines and a single one can not be used in disregard of others. I was under the impression we can not ignore all rules, if it is against consensus, even if we don't like it, unless we can sneak it in under the radar. FYI -- we should not really (according to policy) attempt to make or change policy by using WP:BRD unless we "ignore" the policy on Proposals and Good practice for proposals. The first states: "Proposals for new guidelines and policies require discussion and a high level of consensus from the entire community for promotion to guideline or policy.". The second: "If consensus for broad community support has not developed after a reasonable time period, the proposal is considered failed. If consensus is neutral or unclear on the issue and unlikely to improve, the proposal has likewise failed.".
- Further, the procedural policy explains the process in detail that is located in the second part. A request for comments here is only one part of that process and not a determining factor for an outcome. Some confusion at Wikipedia:How to contribute to Wikipedia guidance#Policy discussions seems to be at odds with policy and may contribute to errors. Policy (Good practice for proposals) states the process for any proposed changes to policy:
- 1)- The first step is to write the best initial proposal that you can.
- 2)- Authors can request early-stage feedback at Wikipedia's village pump for idea incubation and from any relevant WikiProjects.
- 3)- Once it is thought that the initial proposal is well-written, and the issues sufficiently discussed among early participants to create a proposal that has a solid chance of success with the broader community, start an RfC for your policy or guideline proposal in a new section on the talk page, and include the {rfc tag along with a brief, time-stamped explanation of the proposal.
- 4)- A RfC should typically be announced at this policy page (and/or the proposals page, and other potentially interested groups (WikiProjects).
- There appears to be some confusion at Wikipedia:Centralized discussion concerning sequence or location but policy seems clear.
- DAB: Does cover the topic question above as well as WP:AT. Although there are editors that seem to prefer parenthetical disambiguation, or unnecessary use of such on article titles (Britannica style), this has not been established by any broad consensus but more just the opposite according to policy natural disambiguation is preferred and parenthetical disambiguation as a last choice. The etymology of "disambiguation" would be "not unclear" which would be "not clarified". An article title should be precise enough to unambiguously define the topical scope of the article, but no more precise than that.. Recognizable, natural, and concise goes along with this. DAB states: "Disambiguation is also sometimes employed if the name is too ambiguous, despite not conflicting with another article (yet),". Consistency also goes along with these and gives more than one reason why we have Flemish Giant rabbit, Continental Giant rabbit, French Lop, Lop rabbit, Angora rabbit, and so forth. Certainly using the more common name according to references. Common sense is also thrown in there somewhere.
- Conclusion: We should not attempt to change or change policies or guidelines on a whim or by any local consensus. The process is made somewhat complicated to prevent easy changes. DAB and AT do a fine job. I think if editors disagree then they should probably follow the above procedures. Otr500 (talk) 12:39, 26 March 2016 (UTC)
- The portion of WP:DAB that you quote was added a couple of days ago. A clear consensus in support of this recent addition would neatly resolve the difficulty of having an orphaned sentence in the lead that isn't explained in the body of the guideline.--Trystan (talk) 18:50, 27 March 2016 (UTC)
- It's also based on material present in the original, longer version. The WP:GAME here is to keep whittling away at the material in hopes that it can be made to seem out-of-place in its context. If context is restored, it's obviously belongs where it is. This was true 8 months ago, when the context material was originally reduced, on the basis (Francis Schonken's objection) that the example article titles were "unstable". This wasn't actually true then, and 8 months have proven conclusively that it's not true now, so the original rationale to decontextualizing the sentence has evaporated. Better yet, later editors like Dick Lyon have pointed out that entire NC guidelines, like USPLACE and USSTATION, rely on the exact same principle and have for years, so the examples Schonken didn't like almost a year ago were could have been replaced at any time anyway. A challenge against this provision now is a challenge against multiple naming conventions that have been stable for years. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 21:59, 1 April 2016 (UTC)
- 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)
Request for closure[edit]
This RfC was archived by the bot before having been closed. I would suggest that an administrator close it. RGloucester — ☎ 18:28, 23 April 2016 (UTC)
- Shall this long expired RfC ever be closed, or shall it languish here for eternity? RGloucester — ☎ 00:23, 12 May 2016 (UTC)
- All the above effort should have been put into something that actually matters. 217.44.215.253 (talk) 11:57, 16 May 2016 (UTC)
- It matters plenty, since dispute keeps erupting about this, on policy and guideline talk pages, and in RMs, and elsewhere. The real time drain is the recurrent disputation, not the attempt to resolve it with an RfC. In the end, this can only reasonably close one way, or be consensus-reviewed without a close (not all RfCs must have formal closure and consensus determination by common sense doesn't require it) in one way: to retain the guidance. Let's review:
- It's been stable for a year+; the original objections to it were mooted by later tweaks.
- 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.
- Iit codified 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 [22], [23], [24], 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 [25] 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 suddently 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 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)
- 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), but this proposal was already rejected. 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 rational 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.
- 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:
- All the above effort should have been put into something that actually matters. 217.44.215.253 (talk) 11:57, 16 May 2016 (UTC)
-
-
- 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)
- 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)
- 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)
Basic Data Page (A4 or 2xA4 max)[edit]
Ideally, this should be the lead paragraphs of every article, as per WP:LEAD. Efforts to create these pages would be more fruitful if they improved these leading paragraphs instead. Tazerdadog (talk) 04:40, 20 May 2016 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
There are many excellent pages on Wikipedia BUT as an general-knowledge user rather than being an expert in any specific area I find that many articles are so large as to be very difficult to obtain the key data.
The introductory paragraph(s) vary greatly in quality - some are perfunctory, others begin to include quite small details.
When I look at, for example, Florence Nightingale - I don't need ALL 23 pages of the detail; nor do I need all the data for many topics I have had to look at recently. And I believe the assembled expertise of Wiki can build this secondary resource very well and very effectively and to the benefit of the Wiki-world.
SUGGESTION
That major articles and articles over, say, 8 pages are allowed or expected to have a 'Basic Details' section immediately after the introduction. Perhaps an alternative would be to have a section in addition to Article and Talk.
The aim would be to EXCLUDE the references as part of the print and to have a maximum of say two pictures - albeit that one picture can equate to a 1000 words.
I have created pages for this project to see how easy it is. I am very willing to create a page on almost any topic to show that this BasicA4 version is viable and useful.
(A Third alternative would be for this to be somewhat equivalent to the Childs' Wikipedia which has many fewer articles.) JK Joking99a (talk) 09:49, 10 May 2016 (UTC)
- The WP:LEAD is this, or expected to be so. --Izno (talk) 11:17, 10 May 2016 (UTC)
- But LEAD doesn't supply this and isn't even often anything approximating a worthwhile summary - such as an A4 page might offer. How do I push this idea a little further? Joking99a (talk) 10:44, 12 May 2016 (UTC)
- The response to "it's not often good enough" is for you to fix it, or at least tag it with {{lead too short}}. Pushing your idea is unlikely to go anywhere, and a proposal would likely be WP:SNOW-closed, because we already have a guideline which says "write a good summary in the lead", but you are always welcome to develop your idea and then propose it in a WP:RFC. --Izno (talk) 11:14, 12 May 2016 (UTC)
- But LEAD doesn't supply this and isn't even often anything approximating a worthwhile summary - such as an A4 page might offer. How do I push this idea a little further? Joking99a (talk) 10:44, 12 May 2016 (UTC)
For me to 'fix the short or overlong or poor introductions' - I would have to be skilled at all the articles in which I have sometime only a casual interest. And there are a lot of experts in wiki-world who with encouragement would do a better job. Oh well, In the next few weeks 'll put in a few and see what happens. Or, more likely, i'll build up a set and post them in a bunch - wot u think Joking99a (talk) 18:44, 12 May 2016 (UTC)
- The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Designations or qualifiers for authorities cited
In a conversation with a fellow Wikipedian about editing a biographical article, I raised the question, whether it were necessary, when citing an expert on her or his field of study, to identify that field? For instance, if I'm editing the article on Thomas Jefferson, and I want to quote something Dumas Malone wrote about Jefferson, must I refer to him as "historian Dumas Malone", or "biographer Dumas Malone"? I acknowledged the need to describe an authority in connection with forays outside his or her field, such as a novelist writing about an historical figure, or a literary scholar speaking about dance; but I thought it redundant to refer to, e.g., "historian Alfred E. Neuman" when citing Neuman on history.
My fellow Wikipedian thought I was wrong, and said that he had been told by a GA reviewer that he must go even farther, and describe what kind of historian he was citing, as, "twentieth-century historian Alfred E. Neuman", "American historian Alfred E. Neuman", or perhaps "historian of comedy Alfred E. Neuman".
I searched Wikipedia for a policy or discussion concerning this question, but didn't come up with any, so I'm coming to the Village Pump to ask,
- Is there a policy governing this question, and if so, where can I find it?
- If not, is there a talk page or forum, other than this one, where a discussion of this question has happened or would be most appropriate?
- If not, is this the most appropriate forum for such a discussion? (In which case, I'd like to start a new RfC and formulate the question a bit more carefully.)
I look forward to your guidance. J. D. Crutchfield | Talk 18:49, 11 May 2016 (UTC)
- I am unaware of any such policy or guideline so if there is hopefully somebody will correct me. The first thing that sprung to mind was WP:CREDENTIAL but that really doesn't apply here since we are using the phrases like "twentieth-century historian" not as a title but as a qualifier (as you note). I suspect this is just a matter of editorial judgment. It sounds like a good idea to sometimes introduce individuals who are not famous to orientate readers. This helps answer any skeptical "Why should I care what Joe Bloggs' thinks?" questions that might bother them. But this is not a black-n-white rule because sometimes it will be clear from the surrounding text that we're supposed to assume the person has some relative background to qualify their opinion. For example if we're in a paragraph talking about critics reviews of a film, we don't need to introduced each person as a film critic because it will be assumed they are film critics within that context. So any GA reviewer always requiring qualifiers ("film critic") and even secondary adjectives ("Chicago Triune film critic") may have taken the idea too far. This example makes it clear that there's probably not any rules in the form of policy or guidelines on the matter as the solution is context-sensitive. Therefore I am going to say it is not necessary to introduce them with the qualifier, just frequently a good idea. I cannot define what good prose is, but people generally know it when they read it. Try to write good prose and sprinkle in qualifiers as it seems the text demands. As for the best location of a discussion, this too is often unclear. The manual of style talk pages might have been a better spot for this question but since you've started it and it's sort of policy-related (as you've framed it) it seems fine by me here. Jason Quinn (talk) 07:20, 12 May 2016 (UTC)
- Opinions differ on this. I think most heavy content-writers don't qualify obvious names, only those of people who are not the type of expert on might expect in that context. Where the date the person was writing or speaking is significant I prefer to just give that. But some people think qualification is always expected, which it isn't - see FAC, where a range of styles are accepted. I suppose on some very broad subjects there is no "expected" type of expert, so it is worth always qualifying. Another problem is that "historian Dumas Malone" is grating to many British English readers (it should be " the historian Dumas Malone"), so best avoided per whichever policy that is. Johnbod (talk) 14:19, 12 May 2016 (UTC)
- Using "the historian Name Here", "the 20th-century biographer Name Here", etc., is definitely helpful to readers. Too many articles name-drop in a manner that inspires tagging with
{{Non sequitur}}
(the documentation for which I just improved with a mention of the "historian Name Here" vs. "the historian Name Here" distinction). Any time a name is mentioned, its relevance in and connection to the context needs to be clear. WP:GAN and WP:FAC reviewers are not in a position to suggest there's some policy they're enforcing in this regard, but both processes have leeway to collectively by a valid WP:LOCALCONSENSUS the criterial what they expect, as the reviewers doing the actually pretty grueling work involved in these assessments. Clearing up non sequitur name-dropping seems like a perfectly valid criterion to insist on, just as a matter of encyclopedic, non-telegraphic writing. I would not be averse to seeing something about this added to MOS:BIO (in that it has to do with writing style surrounding name presentation), maybe WP:CITE (in that it's connected to attribution, tenuously), or at least the almost-a-guideline essay WP:Writing better articles (in that's it's a how-to-not-make-aritcles-suck matter). PS: To answer the 1-2-3 questions: 1) No. 2) Not that I know of, and probably not recently. 3) This is a reasonable venue, though WT:MOS or maybe WT:CITE would also work — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 15:50, 17 May 2016 (UTC) - You should provide whatever context you believe will be helpful to readers. Frequently, but not always, helping readers will involve a very brief mention of the source's relevance. You do not need to start an RFC or to create any official written rules about this: just go improve some articles.
In general, you should take statements from Good Article reviewers on a standard of trust, but verify. This is because the sole qualification for being a GA reviewer is figuring out how to log in to an account. Most GA reviewers are good or even excellent, but many are tempted to exceed the actual criteria in some respect (a temptation they resist with varying levels of success), and some are making their very first serious contributions to Wikipedia. WhatamIdoing (talk) 02:01, 22 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)
- 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)
- @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)
- 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, 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—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 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—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)
- 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)
- 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—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)
- 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-outNeither I thought on a basic level this was to be decided on a infobox by infobox basis with local consensus, and for that matter, on a field by field basis. I don't see a reason to force opt-in across the board, if the infoboxes for particular projects prefer opt-out. If a particular field causes trouble on enwiki, the maintainers of that infobox can just remove Wikidata from that field till consensus develops. In some cases, Wikidata may just never be suitable. Each infobox can decide to do things as their needs dictate, and it should be easy enough in most cases to include a single parameter to cut off (i.e. opt out) of any wikidata population. -- ferret (talk) 12:21, 16 May 2016 (UTC)- Continue opt-out: However, the method to opt out needs to be easier (as suggested) than by filling in ALL the empty params. A nice simple
|wikidata=no
(or similar) should suffice. As an encyclopedia, we have a duty to provide data that's both complete and accurate. Wikidata gives us this in spades, and it should be rare that we need (not want) to exclude it.Fred Gandt · talk · contribs
12:26, 16 May 2016 (UTC)- it should be rare that we need (not want) to exclude it—that statement needs backing up, and there's a lot more to editorial discretion that IDONTLIKEIT. There's little more to indiscriminate automatic inclusion than ILIKEIT. Curly Turkey 🍁 ¡gobble! 12:56, 16 May 2016 (UTC)
- I didn't say it will be or is rare; Do you disagree that it should be rare? Whether we LIKEIT or not, if the (Wiki)data is applicable, verified and accurate, we should be including it (accepting what should be rare exceptions, when editorial discretion takes over).
Fred Gandt · talk · contribs
14:13, 16 May 2016 (UTC)
- 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).
- 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)
- Broadly, opt-out. In response to each of CT's points below:
- 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.
- "Long lists of parameters" is strawman fallacy--correct coding of an infobox prevents this as an issue.
- 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.
- 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)
-
- 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:
- 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)
- 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)
- 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)
- 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 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.
-
- 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)
- @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)
- 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)
- "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)
-
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- It would prohibit the automatic inclusion of such maps, which is the real benefit here. --Rschen7754 00:44, 19 May 2016 (UTC)
- "Opt-in" doesn't "prohibit" anything. Curly Turkey 🍁 ¡gobble! 00:23, 19 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)
- Thank you, that's a great argument for opt-in. ;-) Ed [talk] [majestic titan] 18:19, 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)
- 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)
- @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)
- I don't follow — how? Carl Fredik 💌 📧 19:14, 17 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. —swpbT 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 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)
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. [26][27] Then Freitjes changed Infobox Book, without discussion, so that it fetched data from Wikidata. [28] In the meantime a Wikidata bot had fetched the genre from the Italian Wikipedia, [29][30] 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...
- @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
- @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)
- 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)
- 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
- 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. [26][27] Then Freitjes changed Infobox Book, without discussion, so that it fetched data from Wikidata. [28] In the meantime a Wikidata bot had fetched the genre from the Italian Wikipedia, [29][30] 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)
- 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)
- 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)
-
-
-
-
-
-
-
-
-
- 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)
- 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
- 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
- Sarah, You would only need to add
- RexxS, thank you for your suggestions. The problem with
- 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)
-
-
-
-
-
-
-
-
- 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: 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)
- "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.
- @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)
- 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
- 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)
-
- 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)
@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: 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)
- 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: 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)
@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)
- 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: 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)
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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Template:Infobox person/Wikidata was only intended as a test-bed to try out methods of data-awareness. Nevertheless setting
-
- 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)
- 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)
- 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.
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
|
-
-
- @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)
- 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)
- The specialties are typically based on the ICD10 which groups diseases by them. Doc James (talk · contribs · email) 16: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)
- 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)
- 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)
- 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)
- "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)
- A solution that the Swedish Wikipedia employs is to bring along all references on Wikidata
- 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)
- 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)
ArticlePlaceholder
Just this week a variation of what is proposed here is made live on other language Wikipedias. See
See live examples as follows -
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)
Separate pages created by new editors from pages created by established user
All pages created by anybody is listed in this page:
https://en.wikipedia.org/wiki/Special:NewPages
The white background also causes eye strain, as people check the name of the page creator
We must separate this Special:NewPages into three parts.
Page A)- This page will only list new articles created by administrators, arbitrators, check users and users with auto patrolled rights.
Page B)- This page will list new articles created by those who don't have extended confirmed rights. All pages created by new users will be listed here.
Page C)- The third page will list articles created by those who have extended confirmed rights but are not auto patrolled, administrator, oversight.
This will make the job of new page patrollers easier as they will have maximum focus on Page B. --223.231.7.91 (talk) 11:40, 18 May 2016 (UTC)
- B) already exists. Click "Recent Changes". See the menu at the top? Click "New Editors Contribs". Now, click the box that says "Only show edits that are page creations" and then click the search button. Or click here. --Jayron32 12:13, 18 May 2016 (UTC)
- I see no reason to separate B from C; nor to separate A from pages belonging to B and C which were reviewed by the New Page Patrol. All pages which are B or C, but weren't checked by NPP, can be found at this link. It also seems likely, although I didn't actually check this out, that you could change the background colors using some simple code on your css page. עוד מישהו Od Mishehu 10:05, 19 May 2016 (UTC)
- You way want to look at special:NewPagesFeed. You can choose only to see pages in C. Also the layout is quite friendly. Happy Squirrel (talk) 14:21, 19 May 2016 (UTC)
- Arbitrator aren't a "group" so this wouldn't be a valid target (they are all currently admins though). — xaosflux Talk 00:21, 20 May 2016 (UTC)
I actually think this is very important — specifically as part of the toolset for users at Wikipedia:New pages patrol.
Also, unfortunately NPP does not consider paid editing, which this type of tool really could take a dent to. Carl Fredik 💌 📧 21:29, 24 May 2016 (UTC)
Promote WP:Tagging pages for problems to guideline
- Subject: Promote the essay to Guideline Wikipedia:Tagging pages for problems
- Alt subject: Promote essay WP:TAGGING to Guideline
- Proposer: 009o9 (talk · contribs) 009o9Disclosure(Talk) 19:57, 20 May 2016 (UTC)
- Status: The essay is stable, 19-20 page reads per day
- Related articles: WP:Template messages, WP:Template messages/Disputes, WP:Responsible tagging and WP:Tag bombing
- Related known current discussions:
- Help talk:Maintenance template removal
- Ping interested participants:@SilkTork, Pincrete, Sphilbrick, Lemongirl942, SilkTork, Debresser, Fuhghettaboutit, and Sphilbrick:
- (recently closed and related RfC)
- Ping interested participants:@Howicus, Gronk Oz, Cullen328, Elmidae, DESiegel, Keith D, GenQuest, GenQuest, Mandruss, BethNaught, ColinFine, Ajraddatz, Cordless Larry, Nizolan, Be..anyone, Fritzmann2002, Gmcbjames, JohnCD, Happysquirrel, WhatamIdoing, SubSeven, Waggers, APerson, LT910001, Aoziwe, Doc James, MSGJ, Fences and windows, Mdann52, Mr. Stradivarius, and Voidxor:
- Help talk:Maintenance template removal
- Essay creation date: 05:35, 3 October 2013 diff
- Essay last edited: 15:09, 19 April 2016 diff
- Statement: I contend that Wikipedia:Tagging pages for problems (aka WP:TAGGING) (current revision, April 19, 2016) is the prevailing consensus on the placement and removal of maintenance tags and the essay should be promoted to Guideline. Minimally, WP:TAGGING provides that tags without accompanying talk page discussion may be summarily removed. We would no longer have to try to guess what the objection is and normal WP:BRD would apply. 009o9Disclosure(Talk) 15:16, 21 May 2016 (UTC)
Support promotion of essay
- As someone who does a fair amount of tagging, I've noticed that how to handle those tags from a conduct perspective is a frequent source of tension with fellow editors. It would be extremely helpful to have a guideline on this subject. I have cited this essay a number of times in disputes over tagging practices and I can't remember a single time when the other editor said there was something wrong with it. I do believe that the essay represents at least a rough consensus of the community. I'm not watching this page so please ping me if you want my attention. --Dr. Fleischman (talk) 19:10, 20 May 2016 (UTC)
- Support -- I can't say I 100% agree with this (I see most drive-by tagging as a problem, see my user page). But I like that this encourages/requires discussion and explanation (by both the tagger and the tag remover). Hobit (talk) 15:51, 21 May 2016 (UTC)
Oppose promotion of essay
- No. There are enough make-work contributors who like to leave their mark without giving their mission an elevated status. It would be much better to have an essay saying that people should focus on improving an article and engaging with others on the talk page, and promote that to a guideline. Johnuniq (talk) 23:23, 20 May 2016 (UTC)
* Opposed (in current state) I'll start my comments by emphasizing that those who have contributed to the essay have done a nice job and I think it is close to acceptable as a guideline. I also should acknowledge that I am in favor of a different approach to the problem—namely a system in which editors who add tags would volunteer to follow up on the tags, ideally with a notification system built-in. However, I recognize that we don't yet have consensus for that approach and even if we do it may take quite some time before it can be implemented, so an alternative approach such as this may well be a good stopgap and might even coexist for the long-term. I'm struggling to articulate my main concern, but I think my main concern is the essay doesn't acknowledge or articulate the fact that while brand-new editors, even anonymous editors about to make the first edit, are often available to address maintenance tag issues, many of them are not yet sufficiently versed in Wikipedia policies and guidelines to know whether their attempts to address the tags are adequate. I'd like to see a little more discussion explaining that, for example a brand-new editor might well be able to add references to an article that needs references, but might not be the best person to determine whether the added references are now adequate.
In general, this essay suggests that an editor seeing a maintenance template is encouraged to address it and then remove it. I'd prefer a slightly different model. To oversimplify, I'd say that an experienced editor, seeing a maintenance template, is encouraged to address it and remove it. A relatively new editor, seeing a maintenance template, is encouraged to address it, and if they think they have adequately addressed it, they should leave a note on the talk page indicating their belief, and ask for feedback. I don't want to micro manage but I'd be happy with a note that says "I believe I addressed maintenance tags X, and if I don't hear otherwise in three days, I plan to remove it". Some might feel more affirmative response is required but that's a detail for discussion. My main concerns can be illustrated with two examples - 1 a relatively new editor might see a copyright concern and think that changing a few words cures the problem 2 a relatively new editor might see a need for more references, add a couple references to IMDb and think they are done.
While the wording I am hoping for is not quite trivial, I am quite happy with much of what is in the essay and I would be prepared to support conversion to a guideline if there were more guidance for relatively new editors.--S Philbrick(Talk) 01:16, 21 May 2016 (UTC)- I misread - I thought the proposal was to promote Help:Maintenance template removal to a guideline; my comments were directed at that page.--S Philbrick(Talk) 13:09, 21 May 2016 (UTC)
Comments
- Proposer comment: The essay was proposed for promotion on its talk page in December 2013 (@DrFleischman:), but never followed through on.diff There is a new Help page being curated at Help:Maintenance template removal; however, there is no official guidance concerning placing maintenance templates in the first place. Thus, the Help page (concerning removals) may be premature and lacking foundation. 009o9Disclosure(Talk) 17:38, 19 May 2016 (UTC)
- Note Please discuss defects or problems you discover with the essay in this forum, since a vote has already been recorded, changing the content is much the same as changing another editor's vote. We are voting on this (revision, April 19, 2016) up or down. Changing the essay can occur after the RfC has closed, so we don't have to keep pinging voters to see if their vote still stands. I've requested page protection for the essay to avoid the problem. 009o9Disclosure(Talk) 21:22, 20 May 2016 (UTC)
-
-
- No we are not voting on that version. I made one change here at 20:13, 20 May 2016 and a second change here saying the same thing at 00:25, 21 May 2016. There was only one plus !vote before then, and I have notified that person; the changes would not have affected the oppose !vote but I have notified them anyway. You work as a paid editor and it looks very bad for you to be arguing against a change that affects your paid editing. Just knock it off. Jytdog (talk) 01:39, 22 May 2016 (UTC)
-
- Comment @Johnuniq and Sphilbrick: The reason I've proposed is to take the (baby) first step and require that tagging editors open a talk page discussion detailing their concerns, or have their tag summarily removed for cause. As it stands now, some editors feel that their header tag should be sustained in perpetuity until the other editor guesses what the problem(s) is. Finding consensus and then adding it to an essay futile, a more authoritative location is needed to discuss implement improvements. 009o9Disclosure(Talk) 04:21, 21 May 2016 (UTC)
- Comment - I am concerned about the one-size-fits-all approach to the essay. A lot depends on which specific tags we are talking about. Some tags are so self-explanatory that requiring a talk page discussion to explain why they were added is pointless... While others definitely do need explanation. Blueboar (talk) 17:23, 21 May 2016 (UTC)
- @Blueboar: My contention is that an edit summary like, "Added XYZ tag (TW)" is not sufficient in almost every case. The maintenance templates are grouped at WP:TC, so the scope of which template are not subjective (or are self explanatory) can be noted as the guideline matures. My guess is that the shortlist would be groups of templates that are exempt from the talkpage requirement. Nothing is set in stone, but as Wikipedians, we are supposed to include the who, what, where, when and how to the best of our ability. I think this rule should also apply to maintenance templates, especially Neutrality templates. Header tags only provide the "what" the objection is not the "where" it is. 009o9Disclosure(Talk) 18:09, 21 May 2016 (UTC)
- Summary removal of inexplicable tags is already the rule for neutrality-related tags (see the /doc pages for the templates). I also disagree with your claim that "in almost every case" the tag isn't self-explanatory, or at least nearly so. Most source-related templates (e.g., {{fact}}, {{unref}}, {{failed verification}}, {{Please check ISBN}}...) are obvious enough, and some general templates (e.g., {{cleanup-reorganize}}, {{linkfarm}}...) sometimes might benefit from explanation, and sometimes are easy enough to figure out. Those that tend to benefit the most from explanation normally require a
|reason=
parameter or already have template-specific rules in the documentation about how and when to provide explanations. WhatamIdoing (talk) 04:28, 22 May 2016 (UTC)
- Summary removal of inexplicable tags is already the rule for neutrality-related tags (see the /doc pages for the templates). I also disagree with your claim that "in almost every case" the tag isn't self-explanatory, or at least nearly so. Most source-related templates (e.g., {{fact}}, {{unref}}, {{failed verification}}, {{Please check ISBN}}...) are obvious enough, and some general templates (e.g., {{cleanup-reorganize}}, {{linkfarm}}...) sometimes might benefit from explanation, and sometimes are easy enough to figure out. Those that tend to benefit the most from explanation normally require a
- @Blueboar: My contention is that an edit summary like, "Added XYZ tag (TW)" is not sufficient in almost every case. The maintenance templates are grouped at WP:TC, so the scope of which template are not subjective (or are self explanatory) can be noted as the guideline matures. My guess is that the shortlist would be groups of templates that are exempt from the talkpage requirement. Nothing is set in stone, but as Wikipedians, we are supposed to include the who, what, where, when and how to the best of our ability. I think this rule should also apply to maintenance templates, especially Neutrality templates. Header tags only provide the "what" the objection is not the "where" it is. 009o9Disclosure(Talk) 18:09, 21 May 2016 (UTC)
-
-
-
- @WhatamIdoing:The WP:TAGGING essay already differentiates between non-obvious and obvious tags in the first section. Primarily, we are discussing header tags here, I'm a big fan of inline and section tags, they are concise and you simply remove them as you fix the content. In fact, I feel that narrowing the scope with inline and section should be the BRD process for tags. I've never heard of a case where an editor goes to war over a section or inline tag. Header tags on the other hand, are just as often placed as a badge of shame, some editors get a kick out of sustaining them while not disclosing the problem. Generally, this is from a disdain for articles where the subject creates useful products instead of teaching at a college or writing best-sellers. Funny thing about the /doc pages for templates, they can be edited and the edit will not show in the history for the complete template.diff and history 009o9Disclosure(Talk) 08:35, 22 May 2016 (UTC)
-
-
- Johnuniq There already is an essay like the one you describe (WP:RESPTAG). It is quite extensive and probably would not stand a chance of promotion at this time, but it could be cited and content imported into the guideline. Seems like promoting WP:TAGGING is the preliminary step to addressing your concerns. With good consensus here, WP:RESPTAG could be put up for RfC later.009o9Disclosure(Talk)
On the use of template Preloaddraft
My attention was drawn to {{Preloaddraft}} in a thread on WP:VPT. The template turns a conventional redlink into what looks to me like hell on wheels: puts you in draft space, as far as I can see, and inserts ... stuff ... into the new article. See, for instance, the redlinks at Wikipedia:WikiProject Missing encyclopedic articles/Art of the Middle East. Call me old fashioned, but I like it when redlinks yield a blank page in article space. Do we have any policy as to when this template can/should be used. I can just about understand it for an editathon - the documentation speaks of this. But as a general implementation, it seems to make wikipedia editing more scary (albeit in the hope that authors will follow a particular framework for an article) than less scary. --Tagishsimon (talk) 22:39, 19 May 2016 (UTC)
- Why don't you just ask Evolution and evolvability about his goals for this new template? You might also want to look at Special:WhatLinksHere/Template:Preloaddraft, to see how it is being used. WhatamIdoing (talk) 04:31, 22 May 2016 (UTC)
-
- Thanks Tagishsimon for your questions about the {{Preloaddraft}} template. My original intention when I wrote it was for use in editathons/wikibombs, when often a lot of first-time users are trying to edit. I'd previously found that novices typically stated feeling intimidated by a blank edit box, and often couldn't work out how to add in reference lists, or infoboxes, or basic sections. In general I've had good feedback from new users. Having a basic structure to start from seems to help give a basic standard of what sort of information is expected or e.g. a scientist or artist. My aim is for it to provide general structure and aid to novice editors, and that more experienced users would just blank the page if they wanted to. I'd be happy for some suggested guideline of when to avoid using it if it turns out to be getting in the way in other circumstances. T.Shafee(Evo﹠Evo)talk 11:16, 22 May 2016 (UTC)
RfC: Proposed draftspace deletion
Non-AFC drafts in draftspace have no G13 method for automatic deletion or for any review at all. As such, there are hundreds of stale drafts that haven't been edited in a long time. Attempts to add G13 or other criteria have been repeatedly and expressly rejected so instead these pages take up a lot of time at WP:MFD where deletion is somewhat routine. I'd like to propose that we allow for a new draft proposed deletion system with the following rules:
- Draftspace drafts that are not tagged with AFC that haven't been edited in six months can be considered.
- If the deletion is proposed, it would go into a dated category similar to Category:Proposed deletion for at least one month at which time any one can remove the proposal for any reason whatsoever. This is similar to the 5 month notification of Category:AfC G13 eligible soon submissions with a month before G13.
- After a month with no deletion, an admin can then decide if it's worth deleting.
I've added header for support as is and a separate support in case people support the general concept but disagree on the six month/one prod timeline. -- Ricky81682 (talk) 21:34, 20 May 2016 (UTC)
Support as is (Proposed draftspace deletion)
- support i don't see any harm arising from this very gentle proposal, and having this path available will hopefully reduce the disruption that we have had from people MacGyvering ways to delete stale drafts outside the MfD pathway. I don't understand why having a more efficient way to clear very stale drafts is very important to some folks, but it is. So let's reasonably accommodate them. Jytdog (talk) 01:33, 23 May 2016 (UTC)
Support generally (Proposed draftspace deletion)
- I agree that drafts located in draftspace should have a reasonable expiration date... After which they are removed from draft space for "lack of interest". I would peg it at one year with no substantive edit. However, it can't be a simple "keep" or "delete" determination... Because there is also the option to "userfy" (moving it out of Draftspace and into Userspace... if there is an editor willing to adopt it). Blueboar (talk) 21:56, 20 May 2016 (UTC)
-
- After the proposed draft is removed, I don't think there's any rules about what to do. It can go to userspace or mainspace or wherever else people want. This is just more of a single veto to deletion than MFD's consensus requirement. -- Ricky81682 (talk) 22:03, 20 May 2016 (UTC)
-
- But the determination about what to do with the draft has to be made before it is removed... Thus the need to outline the options. Blueboar (talk) 22:39, 20 May 2016 (UTC)
- I don't understand. There is no determination. Someone could remove it and just keep it there. The creator could be active but the draft is not. This is not like userspace where we check both the page and the editor so I don't see why anything more has to be done. -- Ricky81682 (talk) 22:42, 20 May 2016 (UTC)
- Maybe I don't understand what you are proposing... How can you remove something from Draftspace and yet still keep it there? I thought the proposal was to institute some form of quick review of unfinished pages that have been sitting in Draftspace with no one working on them. If so... Then we need at least three options for the reviewer to choose from: 1) Delete it (due to the fact that since no one has worked on it, there is obviously a "lack of interest in having an article on the topic", 2) Keep in Draftspace for further work by the community, or 3) move to Userspace for an individual to work on personally. These are mutually exclusive choices. Blueboar (talk) 00:03, 21 May 2016 (UTC)
- No, it's like proposed deletion: a quick review of pages that people think will never be something usable and that no one is working on. The lack of finishing is not a reason to delete something to me. I have a half dozen drafts I've started and haven't finished. I still work on them but if someone else took them to MFD, I'd argue to keep them and if proposed for deletion, I'd remove it. However, other people leave content there and that's it. Why should be done? -- Ricky81682 (talk) 04:14, 23 May 2016 (UTC)
- Maybe I don't understand what you are proposing... How can you remove something from Draftspace and yet still keep it there? I thought the proposal was to institute some form of quick review of unfinished pages that have been sitting in Draftspace with no one working on them. If so... Then we need at least three options for the reviewer to choose from: 1) Delete it (due to the fact that since no one has worked on it, there is obviously a "lack of interest in having an article on the topic", 2) Keep in Draftspace for further work by the community, or 3) move to Userspace for an individual to work on personally. These are mutually exclusive choices. Blueboar (talk) 00:03, 21 May 2016 (UTC)
- I don't understand. There is no determination. Someone could remove it and just keep it there. The creator could be active but the draft is not. This is not like userspace where we check both the page and the editor so I don't see why anything more has to be done. -- Ricky81682 (talk) 22:42, 20 May 2016 (UTC)
- But the determination about what to do with the draft has to be made before it is removed... Thus the need to outline the options. Blueboar (talk) 22:39, 20 May 2016 (UTC)
Support: I believe WP:WEBHOST does apply here. Also, could someone provide diffs for an editor being chased away for their stale draft being deleted, I'm sceptical. I have, on the other hand, seen some editors jump back into the game and resume editing a draft that was stale because they did care about it. The point here is that if it's truly stale, they obviously DON'T care about it. I scrolled down the MusikBot stale draft report and clicked on three drafts completely at random. I found: Draft:Rusty Anderson Afternoon EP II, Draft:Ishan Sinha, and Draft:Hatim. This is at least the second time I have looked at a random sampling of these stale drafts and come up with NOTHING worth keeping simply for the sake of keeping. Those three articles don't even have a proper paragraph between them, much less potential for a mainspace article. Three more at random: Draft:Karl Gebhardt, Draft:Prime Lending, and Draft:Davula Estates Limited. Same problem. Authors aren't going to driven away by us deleting a BLANK draft, or one with only ONE sentence. This is cruft that we do not need cluttering categories, backlogs, search results, etc. My only proposed change to the proposal is to extend from 6 months to 1 year - the reason for this is that looking at the 6 Drafts and the contributors, it appears there's a small chance that the authors might want to come back to them (especially if they thought it might be deleted). Chrisw80 (talk) 19:37, 21 May 2016 (UTC)
- The entire point of Draftspace is for the broader community to work on the draft. If no one in the broader community is interested in working on it, we should move it out of Draftspace. This does not mean, however, we have to delete the draft. It should be moved into the original author's Userspace, if there is even a remote chance of a potential that it might someday make a valid article. Blueboar (talk) 20:37, 21 May 2016 (UTC)
- We've had policies for years that if a draft isn't going anywhere, it can go to MFD and be discussed there. The consensus has been for deletion overwhelmingly. The point is userification is beyond a minute occurrence. If you want to oppose all deletions, then go to MFD and argue that every draft should be userified back to the user but I'm certain you won't get a lot of support for that. That's how consensus works: you have to actually convince people of your proposal not just state it and then argue it at the policy stages to create procedural hurdles for everyone else. It's not like the option is "this proposal or these pages don't get deleted." These pages are already being deleted. I'm just trying to find a way to avoid either flooding AFC with 5000 more pages as people suggest or MFD with more pages. -- Ricky81682 (talk) 20:52, 21 May 2016 (UTC)
- Blueboar, I'm not sure I understand you here. That a year old draft with no content should be saved? That a two year old draft about someone who will obviously NEVER meet WP:GNG should be saved? What is a "remote chance"? As Ricky81682 points out, the matter of the deletion of abandoned and poor-quality drafts has already long since been settled. The matter is whether the author ends up at the dumping ground that is MfD trying to salvage their draft (dealing with confusing terminology, contentious arguments, etc.), or they end up with a PROD style warning that gives them an easy and quick chance to continue working on their draft without all that. This idea seems perfect to me to keep potential contributors, while still dealing with the stale draft problem. Chrisw80 (talk) 21:22, 21 May 2016 (UTC)
- I agree that most of the drafts in the backlog are likely to be deleted... But I doubt this will be the case with every one of them. With thousands in the list, there are bound to be at least a few that are worth keeping (perhaps in Userspace). I agree that we need a quick and efficient review process... I am just not sure a G13 like process is the right one. Blueboar (talk) 22:27, 21 May 2016 (UTC)
- Hi Blueboar, I think I see what you're getting at now.. I agree, there is likely some of the drafts in the backlog have merit and shouldn't be deleted. The process Ricky81682 is describing is more similar to the PROD process, rather than the CSD G13 process. He is simply offering G13 as similar to the stale aspect of the drafts, not the speedy deletion part of it. He's talking about a full month where the "DraftPROD" tag would be present on the page and the author (or anyone else) can remove the tag at any time during that period, no big deal, no questions asked. It actually seems quite reasonable to me. Chrisw80 (talk) 23:47, 21 May 2016 (UTC)
- Honestly, it's more akin to Category:AfC G13 eligible soon submissions to me. You have a month to review them (although I imagine them by individual date is better). Create a rescue task force and split it by letter or whatever to double/triple/quadruple review them, I don't care. It's not like I'm going to mass nominate 5000 pages in one day. -- Ricky81682 (talk) 00:38, 22 May 2016 (UTC)
- Hi Blueboar, I think I see what you're getting at now.. I agree, there is likely some of the drafts in the backlog have merit and shouldn't be deleted. The process Ricky81682 is describing is more similar to the PROD process, rather than the CSD G13 process. He is simply offering G13 as similar to the stale aspect of the drafts, not the speedy deletion part of it. He's talking about a full month where the "DraftPROD" tag would be present on the page and the author (or anyone else) can remove the tag at any time during that period, no big deal, no questions asked. It actually seems quite reasonable to me. Chrisw80 (talk) 23:47, 21 May 2016 (UTC)
- I agree that most of the drafts in the backlog are likely to be deleted... But I doubt this will be the case with every one of them. With thousands in the list, there are bound to be at least a few that are worth keeping (perhaps in Userspace). I agree that we need a quick and efficient review process... I am just not sure a G13 like process is the right one. Blueboar (talk) 22:27, 21 May 2016 (UTC)
Support Any draft in draftspace should be subject to WP:NOTWEBHOST. They should have an expiration date, like WP:AFC drafts. Tom29739 [talk] 21:25, 21 May 2016 (UTC)
- Support by all means, certainly something I've considered before. SwisterTwister talk 22:50, 21 May 2016 (UTC)
- Support – We are not a web host. There is no reason to keep stuff (potential junk) around like this for ages. An expiration date is required. If an editor really does come back after 20 years to work on some draft, he can always request a copy of it via WP:REFUND. Deletion is not permanent, after all. I think the opposers haven't realised this. RGloucester — ☎ 23:00, 21 May 2016 (UTC)
- Support, hosting large amounts of poorly-reviewed content eternally is a problem in itself. I see editors concerned that there might be a hidden gem in these abandoned drafts. I don't see them volunteering to patrol the huge ever-growing backlog for copyright violations, attack pages and the like. Those could of course already be speedied, but discovering copyvios takes a lot of effort, effort nobody will want to spend on abandoned drafts. Getting rid of all that have been inactive for an extended amount of time will at least minimize the problem. Huon (talk) 12:07, 22 May 2016 (UTC)
- Support - I do a bit of work on G13, and when I began it was because there was a backlog of several thousand, and another editor asked for help in reducing that backlog. It's tedious, and time consuming, and I do it as part of my gnomish morning activity. Probably 50% of the drafts can be nominated for deletion in under 20 seconds (blank, foreign language, "hi", obvious personal bios of non-notable teenagers, etc). Another small percentage are the other end of the spectrum, where, within 20 seconds you can ascertain the subject meets the notability criteria, and you postpone the G13 (it's a town in India, which just doesn't have any citations, or you click on the Scholar search and see the professor has several articles cited thousands of times, etc). Another 25% or so are obviously simply advertisements. Another 15% or so take a minute or so to check the references or the search engines, after which you can make a determination of whether or not to G13. After which an admin then makes one last check. Not sure what the issue is with applying this same procedure to these other types of drafts. The article's creator would receive a notice a month out, and they have that month to have input on whether or not they still intend to work on the article. Then they can still have it reinstated if they were spending a couple of months in the outback and missed the notice. Onel5969 TT me 22:21, 22 May 2016 (UTC)
- Support. I don't think this is the ideal solution (I'd prefer new speedy deletion criteria for the worst, and blanking or redirection for the rest), but this is workable, and the current situation - massive overload and continuous bickering at WP:MFD - is far worse. —Cryptic 04:16, 23 May 2016 (UTC)
Oppose (Proposed draftspace deletion)
- Oppose - I would like to see some material justification for deleting these things before we create a new process and then staff that process. What's the harm in allowing things to accumulate in draft space? Seems like there could even be some good in it. ~Kvng (talk) 22:41, 20 May 2016 (UTC)
-
- Why do we have G13? Why not let the entire draftspace accumulate with tens of thousands of pages that are never going anywhere and completely choke AFC to the point of uselessness? WP:WEBHOST is one reason and not actually enforcing it leads to things like Wikipedia:Miscellany for deletion/Draft:Eligible Class Records where editors just use Wikipedia to host all their content. -- Ricky81682 (talk) 22:45, 20 May 2016 (UTC)
-
- I think we may have some confusion in terminology... pages that falls afoul of WP:WEBHOST are unlikely to actually be located in Draftspace to begin with (because the are not drafts). Blueboar (talk) 23:23, 20 May 2016 (UTC)
- I don't know why we have G13? Do you? Still looking for a reason these things need to be deleted. WP:WEBHOST doesn't seem to be it. ~Kvng (talk) 14:03, 21 May 2016 (UTC)
- We have a G13 so we don't have a million pages of junk to go through at AFC. There's probably a thousand pages a day that are deleted. Do you actually think the best way for us to actually work on creating a feasible encyclopedia is to keep what would possibly be a quarter million pages a year of old pages that no one is working on? We'd be approaching a million old pages from draftspace/wikipedia talkspace since the start if we didn't have it. Do you think AFC could function? Do you actually think anyone would want to review a single page if they had to go through thousands of pages of junk from years and years ago? -- Ricky81682 (talk) 20:58, 21 May 2016 (UTC)
- You certainly can't keep all your physical junk forever but I guess I'm thinking outside the box here and asking what's the problem with keeping all drafts forever? It just sits there. It doesn't hurt anyone. It is cordoned off from mainspace that we'd like to keep tidy. If you think about it, the data storage requirements for text are small; With a million 1000 byte articles a year, it will take 1000 years to fill a hard disk. No one at AfC or anywhere else has to sort through any of this stuff. Editors can pull out bits using search. Authors may never return to finish an aborted draft but if they do, it will be waiting for them where they left it - friendly. What's not to like? ~Kvng (talk) 23:58, 21 May 2016 (UTC)
- You want to propose, go right ahead. Most people find the goal of creating an encyclopedia is more likely to occur if we didn't have tens of thousands of extra pages of junk lying around. Your arguments are the same things I had a decade ago when we raised our standards for GNG: we should be more concerned about driving away potential "contributors" than about the people who are here and who do work here in terms of the clean-up and other projects. Either way, what does that have to do with this proposal? These pages are subject to deletion at MFD anyways. This is like opposing WP:PROD because you want to argue about some subset of WP:GNG or other notability guidelines. -- Ricky81682 (talk) 00:11, 22 May 2016 (UTC)
- You certainly can't keep all your physical junk forever but I guess I'm thinking outside the box here and asking what's the problem with keeping all drafts forever? It just sits there. It doesn't hurt anyone. It is cordoned off from mainspace that we'd like to keep tidy. If you think about it, the data storage requirements for text are small; With a million 1000 byte articles a year, it will take 1000 years to fill a hard disk. No one at AfC or anywhere else has to sort through any of this stuff. Editors can pull out bits using search. Authors may never return to finish an aborted draft but if they do, it will be waiting for them where they left it - friendly. What's not to like? ~Kvng (talk) 23:58, 21 May 2016 (UTC)
- We have a G13 so we don't have a million pages of junk to go through at AFC. There's probably a thousand pages a day that are deleted. Do you actually think the best way for us to actually work on creating a feasible encyclopedia is to keep what would possibly be a quarter million pages a year of old pages that no one is working on? We'd be approaching a million old pages from draftspace/wikipedia talkspace since the start if we didn't have it. Do you think AFC could function? Do you actually think anyone would want to review a single page if they had to go through thousands of pages of junk from years and years ago? -- Ricky81682 (talk) 20:58, 21 May 2016 (UTC)
- Oppose. To date, the instigators of the recent 2015-16 drive to clean up all old drafts, along with other pages swept up in the drive, have failed to present, at MfD or elsewhere, a coherent explanation of how they discriminate useful versus useless material. This proposal is just a proposal for them to continue mass deletion but without review. Prod was intended to depend mostly on page watchers noticing, and draftspace pages don't have watchers. If Ricky really wants to help the project by processing old drafts, I suggest that he classify, or categorize them, preferably by taggings, with one category containing all the pages he would see deleted. Then, if and when he is confident that the category is accurate, propose deletion of the contents.
- Personally, I think that the effort is a net negative. DraftSpace was supposed to help the project, not create more work than it is worth. There is actually no reason to delete, or even process old drafts that don't violate anything at WP:NOT. --SmokeyJoe (talk) 00:43, 21 May 2016 (UTC)
- You always suggest other nonsensical sorting scheme or "put them to AFC" or other projects that everyone else opposes, all of which in the end is the same solution: demand that other people do more nonsense you create while you sit back and just oppose any review of these drafts. As of this date, there are over 7000 old drafts that have not been edited in six months or more. Of those, the people who actually want to review and work on them would like to simply delete the ones that aren't going anywhere. Are you actually working on these? Have you moved any to mainspace? No one is out there in some lunatic craze to just wildly delete every page here. If you want, remove every single proposed deletion and just yell and scream some more that AFC or me or someone else should jump through the 50th hoop you've made up to save one sentence someone created in 2013 and never bothered with again. I set up the entire Abandoned Drafts project the way you suggested and then you ignored it. Otherwise, we continue on with these at MFD where you again oppose deleting these arguing that "G13 should handle these" and then oppose G13 handling then and then watch as AFC explodes that they don't want them and so on and so on. Is literally the only thing you do all day make up new kinds of bureaucracy so you can sit around and proclaim victory because something isn't done? I mean, if we go with your new "tag them with AFC" (after months of opposing the same thing), then in six months there will be 7000 new items in Category:G13 eligible AfC submissions. Ignoring this backlog so it's miserable that no one wants to touch is surely your end goal here. -- Ricky81682 (talk) 01:51, 21 May 2016 (UTC)
Oppose. Support SmokeyJoe's proposal that all these pages be organized and categorized instead. 166.176.56.99 (talk) 03:05, 21 May 2016 (UTC)WP:BANNED — JJMC89 (T·C) 07:48, 21 May 2016 (UTC)- No. 1) There's no reason to do this. 2) There's at least one good reason to not do this, in that it chases away contributors. I suspect that there is a perfectionist personality type who looks at imperfect things and wants to eliminate as many of them as possible to improve things. I respectfully suggest that Wikipedia is not the place where such intentions and tendencies will bring on the most satisfaction. Jclemens (talk) 07:38, 21 May 2016 (UTC)
- Oppose: per the previous proposals. The statistic that "there are over 7000 old drafts that have not been edited in six months" only shows there is no effective reminder system which pings the contributors with a tickler about drafts. Just because someone creates a report with a number does not mean that number has any actionable meaning or that the number should even be thought of as a backlog when, in my opinion, it seems to be a to-do list. The difference for me is that backlog implies management of contributor efficiency. Less oligarchy is better. –BoBoMisiu (talk) 11:52, 21 May 2016 (UTC)
- Can anyone articulate a reason why deleting these is useful? The proposal assumes that it is, but I don't see a reason given. Oppose for now. It's clear deleting people's work is likely to piss them off and drive them away from Wikipedia. Probably very few return to a draft years later, but even if one would have, deleting the drafts is hurtful. What is the help here? Hobit (talk) 15:47, 21 May 2016 (UTC) Following up to my !vote, I've not been convinced that there is any meaningful benefit to doing this and I'm concerned we will delete useful things and/or piss off contributors or potential contributors. My oppose stands. Hobit (talk) 03:57, 24 May 2016 (UTC)
- You're arguing about the deletion policy in general. These pages are already being discussed at MFD (like at AFD). These drafts are regularly discussed and deleted on an ongoing basis. This is a suggestion for a proposed deletion system similar to WP:PROD. If you truly oppose any deletion of this sort, you'd be better off supporting this proposal and just removing all notices in mass rather than having to go to MFD and argue at every single discussion. Else, your opposition is entirely irrelevant to the issue of what method by which we can delete these pages since the consensus is that these pages are subject to deletion and are/have been deleted as such for years. -- Ricky81682 (talk) 20:45, 21 May 2016 (UTC)
-
-
- We're not arguing about about deletion policy in general, we're talking about deletion policy for draft space. It make sense to delete crap from main space as that material is available through a web search and would reflect badly on Wikipedia if people were reading it thinking it is something produced by the project. The situation is different with draft space. It is not externally indexed and so it can be considered semi-public unpublished work. This is really not much different than past revisions of articles in mainspace which we only delete based on copy violations and similar touchy issues.— Preceding unsigned comment added by Ricky81682 (talk • contribs)
- Please take a step back from your assumption that keeping everything is not sustainable (see my comments on storage above) and answer the question we've posed, what is gained by deleting abandoned drafts? ~Kvng (talk) 00:13, 22 May 2016 (UTC)
- It isn't sustainable, though. Categories will grow, indexes will grow, disk usage overall will grow, etc. The problem isn't necessarily the technological limitations, though, it's how manageable the dataset is for humans to deal with. There's no reason to keep one line drafts that have no potential whatsoever, empty drafts, etc. The proposal is a reasonable way to try and keep a handle on this. Are you really proposing that we delete NOTHING in draftspace? Every random promo utterance by a COI editor, every half-hearted attempt at a personal profile, every mistakenly create draft by an inexperienced editor? We don't need to hoard random, nonsensical stuff. A PROD process makes sense to keep useful drafts with potential easily accessible and easily findable - people don't want to wade through tons of junk to find that one gem. Chrisw80 (talk) 00:28, 22 May 2016 (UTC)
- Also, if they return, we'll just restore it. No one is on a wild mission to destroy good work but at the same time the people who actually go through the slog shouldn't have to suffer through millions of pieces of junk just for some philosophical debate about what "drives people away". We've done this for years and there's no evidence that these deletions are in fact driving any more people away that not doing them so it's odd that now that's a reason to not do it. -- Ricky81682 (talk) 00:34, 22 May 2016 (UTC)
- I have done the math argued that keeping all drafts indefinitely is sustainable. You have simply stated that it is unsustainable. Please explain why you think it is unsustainable.
- I agree that it is about making the dataset manageable for humans. My argument is that nothing is gained by time spent by humans reviewing these drafts. If there's a blanket technical or policy reason for deleting them, just delete them. If not, what is the harm in keeping all of them. How is going through this stuff now when you don't have a good understanding of how it may or may not be useful in the future better than going through it in the future when you know what you're looking for? ~Kvng (talk) 00:55, 22 May 2016 (UTC)
- That's nice and all but what does this have to do with this proposal? If you want to propose a bot to review all these, go ahead. If you want to propose that people ignore it, go ahead but if you aren't interested in this, why in the world does it matter that other people volunteer to do this? -- Ricky81682 (talk) 01:10, 22 May 2016 (UTC)
- Well, it's unfortunately not human manageable with 1 draft in 600 having any potential (mostly random stat, don't take at face value). Additionally, I have offered technical reasons for deleting them (growing categories, database indexes, disk usage, etc.). The direct harm is that the good stuff can't be found amongst the crap if we don't clean it up. We have people that WANT to clean it up, we are driving THEM away by refusing to allow crap drafts with no potential to be deleted. We shouldn't keep some poorly-written one-line or completely blank draft on the WP:CRYSTALBALL chance because it might happen to turn notable 10 years from now (we KNOW it's not suitable now). It's actually possible to draw in new contributors by offering them drafts that might have potential so they don't have to start from scratch - but we can't do that when draftspace is a complete disaster as it is now. Chrisw80 (talk) 01:18, 22 May 2016 (UTC)
- It seems like technical reasons in favor of deletions would have to be pretty compelling. Otherwise it would seem to be a good bargain to burn some system resources to avoid expending the human resources required to sift through all this stuff.
- I appreciate that there are Wikipedians who want to delete stuff and if we make that harder, maybe they'll be driven away or maybe they'll start using their time on activities that more directly affect the quality of the encyclopedia. I guess we must individually decide whether this is a potential problem. ~Kvng (talk) 04:11, 22 May 2016 (UTC)
- Chrisw80, you don't need to worry about WP:PERFORMANCE. There's a whole department of really awesome tech folks that deals with this stuff. In the unlikely event that the draftspace gets to big or too complicated for them, then they'll let us know. In the meantime, if you want a quick point for comparison, keep in mind that you're talking about a few thousand tiny text files, and they're supporting Commons:, whose database includes more than 31 million not-so-tiny media files and nearly a quarter-billion revisions. WhatamIdoing (talk) 04:42, 22 May 2016 (UTC)
- Hello there, WhatamIdoing. As I mentioned, the technological piece is only a part of the issue here. I'm well aware of how competent the WMF ops folk are. It doesn't mean we need to make their jobs any harder. Anyway, as I have pointed out it's not entirely about the technological piece, it's about the whole concept of collecting cruft in general. This whole idea is not wise, nor sustainable. However, I begin to repeat myself. I will not, nor will I ever, support keeping mountains of entirely useless drafts on Wikipedia. I do not believe that it will ever serve us to do so. Doing something simply "because we can", is foolish and short-sighted, IMHO. Chrisw80 (talk) 05:10, 22 May 2016 (UTC)
- Yes, you are repeating yourself a bit. You keep saying that leaving these drafts around is not sustainable. Not sustainable implies that we're going to run out of something or be buried by something. You haven't said specifically what the sustainability problem is. We're not going to run out of disk space or take forever to complete a search or break system indexing by having too many things in a category. We're not going to put any burden on editors or administrators because leaving all the stuff there means that no one needs to sift through it or perform any delete operations. I think it is easier to argue that continuing to examine and selectively delete "expired" material is not sustainable; We're getting a constant flow of it coming in and have a declining number of qualified editors and administrators working on the project. ~Kvng (talk) 05:55, 22 May 2016 (UTC)
- Regarding sustainability, I stated specifically: "A PROD process makes sense to keep useful drafts with potential easily accessible and easily findable - people don't want to wade through tons of junk to find that one gem." Keeping things clean so useful material is easy to find. We ARE geting buried with useless drafts. I wasted 30 minutes opening stale drafts at random for something I thought would be something I could pick up and roll with to prove myself wrong here. I found nothing worth keeping. Almost all were one-liners for completely non-notable persons or organizations, blank, or only had basic section headers and no content. There were a couple where the subject had potential, but the content was so poorly written that it would have needed a complete rewrite anyway. Perhaps there are others that I'm missing? In every borderline case I saw, it would be better simply to have a line item over at WP:RA. There are people that WANT to do this, I say let them do it, and it's possible we can convince them to do other things on Wiki as well in the process, rather than drive them away with refusal to let ANYTHING be deleted. Chrisw80 (talk) 06:12, 22 May 2016 (UTC)
- In this same paragraph your arguing both that people do and people don't want to sort through all of this stuff. If you're talking about the same people, you're not making sense. If you're talking about different people that do and other people that don't, I would be surprised if these two groups would be able to agree on a criteria for determining what's a gem. ~Kvng (talk) 17:56, 22 May 2016 (UTC)
- Regarding sustainability, I stated specifically: "A PROD process makes sense to keep useful drafts with potential easily accessible and easily findable - people don't want to wade through tons of junk to find that one gem." Keeping things clean so useful material is easy to find. We ARE geting buried with useless drafts. I wasted 30 minutes opening stale drafts at random for something I thought would be something I could pick up and roll with to prove myself wrong here. I found nothing worth keeping. Almost all were one-liners for completely non-notable persons or organizations, blank, or only had basic section headers and no content. There were a couple where the subject had potential, but the content was so poorly written that it would have needed a complete rewrite anyway. Perhaps there are others that I'm missing? In every borderline case I saw, it would be better simply to have a line item over at WP:RA. There are people that WANT to do this, I say let them do it, and it's possible we can convince them to do other things on Wiki as well in the process, rather than drive them away with refusal to let ANYTHING be deleted. Chrisw80 (talk) 06:12, 22 May 2016 (UTC)
- Yes, you are repeating yourself a bit. You keep saying that leaving these drafts around is not sustainable. Not sustainable implies that we're going to run out of something or be buried by something. You haven't said specifically what the sustainability problem is. We're not going to run out of disk space or take forever to complete a search or break system indexing by having too many things in a category. We're not going to put any burden on editors or administrators because leaving all the stuff there means that no one needs to sift through it or perform any delete operations. I think it is easier to argue that continuing to examine and selectively delete "expired" material is not sustainable; We're getting a constant flow of it coming in and have a declining number of qualified editors and administrators working on the project. ~Kvng (talk) 05:55, 22 May 2016 (UTC)
- Hello there, WhatamIdoing. As I mentioned, the technological piece is only a part of the issue here. I'm well aware of how competent the WMF ops folk are. It doesn't mean we need to make their jobs any harder. Anyway, as I have pointed out it's not entirely about the technological piece, it's about the whole concept of collecting cruft in general. This whole idea is not wise, nor sustainable. However, I begin to repeat myself. I will not, nor will I ever, support keeping mountains of entirely useless drafts on Wikipedia. I do not believe that it will ever serve us to do so. Doing something simply "because we can", is foolish and short-sighted, IMHO. Chrisw80 (talk) 05:10, 22 May 2016 (UTC)
- It isn't sustainable, though. Categories will grow, indexes will grow, disk usage overall will grow, etc. The problem isn't necessarily the technological limitations, though, it's how manageable the dataset is for humans to deal with. There's no reason to keep one line drafts that have no potential whatsoever, empty drafts, etc. The proposal is a reasonable way to try and keep a handle on this. Are you really proposing that we delete NOTHING in draftspace? Every random promo utterance by a COI editor, every half-hearted attempt at a personal profile, every mistakenly create draft by an inexperienced editor? We don't need to hoard random, nonsensical stuff. A PROD process makes sense to keep useful drafts with potential easily accessible and easily findable - people don't want to wade through tons of junk to find that one gem. Chrisw80 (talk) 00:28, 22 May 2016 (UTC)
-
Hello Kvng, they aren't necessarily the same group of people, I wasn't suggesting they were - Wikipedia is a large project and there is room for all kinds of people who want to focus on different aspects of the project. And perhaps they wouldn't be able to agree on specific criteria, that's why a PROD process is a good idea. If anyone thinks the article is worth salvaging, they can remove the PROD, it's that simple. Anyone's definition of a "gem" will do, in this process. You are aware that with a PROD, anyone can remove the tag with no explanation required? I still can't figure out if you're really suggesting that if someone wants to have a blank or nearly blank draft deleted that they either have to ignore it and let it clutter the categories and backlog, or have to send it to MfD for it to be debated ad nauseam.. We should courtesy blank a blank draft instead of deleting it? Deleting a blank draft is going to drive away potential contributors? Chrisw80 (talk) 18:25, 22 May 2016 (UTC)
- The problem with prod for this purpose is that a normal editor has no way of knowing what has been deleted and so it is impossible to know what to ask for at WP:REFUND when you're looking for a gem. Novice editors may find WP:REFUND to be too high of a barrier to continue their postponed work. Novice editors are sometimes reluctant to or otherwise unable or unwilling to deprod (they continue to improve their draft without deprodding). ~Kvng (talk) 19:23, 22 May 2016 (UTC)
- Oppose — This is only a hypothetical problem. As long as drafts are not spam or things that do not belong on Wikipedia anyway, such as paid editing drafts there is no reason to actually delete them. If even a single draft can be salvaged from this space it is worth letting thousands accumulate — they aren't doing anyone any harm and barely impact the servers. Carl Fredik 💌 📧 21:45, 22 May 2016 (UTC)
- It's not about the servers, it's about the people. Do you think people are going to be able to functionally go through and work in draftspace if you have to click through hundreds of pages like Draft:Kristoffer Hellkvist - Världens sämsta källkritker that no one finds useful but won't be deleted? Even then, how does that affect this proposal? The deletions occur with or without this proposal and instead of a month to work on the draft, the editor is told there's a week-long procedural discussion at MFD. -- Ricky81682 (talk) 22:27, 22 May 2016 (UTC)
-
-
- Why does anyone need to go through them? We have other methods of deleting and detecting copyvio, slander, and other material that should not be on Wikipedia. I can not fathom a scenario where you will come across that article without looking for info on Kristoffer Hellkvist, where it might actually be useful. Also, that is a BLP issue and can be deleted on those grounds, this proposal makes no sense because it isn't a problem. Carl Fredik 💌 📧 22:41, 22 May 2016 (UTC)
- For CSD violations? For BLP nightmares? For forks of mainspace? For content worth merging and using? Why does anyone review work at AFC? People check on old drafts that haven't been touched to get rid of the worst ones, and to figure out what's worth improving to get them to mainspace. Again, if you don't want to do that kind of stuff, fine but since they are already going to be reviewed and are subject to deletion on these exact same grounds, I'm trying to propose a more streamlined approach. It doesn't take a ton of time to see junk and that's why AFC has G13 to simplify it. This is better than a separate MFD for each page. -- Ricky81682 (talk) 04:08, 23 May 2016 (UTC)
- But why do existing drafts that do not violate policy have to be deleted? It seems to me that all you need to do is patrol recent edits in draft-space, and ignore old drafts. Carl Fredik 💌 📧 14:22, 23 May 2016 (UTC)
- For CSD violations? For BLP nightmares? For forks of mainspace? For content worth merging and using? Why does anyone review work at AFC? People check on old drafts that haven't been touched to get rid of the worst ones, and to figure out what's worth improving to get them to mainspace. Again, if you don't want to do that kind of stuff, fine but since they are already going to be reviewed and are subject to deletion on these exact same grounds, I'm trying to propose a more streamlined approach. It doesn't take a ton of time to see junk and that's why AFC has G13 to simplify it. This is better than a separate MFD for each page. -- Ricky81682 (talk) 04:08, 23 May 2016 (UTC)
- Why does anyone need to go through them? We have other methods of deleting and detecting copyvio, slander, and other material that should not be on Wikipedia. I can not fathom a scenario where you will come across that article without looking for info on Kristoffer Hellkvist, where it might actually be useful. Also, that is a BLP issue and can be deleted on those grounds, this proposal makes no sense because it isn't a problem. Carl Fredik 💌 📧 22:41, 22 May 2016 (UTC)
-
- Oppose as very few, and likely 0 people will be keeping an eye on the proposals to delete. So it would be akin to a delayed speedy delete. Graeme Bartlett (talk) 00:21, 24 May 2016 (UTC)
- @Graeme Bartlett: I would imagine that the number of people "keeping an eye on the proposals to delete" will be the same for a page in Draft space as for a page in article space. If your worry is that nobody will do anything before the time limit is reached, then you should have a similar worry with articles that have been WP:PRODded. The pages will be in Category:All articles proposed for deletion, or a similar category; and when the time limit does get reached, the draft will be automatically categorised into Category:Expired proposed deletions, or similar. --Redrose64 (talk) 14:39, 24 May 2016 (UTC)
- Oppose - I've yet to see any good justification as to why we should delete any pages that just happen to be old, but are otherwise not harmful. Absent that justification, there can be no rationale for expanding G13's scope. Ivanvector 🍁 (talk) 21:32, 26 May 2016 (UTC)
Discussion (Proposed draftspace deletion)
- I would suggest adding {{subst:submit}} to such pages instead. This will ensure that they are properly reviewed before being deleted. If WP:PROD is used, chances are that no one reads the page before it is deleted, and then we might lose useful stuff. --Stefan2 (talk) 21:41, 20 May 2016 (UTC)
- Unless things have changed, AFC had a fit the last time I tried doing something similar. To be fair, the fit was in part because they used to be userspace before being moved but I was doing that in old draftspace drafts as well and the general view was against the unilateral addition to AFC without the original creator's consent. We are going in circles if people propose adding it to AFC and AFC objects to their addition. -- Ricky81682 (talk) 21:54, 20 May 2016 (UTC)
- Why were they moved out of Userspace, if they are not AFC candidates? Perhaps the solution is to return them to Userspace. Blueboar (talk) 22:06, 20 May 2016 (UTC)
- AFC does both places. I'm only making a proposal for draftspace right now. -- Ricky81682 (talk) 22:51, 20 May 2016 (UTC)
- Why were they moved out of Userspace, if they are not AFC candidates? Perhaps the solution is to return them to Userspace. Blueboar (talk) 22:06, 20 May 2016 (UTC)
- I wrote a fair bit about why this is a bad idea at Wikipedia:User pages/RfC for stale drafts policy restructuring#Comments B1. The short, short version is that, unless you're going to submit it and then immediately do the AFC review yourself, all you've accomplished is to move a page out of one backlog into another. —Cryptic 23:06, 20 May 2016 (UTC)
- Given that User:MusikBot/StaleDrafts/Report is at least 5000 blue links, that will be a miserable backlog created at Category:G13 eligible AfC submissions in six months. Everyone loves to suggest someone do more work instead. -- Ricky81682 (talk) 01:55, 21 May 2016 (UTC)
- Unless things have changed, AFC had a fit the last time I tried doing something similar. To be fair, the fit was in part because they used to be userspace before being moved but I was doing that in old draftspace drafts as well and the general view was against the unilateral addition to AFC without the original creator's consent. We are going in circles if people propose adding it to AFC and AFC objects to their addition. -- Ricky81682 (talk) 21:54, 20 May 2016 (UTC)
- To respond to a number of people, if your opposition is against deleting these old draftpsace pages in general, that's been resolved for years and you've basically lost that battle. These pages are currently taken to MFD and deleted on a regular basis. If this is rejected, then MFD remains an option for these. As opposed to an editor getting a notice that they have a week to go to an MFD discussion and gain a consensus to keep their page, they will be told they have a month to just go on the page and remove the notice. I think that's better. If you truly object to the deletion of these drafts at all, WP:MFD is available and this proposal actually makes it easier for you to just mass remove every proposed deletion than to go to MFD and argue against all deletion of these pages. -- Ricky81682 (talk) 20:41, 21 May 2016 (UTC)
-
- @Ricky81682: from what I read, MFD is like a material review board which I understand well. Your proposal is about how to disposition draft pages that are identified by bots using the criteria of inactivity. You wrote above that "After the proposed draft is removed, I don't think there's any rules about what to do. It can go to userspace or mainspace or wherever else people want. This is just more of a single veto to deletion than MFD's consensus requirement." I am assuming removed in your sentence means queued for disposition. MFD deletes by consensus but your proposal would delete by individual admin as the last step in this new queue for disposition. What regulates that last step, i.e. the individual admin's decision to delete? Or maybe, if I reword that, how does she decide if the draft page is defective enough to scrap other than because it is inactive? –BoBoMisiu (talk) 23:14, 21 May 2016 (UTC)
- I'm imagine this like WP:PROD. If a draft hasn't been edited in six months/whatever time period and someone thinks it's not worth keeping, then they can propose it for deletion. From there, an admin can decide whether or not to delete. On what basis, I'd argue if you think there's no plausible chance that it could become a legitimate article but there's been no consensus on a standard for when a draft should be kept (else, we'd have some basis at AFD for when to draftify/userify pages). Discussing that is impossible if people argue against deleting any drafts while at the same time there are votes (often the same people) for deleting certain drafts and a refusal to explain their criteria. We can define that separately now or later if that's a concern. There are no bots I'm suggesting here; the prod template could do the six month check within it as the G13 template does but it's still the admin's responsibility to make sure the rules are followed. We could add that WP:REFUND still applies or any admin can undelete it if requested but that's pretty much standard anyways so I don't see the need for it to be explicitly stated. Again, if people really do believe that drafts shouldn't be deleted, they are free to browse through these as well and see if there's anything worth keeping. I've been active in moving pages to mainspace for a while now, it's just not feasible to do that if we can't do some triage and rid of the stuff that no one sees going anywhere under the hope that editors will return after 2/3/4/5 years and do it for us. -- Ricky81682 (talk) 00:00, 22 May 2016 (UTC)
- @Ricky81682: from what I read, MFD is like a material review board which I understand well. Your proposal is about how to disposition draft pages that are identified by bots using the criteria of inactivity. You wrote above that "After the proposed draft is removed, I don't think there's any rules about what to do. It can go to userspace or mainspace or wherever else people want. This is just more of a single veto to deletion than MFD's consensus requirement." I am assuming removed in your sentence means queued for disposition. MFD deletes by consensus but your proposal would delete by individual admin as the last step in this new queue for disposition. What regulates that last step, i.e. the individual admin's decision to delete? Or maybe, if I reword that, how does she decide if the draft page is defective enough to scrap other than because it is inactive? –BoBoMisiu (talk) 23:14, 21 May 2016 (UTC)
I have not previously spent time at MfD but the intro at WP:MFD says "Miscellany for deletion (MfD) is a place where Wikipedians decide what should be done with problematic pages in the namespaces which aren't covered by other specialized deletion discussion areas." You say that abandoned drafts are routinely deleted at MfD. I assume that there is some routine argument given for why these pages are problematic. Can you share that reasoning with us? ~Kvng (talk) 00:18, 22 May 2016 (UTC)
- Again, if your dispute is that these pages should not be deleted, this has zero effect on that. Otherwise, the archives show various draft pages that were deleted including under G2 criteria, prior moves from mainspace that were never improved, G11, later creation in mainspace, and just being abandoned. The general idea is that these exact same pages would be deleted if in mainspace. Telling editors that the mainspace violating ones will be immediately deleted while just keeping around ones they put in draftspace and other places (which some people then subsequently link to directly, NOINDEXing aside) just sends the wrong signals. -- Ricky81682 (talk) 00:31, 22 May 2016 (UTC)
- And if you disagree with a particular one or a particular rationale, feel free to take it to DRV or talk to the closing admin. I personally have restored a number of old drafts just because one person has said they will work on it. Hell, I'll even vote keep just on a guess that someone will work on it. -- Ricky81682 (talk) 00:42, 22 May 2016 (UTC)
-
-
- I've had a look at active discussions at MfD and see that Ricky81682 is doing a lot of nominations that basically say, "This is crap and should be deleted." I'm tempted to chime in on all of these draft deletion discussions with. "Oppose, no indication this is a problematic draft." I don't wasnt to contribute to any more time being wasted on these nominations. The issue goes beyond the draft prod proposal for me. If you want to confine discussion here to your proposal, I can start something at Wikipedia talk:Miscellany for deletion. Let me know. ~Kvng (talk) 00:45, 22 May 2016 (UTC)
- Engage you in what? A new academic debate based upon the MFD instructions? WT:MFD is not for deletion policy debates, it's for how to functionally run MFD. The fact that people have made the instructions into a maze of regulations is not a reason to engage further in that idiocy. We had two stupid RFCs on whether we can relist discussions because people argued that it was driving editors away. If you think those shouldn't have been deleted, take them all to DRV and convince people that they should be restored for whatever reason you have. I'm using the same reasons and rationales that have been discussed at MFD since 2008 and before that and these are being deleted for the same reasons. If you have some bold new insight as to why all those prior nominators, voters and closers were all wrong, go look for examples, get those discussions reversed and convince some people rather than badgering the people who actually just want to deal with this crap and not just engage in the same navel-gazing month after month. -- Ricky81682 (talk) 01:02, 22 May 2016 (UTC)
- Looks like there's a very active discussion about this at Wikipedia_talk:Criteria_for_speedy_deletion#G13_Drafts. I will contribute there. ~Kvng (talk) 01:15, 22 May 2016 (UTC)
- Looks like discussion has moved on to Wikipedia:User_pages/RfC_for_stale_drafts_policy_restructuring ~Kvng (talk) 20:13, 23 May 2016 (UTC)
- Looks like there's a very active discussion about this at Wikipedia_talk:Criteria_for_speedy_deletion#G13_Drafts. I will contribute there. ~Kvng (talk) 01:15, 22 May 2016 (UTC)
- Engage you in what? A new academic debate based upon the MFD instructions? WT:MFD is not for deletion policy debates, it's for how to functionally run MFD. The fact that people have made the instructions into a maze of regulations is not a reason to engage further in that idiocy. We had two stupid RFCs on whether we can relist discussions because people argued that it was driving editors away. If you think those shouldn't have been deleted, take them all to DRV and convince people that they should be restored for whatever reason you have. I'm using the same reasons and rationales that have been discussed at MFD since 2008 and before that and these are being deleted for the same reasons. If you have some bold new insight as to why all those prior nominators, voters and closers were all wrong, go look for examples, get those discussions reversed and convince some people rather than badgering the people who actually just want to deal with this crap and not just engage in the same navel-gazing month after month. -- Ricky81682 (talk) 01:02, 22 May 2016 (UTC)
- If, as you say, you don't object to these being restored upon simple request, then what's the advantage of deletion over writing a close variant of {{inactive userpage blanked}} for draftspace? —Cryptic 01:38, 22 May 2016 (UTC)
- Because there was no support for that before. If you want to support a policy change that better defines when blanking versus deletion is appropriate, I'm on board. However, that first requires some acknowledgement that deletion is appropriate and some definition of when since deletion is obviously done. Abjectly arguing against any policy line for deletions is why we keep going in circles. Otherwise, why not support this and then just mass unprod everything and replace with the template? -- Ricky81682 (talk) 02:08, 22 May 2016 (UTC)
- I've had a look at active discussions at MfD and see that Ricky81682 is doing a lot of nominations that basically say, "This is crap and should be deleted." I'm tempted to chime in on all of these draft deletion discussions with. "Oppose, no indication this is a problematic draft." I don't wasnt to contribute to any more time being wasted on these nominations. The issue goes beyond the draft prod proposal for me. If you want to confine discussion here to your proposal, I can start something at Wikipedia talk:Miscellany for deletion. Let me know. ~Kvng (talk) 00:45, 22 May 2016 (UTC)
-
- Could someone please provide some concrete examples of contributors that have been "chased away" by deletion of their stale/useless drafts? It keeps getting brought up and I haven't seen any actual evidence. Chrisw80 (talk) 00:47, 22 May 2016 (UTC)
- WT:MFD had two RFCs on whether or not to relist discussions arguing that relisting discussions was somehow a deletionist scheme to chase editors away. Don't be surprised at the evidence you'll get. -- Ricky81682 (talk) 01:02, 22 May 2016 (UTC)
- I haven't made this claim myself but I do see new editors "chased away" at AfC, AfD and PROD. Unnecessary or overly-aggressive deletion definitely WP:BITEs and regardless of whether you can connect biting to new editor retention, we don't want to bite. ~Kvng (talk) 01:08, 22 May 2016 (UTC)
- Question: Why can't we just use plain old {{subst:prod}} in draftspace? This would naturally require changing WP:PROD (one sentence?), but that seems achievable, and it seems like a better way to get rid of completely inappropriate pages (i.e., pages that have problems beyond a lack of editing activity) than waiting about for six months. WhatamIdoing (talk) 05:01, 22 May 2016 (UTC)
-
- I could agree to extending PROD to include material in Draftspace. Blueboar (talk) 18:20, 22 May 2016 (UTC)
- Exactly. Extending PROD applicability to Draftspace certainly makes sense and would be a fairly minimal change that would still help quite a bit. Right now, apart from G13 and obvious CSD cases, the only other route for deleting pages from Draftspace is through MfD, which is bureaucratically complicated and time consuming for everybody. A simpler procedure, like PROD, for more straightforward cases, would be helpful. Nsk92 (talk) 15:17, 23 May 2016 (UTC)
- The cart is before the horse here. PROD is only to be used for uncontroversial deletions. There is currently no consensus on whether these deletions should be performed, see Wikipedia_talk:Criteria_for_speedy_deletion#G13_Drafts. Until this is resolved, it is inappropriate to use PROD. ~Kvng (talk) 20:05, 23 May 2016 (UTC)
-
Inconsistency between WP:Article Size and WP:Summary style
WP:Summary style states: "What constitutes 'too long' is largely based on the topic, but generally 30 kilobytes of readable prose is the starting point at which articles may be considered too long. Articles that go above this have a burden of proof that extra text is needed to efficiently cover their topics and that the extra reading time is justified." But WP:Article size states that for articles under 40 kB readable prose size "[l]ength alone does not justify division". To address this issue and a couple suggested improvements to WP:Summary style, I began a discussion at Wikipedia talk:Summary style#Inconsistency with WP:Article Size. Please keep discussion in one place by commenting in that discussion, not here in the village pump. AHeneen (talk) 09:31, 23 May 2016 (UTC)
Unauthorized electronic trails by the fa and id Wikipedia
I have recently noticed that some language versions of Wikipedia takes the freedom to create you a userpage or talk page just because you happened visit, not edit that Wikipedia, ONCE. I find that practice offensive and abusive to use the access to the global login system to create completely unnecessary electronic trail. The projects that seem practice this are "id.wikipedia.org" and "fa.wikipedia.org" maybe others. Until they fix this, one effective solution is to cut their access to the cookies that facilitate the global login system so that users explicitly have to permit cookie persistence when visiting those projects. Ie "make global login visible for project [en] [es]" etc. Bytesock (talk) 04:10, 24 May 2016 (UTC)
- @Bytesock: this page is for discussing policies for the English Wikipedia, we have no jurisdiction over any other project. You may want to raise your point at meta:Wikimedia_Forum. — xaosflux Talk 04:15, 24 May 2016 (UTC)
- @Bytesock: - Also, this is not how it works. When you visit the page while logged in your account is created, they give the message to created accounts, so this is inherent to the way Wikipedia works. Carl Fredik 💌 📧 07:39, 24 May 2016 (UTC)
- @Bytesock: I replied to you on meta but I just remind you here in bigger detail that if go to "Preferences" there is a subpage called "notification" and you can deselect the box of cross wiki notifications. Personally I was against the massive introduction of cross-wiki notifications, as happened few weeks ago. I supported the information campaigns for user who wnatd to select the box as a possibility, and I could see the utility of its default introduction on some "meta" platforms such as mediawiki, meta, incubator and maybe later also commons and wikidata, but switching the cross-notification function on for all the platforms and also all the newbies was not well planned. if you remove the cross notification, other wikis won't bother you directly with their welcoming messages.--Alexmar983 (talk) 04:32, 25 May 2016 (UTC)
- @Bytesock: - Also, this is not how it works. When you visit the page while logged in your account is created, they give the message to created accounts, so this is inherent to the way Wikipedia works. Carl Fredik 💌 📧 07:39, 24 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
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)
- 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)
- 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)
- 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)
- 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)
RfC: Editinterface rights for template editors
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
Oppose
- 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)
Discussion
Behold, A Deeply Important and Profound Critique of Wikipedia
http://www.the-tls.co.uk/articles/public/encyclopedic-knowledge/
Here you are, friends.
Enjoy! — Preceding unsigned comment added by A Friendly Troll (talk • contribs) 06:17, 27 May 2016 (UTC)