Wikipedia:Village pump (policy): Difference between revisions
Curly Turkey (talk | contribs) |
SlimVirgin (talk | contribs) |
||
Line 562: | Line 562: | ||
*'''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. |
*'''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 <u>normally should not include any parameters</u>. In that case it's obvious to check the template page to figure out what's going on. [[User:Alsee|Alsee]] ([[User talk:Alsee|talk]]) 13:01, 16 May 2016 (UTC) |
:A good exception is something like Authority Control which <u>normally should not include any parameters</u>. In that case it's obvious to check the template page to figure out what's going on. [[User:Alsee|Alsee]] ([[User talk: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.{{pb}}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 [https://en.wikipedia.org/w/index.php?title=Talk:Night_%28book%29&oldid=717835887#Infoboxes_and_Wikidata the discussion].{{pb}}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.{{pb}}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. [[User:SlimVirgin|SarahSV]] <small><sup>[[User_talk:SlimVirgin|(talk)]]</sup></small> 15:21, 16 May 2016 (UTC) |
|||
===Rationale (Wikidata)=== |
===Rationale (Wikidata)=== |
Revision as of 15:21, 16 May 2016
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
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.
Wikipedia:Disambiguation and inherently ambiguous titles
What guidance should WP:Disambiguation give for article titles that do not result in a conflict between two or more articles, but which are not inherently unambiguous to a general audience?
Background:
- This content regarding titles that inherently lack precision was added to WP:DAB on June 6, 2015, by SMcCandlish, consisting of a paragraph under "Is there a Primary Topic?", an example under "Deciding to disambiguate", and a summary sentence in the lead paragraph: "Disambiguation may also be applied to a title that inherently lacks precision and would be likely to confuse readers if it is not clarified, even it does not presently result in a titling conflict between two or more articles." SMcCandlish posted a rationale of this addition to the talk page, which received no replies.
- On July 16, 2015, Red Slash removed the main paragraph, with the comment "How does this have anything at all to do with disambiguation?". A talk page discussion between Red Slash and Francis Schonken discussed this removal.
- On July 28, 2015, Red Slash removed the example under "Deciding to disambiguate". On August 6, this example was restored by SMcCandlish and again removed by Red Slash, then, on August 7, restored by SMCandlish, removed by Francis Schonken, again restored by SMcCandlish, and again removed by Francis Schonken. An RFC on the content from that time doesn't appear to have been officially closed, but by my count has three editors in support of the principle of "disambiguation for clarification" and three opposed.
- In February 2016, the lead sentence (the only remaining portion of the content originally added June 6) was removed by Born2cycle, restored by by SMcCandlish, removed by BD2412, restored by Dicklyon, removed by Calidum, restored by Tony1, removed by Calidum, restored by Tony1, removed by Calidum, and restored by Bagumba who locked the page for edit warring. A talk page discussion did not result in any clear consensus.
- On March 23, the lead sentence was removed by Dohn joe, restored by In ictu oculi, removed by Dohn joe, and restored by SMcCandlish. A further talk page discussion ensued.
- With respect to the participants on both sides, the discussion of the proposed guideline so far has generated more heat than light. I'm hoping a straightforward and (pardon the pun) unambiguous RFC can resolve the issue somewhat permanently and put an end to the disruptions to WP:D. Two of the talk page discussions have proposed taking this to RFC, but don't seem to have been able to reach agreement even on what an RFC should look like. As I have not, to my recollection, participated in the dispute, I have done my best to frame it neutrally and been so bold as to just go ahead and post it here. Please let me know if I have missed anything salient in the above summary.--Trystan (talk) 02:34, 25 March 2016 (UTC)
Responses (disambiguation)
- Parenthetical notes in an article title (unless the parenthetical notes are part of the article title) should only be used to distinguish between multiple articles with the same title. I can't think of a time when I would add a parenthetical dab to a title of an article when it didn't belong, merely to clarify something. Perhaps if some examples of contentious article titles were posted, we could see the nature of the dispute here. --Jayron32 03:11, 25 March 2016 (UTC)
- No guidance. This kind of guidance is a can of worms - loads of unintended consequences. We should not "pre-disambiguate" an article because "it sounds too generic" or "that doesn't sound like it is an X" or "that sounds too similar to X". If there is an existing encyclopedic topic that shares a name with another topic, there is potential ambiguity, and we refer to WP:DAB's guidance. If there's only one topic, then WP:DAB does not come into the equation. The examples given to illustrate the contested guidance show that. "Flemish giant" - with no context - sounds like it might be a tall person from Antwerp. While this may be true, tall people from Flanders is not an encyclopedic topic. So instead, Flemish giant redirects to Flemish Giant rabbit - a domestic rabbit breed.
But that's the point - "Flemish giant" redirects to "Flemish Giant rabbit". Why? Because there is no other encyclopedic topic to disambiguate from. Conversely, Algerian Arab is a dab page, while Algerian Arab sheep is an article about sheep. So in this case, "sheep" serves to disambiguate, while "rabbit" does not. If you prefer "Flemish Giant rabbit" for WP:CONSISTENCY purpose or something else, that's fine, but it's not actually disambiguating anything.
So - there is actually nothing unusual here. Regular WP:DAB questions should be asked of any title. Those questions should not include "Doesn't that kind of sound like something else?" Dohn joe (talk) 03:45, 25 March 2016 (UTC)
- "If you prefer 'Flemish Giant rabbit' for WP:CONSISTENCY purpose or something else, that's fine, but it's not actually disambiguating anything." OK, by your narrow definition, this is not actually disambiguating anything, in that there is no confusion what article you want if you say Flemish giant. Note, however, that by a broader definition, quite often that extra word that is "not necessary" does a lot of good in terms of improving precision and reducing ambiguity. Did you look at the railway station example I added? The point is that that minimalist titling that some espouse leaves things looking imprecise, and we have many examples of consensus naming conventions that don't interpret precision and ambiguity in this narrow B2C way. Dicklyon (talk) 03:52, 25 March 2016 (UTC)
- Projects are allowed to develop naming conventions. They usually are exceptions to the precision/ambiguity criterion of WP:AT - see WP:USPLACE, WP:Naming conventions (UK Parliament constituencies), etc., referenced at WP:PRECISION. So, yes, consistency, or naturalness or some other consideration can override precision. But it should remain an exception that doesn't swallow the rule. Dohn joe (talk) 04:03, 25 March 2016 (UTC)
- I'm pretty sure projects don't change, supercede, or make exceptions to policy and guidelines. And WP:PRECISION isn't overridden by having the article title "unambiguously define the topical scope of the article". People seem to ignore that provision, and treat precision as a negative when they could use a shorter title without a collision. That's the B2C algorithm, and it's nonsense. Dicklyon (talk) 05:03, 25 March 2016 (UTC)
- I'd never seen Wikipedia:Naming conventions (UK Parliament constituencies) until today. I can't believe it exists. Curly Turkey 🍁 ¡gobble! 05:09, 25 March 2016 (UTC)
- Your singular personal belief is not required to make things exists. The world, and the things in it, exist outside of your consciousness. --Jayron32 05:18, 25 March 2016 (UTC)
- And the world outside the Wikipedia:Naming conventions (UK Parliament constituencies) basement has moved strongly against this pointless "disambiguation"—WProjects like WP:CANADA and WP:INDIA dropped this silliness years ago. So, what were you saying about "singular personal beliefs"? Curly Turkey 🍁 ¡gobble! 05:25, 25 March 2016 (UTC)
- And yet, it still exists. Notice how you had a feeling or an emotion (you thought it "silly") and nothing changed. The world works like that: reality continues to keep being real despite you having feelings about it. It's odd you haven't learned that. --Jayron32 16:17, 25 March 2016 (UTC)
- You don't appear to have a point. Curly Turkey 🍁 ¡gobble! 21:18, 25 March 2016 (UTC)
- 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:
- 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:
- 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)
- Retain the guidance since the lengthy discussion above and below has convinced me that this is useful guidance to editors in encouraging a better and less frustrating experience for our readers. BushelCandle (talk) 06:59, 3 April 2016 (UTC)
- No guidance as I agree wholeheartedly with DoctorKubla. -- Tavix (talk) 12:24, 5 April 2016 (UTC)
- Retain the guidance. I am also irked by the Memorial Hall (Harvard University) example provided by EEng and similar ones – articles about obscure things with common-sounding (i.e. wikt:ambiguous) names do benefit from some extra WP:PRECISION. Doing otherwise easily confuses the readers (as the context is often not enough to quickly conclude what the topic is, and matches displayed in the search box do not provide any hint about the topic) and editors (quite easy mislinking) alike. Of course, case-by-case examination is always welcome, but we do not apply WP:CONCISE at all costs. No such user (talk) 15:35, 6 April 2016 (UTC)
- I, for one, do not call for applying WP:CONCISE at all costs. To the contrary. I call for applying it primarily as a "tie breaker". When considering all other WP:CRITERIA there is no clear answer, then go with the more concise one. It is that simple. But the main point her is that all this is WP:AT consideration; it has nothing to do with WP:DISAMBIGUATION. --В²C ☎ 20:07, 7 April 2016 (UTC)
- Retain the guidance. It's reasonable to note that some titles may be ambiguous or likely to confuse a reader even if they don't exactly match any other titles, and I'm fine with having at least a modicum of text into the guideline to explain this. I understand that some prefer the term "disambiguation" to be defined more narrowly as just the mechanical process of distinguishing between otherwise identical Wikipedia titles, but I don't think that's particularly useful. There can be (and often is) a difference between what's merely technically ambiguous and what's actually ambiguous, and the latter can be a valid consideration when determining the best title for our readers. ╠╣uw [talk] 19:01, 11 April 2016 (UTC)
- Change names The simplest thing to do would be to change the names. — Preceding unsigned comment added by Shinyapple (talk • contribs) 01:22, 30 April 2016 (UTC)
- Retain guidance What useful purpose is served by inherently ambiguous titles, even when this is the sole article? Pincrete (talk) 21:37, 6 May 2016 (UTC)
- Retain Guidance Why would we remove relevant information that helps users avoid pointless move discussions. I have seen time and again pointless move requests to ambiguous titles that fail precision. InsertCleverPhraseHere 03:23, 15 May 2016 (UTC)
- And numerous RMs have closed with the opposite result. Calidum ¤ 03:48, 16 May 2016 (UTC)
Discussion (disambiguation)
- More detailed background: Attempts to delete part of the guideline, which was established through standard consensus-building discussion and revision many months ago, are predicated on two obvious fallacies: 1) That "disambiguate" is a made-up Wikipedian neologism for "prevent article title collisions". Check any dictionary; it's a plain-English word meaning "to resolve ambiguity"; doing so to prevent title collisions is simply the most common reason we disambiguate and has never been the only one. 2) That WP:CONCISE is akin to a law, and that the most concise possible name must always be chosen no matter what. Actually read WP:AT policy – all of the WP:CRITERIA are considered, and balanced against each other; the overriding concern is not following any "rule" bureaucratically, but ensuring clarity for readers. The naming criteria
"should be seen as goals, not as rules. For most topics, there is a simple and obvious title that meets these goals satisfactorily. If so, use it as a straightforward choice. However, in some cases the choice is not so obvious. It may be necessary to favor one or more of these goals over the others."
The previous debates about this guidance are misrepresented in the the summary in the RfC, which incorrectly paints it as a slow editwar instead of removal, discussion, refinement, acceptance, then much latter isolated attempts to delete it without a rationale. In the original discussions 8 months ago here and here, Red Slash tried to move it into policy itself at WP:AT (rejected), objections were raised about iit original length (it was shortened), and about particular examples it use (removed); the principal objector was Francis Schonken, on the basis of having made a proposal to rewrite AT in ways that would have integrated this and made various other changes (which did not achieve consensus at AT). After revision, the short version of this material was accepted in WP:Disambiguation without incident since that second discussion. This is standard WP:BRD operating procedure, and this revision and resolution process is how consensus is established. By August, the principal objector, Schonken, was removing attempts to reinserted expanded wording and examples [18] but retaining the agreed short version from prior discussions [19], which had already been accepted for two months. It remained uncontroverted for 6 more months, clearly long enough for consensus to be established, especially in a much-watchlisted guideline we use every single day.
It was drive-by deleted in Feb. by Born2Cycle, with a bogus claim that discussion didn't happen and consensus was not been established [20]. This is is part of his years-long, tendentious campaign to promote WP:CONCISE as some kind of "super-criterion" that trumps all other concerns – which WP:MFD has rejected three times in a row: 1, 2, 3. The recent attempt by Dohn joe to delete material was predicated on his unawareness of the February discussion (which is mischaracterizing as being against inclusion when it was not) [21], his misunderstanding of previous discussions (see WT:Disambiguation#Restored content on precision cut from lead, which covers much of what I've outline here in more detail), and more false claims that consensus was not established.
After 8 months of stability, the burden is on would-be deleters to demonstrate what the supposed problem is, and provide actual evidence that WP-wide consensus that such precision-and-recognizability disambiguations are permissible when necessary has somehow disappeared all of a sudden. This RfC, and two editors' PoV against this part of WP:DAB, would undo very long-standing naming conventions that call for this kind of precision-and-recognizability disambiguation, like WP:USPLACE and WP:USSTATION, and fly in the face of years of common sense decisions at RM, like the disambiguation of Algerian Arab (now a disambiguation page) to Algerian Arab sheep, and British White to British White cattle. Per WP:POLICY, the purpose of guidelines is to record actual community best practice, not try to force someone's made up idea about how things should be, like changing the meaning of English words, or preventing RM from doing what RM routinely does. Retaining this does the former, and removing it does the latter, both to pretend the word "disambiguation" doesn't mean what it means, and as to elevate concision above every other criterion, against the clear wording of policy. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 16:04, 25 March 2016 (UTC)
- Comments (since there seems to be confusion): Wait! You mean I just don't like it doesn't mean we can change things just because? How about used in conjunction with and while ignoring all rules.
- We have many policies and guidelines and a single one can not be used in disregard of others. I was under the impression we can not ignore all rules, if it is against consensus, even if we don't like it, unless we can sneak it in under the radar. FYI -- we should not really (according to policy) attempt to make or change policy by using WP:BRD unless we "ignore" the policy on Proposals and Good practice for proposals. The first states: "Proposals for new guidelines and policies require discussion and a high level of consensus from the entire community for promotion to guideline or policy.". The second: "If consensus for broad community support has not developed after a reasonable time period, the proposal is considered failed. If consensus is neutral or unclear on the issue and unlikely to improve, the proposal has likewise failed.".
- Further, the procedural policy explains the process in detail that is located in the second part. A request for comments here is only one part of that process and not a determining factor for an outcome. Some confusion at Wikipedia:How to contribute to Wikipedia guidance#Policy discussions seems to be at odds with policy and may contribute to errors. Policy (Good practice for proposals) states the process for any proposed changes to policy:
- 1)- The first step is to write the best initial proposal that you can.
- 2)- Authors can request early-stage feedback at Wikipedia's village pump for idea incubation and from any relevant WikiProjects.
- 3)- Once it is thought that the initial proposal is well-written, and the issues sufficiently discussed among early participants to create a proposal that has a solid chance of success with the broader community, start an RfC for your policy or guideline proposal in a new section on the talk page, and include the {rfc tag along with a brief, time-stamped explanation of the proposal.
- 4)- A RfC should typically be announced at this policy page (and/or the proposals page, and other potentially interested groups (WikiProjects).
- There appears to be some confusion at Wikipedia:Centralized discussion concerning sequence or location but policy seems clear.
- DAB: Does cover the topic question above as well as WP:AT. Although there are editors that seem to prefer parenthetical disambiguation, or unnecessary use of such on article titles (Britannica style), this has not been established by any broad consensus but more just the opposite according to policy natural disambiguation is preferred and parenthetical disambiguation as a last choice. The etymology of "disambiguation" would be "not unclear" which would be "not clarified". An article title should be precise enough to unambiguously define the topical scope of the article, but no more precise than that.. Recognizable, natural, and concise goes along with this. DAB states: "Disambiguation is also sometimes employed if the name is too ambiguous, despite not conflicting with another article (yet),". Consistency also goes along with these and gives more than one reason why we have Flemish Giant rabbit, Continental Giant rabbit, French Lop, Lop rabbit, Angora rabbit, and so forth. Certainly using the more common name according to references. Common sense is also thrown in there somewhere.
- Conclusion: We should not attempt to change or change policies or guidelines on a whim or by any local consensus. The process is made somewhat complicated to prevent easy changes. DAB and AT do a fine job. I think if editors disagree then they should probably follow the above procedures. Otr500 (talk) 12:39, 26 March 2016 (UTC)
- The portion of WP:DAB that you quote was added a couple of days ago. A clear consensus in support of this recent addition would neatly resolve the difficulty of having an orphaned sentence in the lead that isn't explained in the body of the guideline.--Trystan (talk) 18:50, 27 March 2016 (UTC)
- It's also based on material present in the original, longer version. The WP:GAME here is to keep whittling away at the material in hopes that it can be made to seem out-of-place in its context. If context is restored, it's obviously belongs where it is. This was true 8 months ago, when the context material was originally reduced, on the basis (Francis Schonken's objection) that the example article titles were "unstable". This wasn't actually true then, and 8 months have proven conclusively that it's not true now, so the original rationale to decontextualizing the sentence has evaporated. Better yet, later editors like Dick Lyon have pointed out that entire NC guidelines, like USPLACE and USSTATION, rely on the exact same principle and have for years, so the examples Schonken didn't like almost a year ago were could have been replaced at any time anyway. A challenge against this provision now is a challenge against multiple naming conventions that have been stable for years. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 21:59, 1 April 2016 (UTC)
- 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
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)
Schoolblocks
In the early days of Wikipedia, shared IP templates were created to point out hey, this IP represents a bunch of people, don't assume what happened yesterday is from the same person as what happened today, and if you do block this IP, keep it short because there will be collateral damage. It was not unusual to see blocks say things like have your system administrator contact me to have this block removed. Sysops have become block happy with schools (and some even [to having elaborate plans of identifying school IPs]). What is particularly disturbing to me are rangeblocks on entire states' networks, such as this block by @Materialscientist:, and this block by @JamesBWatson: (which I will start an AN/I about tomorrow), neither of which appear to have had any discussion prior to their implementation. These rangeblocks on state networks bother me; even if you want to argue schools cause more trouble than productive activity, libraries and universities could in the future join those IP ranges and no one would even know unless someone requested unblocking. I know of at least one public library system in Florida which uses the Florida Information Resource Network, and it would be affected if a sysop similarly rangeblocked FIRN to stop the pom-pom type editing tests and vandalism from schools. In my opinion, the real vandalism problem we have is with adults trying (sometimes quite cleverly) to inject their POV into articles, not middle and high school kids writing "Katryna <3" on pages; I can't tell you how many times I've seen grown-up places like big corporations, federal agencies, and the military tagged with {{CheckUser block}}, something that happens when there's serious issues, and something I rarely ever see schools tagged with despite the schoolblocks not stopping logged in editing. If anything, it seems we should be heavy handed with those kind of places instead of schools (and this comes from a grown 24 year old, not some kid crying discrimination). Also in my opinion, we have enough mechanisms in place to deal with the pom-pom type editing tests and vandalism without putting into effect blocks that could stop a good faith contributor from making his/her first edit. As I said on JamesBWatson's talk page, the pom-pom type editing tests and vandalism that schools spew out are like sugar ants on the floor in a restaurant. It doesn't look good if the customers or the Division of Restaurants see them, but they're really not hurting anything. Not to mention, anyone stumbling upon it can easily remove it. What really hurts Wikipedia is the POV pushing and deliberate factual inaccuracies, which are more like cockroaches on the cook line in a restaurant, which may not be spotted as quickly by customers but spread disease causing germs. When the customers get sick from eating at the establishment, they may not return. Similarly, if someone gets bad information from Wikipedia, they may not return. That's not to say that schools aren't responsible for that kind of vandalism too, but I would argue there's not any more of that kind of vandalism from schools than there is from Hospital Corporation of America or General Motors; most of what I see from schools is stuff like "CHRIS IS A FAG" or "My name is Siobhan and I am deeply in love with Jeff <3." I would also argue that a lot of this so-called "school vandalism" isn't vandalism at all per official policy, but rather editing tests. How can we differentiate "silly vandalism" from editing tests unless there's a definite pattern (vandalism to the same article over and over again, excluding the high school's article or the town's article, posting the same thing over and over again, etc), especially when you consider how many times this pom-pom type vandalism gets self reverted? Assuming good faith according to official policy, I don't think a lot of the "school vandalism" is vandalism at all, but rather students curious about the editing process. That's not saying some of it isn't vandalism with malicious intent, but it's really hard to tell what is and isn't vandalism if editing experiments aren't vandalism, unless there's a real behavioral pattern. Another thing to consider is that, despite admins claiming the IPs they block do nothing but vandalize, we do get good faith edits from these IPs. 204.86.170.3 is currently under a long term block, despite this, this, this, this, this, this, and this, and if you look at the rest of the contributions, they were all just silliness and easily spotted and reverted. Then you have this state college IP with a mix of good and bad long-term blocked because @Gilliam: wants to stop the pom-pom editing tests at all costs.
Regardless of where you stand on this, I think we could probably agree that we need real policy on this matter rather than admins just blocking IPs and IP ranges for however long they want because IPs make editing tests and vandalism. PCHS-NJROTC (Messages) Jesus Christ loves you! 07:26, 26 April 2016 (UTC)
- A school is an institution where the same people will be around for a long time; and we only block school IPs where there actually are long-term problems. In {{school block}}, it says "Due to persistent vandalism (see edit log), anonymous editing from your school, library, or educational institution's IP address is blocked (disabled)"; unless there in a case of "persistent vandalism", {{school block}} shouldn't be used. And while there is a significant amount of disruption from "grown-up places like big corporations, federal agencies, and the military", I would tend to think that such places tend to have a higher percentage of edits which are actually helpful towards Wikipedia than schools do. עוד מישהו Od Mishehu 11:58, 26 April 2016 (UTC)
- We only block school IPs where there actually are long term problems. Then we need official policy on that, because no one told some of tge sysops that. PCHS-NJROTC (Messages) Jesus Christ loves you! 17:39, 26 April 2016 (UTC)
- These admins should see Wikipedia:Blocking policy#Blocks should be preventative, where it says that blocks should be used to "prevent imminent or continuing damage and disruption to Wikipedia"; this means that long term blocks should only be made for an IP address or range f there is long-term disruption coming from there. (While open proxies are an exception, these are rarely in schools and don't get {{school block}}s.) And admins who use templates for block reasons should know what the template says - in this case, "Due to persistent vandalism. עוד מישהו Od Mishehu 20:08, 26 April 2016 (UTC)
- I agree, however, the sysoos I'm referring to will often use excuses like this IP does nothing but vandalize or there was vandalism 24 hours after the last block. If someone is going to sit there and tell me the same person patiently waited 2+ years for a block to expire and returned to vandalize some more, and for some reason didn't use other mediums to launch an LTA campaign (and these IPs are rarely tagged for socking, it seems), their obsession with maliciously using the school computers maliciously is probably something they should see a a doctor about. Otherwise, following WP:AGF, it's probably just test edits if there's no clear sign someone is trying to sabotage the encyclopedia. PCHS-NJROTC (Messages) Jesus Christ loves you! 22:14, 26 April 2016 (UTC)
- These admins should see Wikipedia:Blocking policy#Blocks should be preventative, where it says that blocks should be used to "prevent imminent or continuing damage and disruption to Wikipedia"; this means that long term blocks should only be made for an IP address or range f there is long-term disruption coming from there. (While open proxies are an exception, these are rarely in schools and don't get {{school block}}s.) And admins who use templates for block reasons should know what the template says - in this case, "Due to persistent vandalism. עוד מישהו Od Mishehu 20:08, 26 April 2016 (UTC)
- We only block school IPs where there actually are long term problems. Then we need official policy on that, because no one told some of tge sysops that. PCHS-NJROTC (Messages) Jesus Christ loves you! 17:39, 26 April 2016 (UTC)
- If the contributions on a school IP address (or mobile, which sometimes gets mistaken for a school) are a mix of good and bad edits (particularly if the ratio is typical of IP edits and it's just that those IP addresses are shared by more users) blocks should usually be shorter. Longer blocks would still be appropriate in some cases - persistent disruption by the same user, multiple edits suitable for revision deletion criteria 2 or 3 over a period of time, or IPs with numerous vandalism or test edits and nothing else. Peter James (talk) 23:19, 26 April 2016 (UTC)
- Then why is Florida SouthWestern State College, at 169.139.115.67, and Charlotte County Public Schools, at 204.86.170.3, subject to extended blocks? Those IPs are a mix of good and bad. Yes, there's a lot of test editing, but not an unbearable amount of it (we don't have a daily dose of vandalism sprees from them), to me, the damage caused by the type of abuse from those IPs (very minimal) is not enough to stop even one good faith edit for an extended amount of time. Additionally, what is your take on long-term rangeblocks impacting entire states, just to stop pom-pom type test editing? Seems like overkill to me. Overkill that is not supported by policy. Policy calls for long term blocks to stop idiots like User:Grawp or User:Mmbabies, not infrequent pom-pom type test editing. PCHS-NJROTC (Messages) Jesus Christ loves you! 00:56, 27 April 2016 (UTC)
- Sometimes a school IP address is the source of a sudden burst of vandalism, suggesting that either a single person or a couple or more kids playing around together are responsible. In such cases a warning very often puts an end to it, and if not then a short block will usually do the job: very often a block for a few hours is enough, and a couple of days at the most. Obviously, if the IP address also has a history of constructive editing, then that will weigh against a block of any sort, and if a block is considered it will even more likely to be a short one. Personally, I never place any kind of IP block without first carefully checking the history of the relevant IP address(es) over a time period of significantly more than the length of the block. If constructive edits are a substantial proportion of edits in the time period involved (even a substantial minority), then I do not place the block, even if it has the unfortunate effect of allowing some vandalism to continue.
- Very different from the case of one sudden burst of vandalism (or several sudden bursts well separated) is the situation where a particular IP address or group of addresses is the source of endless continuing vandalism or other unconstructive editing. Very often, I have known the following to happen. An IP address is blocked for a short time, such as 48 hours, the vandalism returns immediately after the block expires. Several things happen to the vandalism edits: most of them are either reverted by editors who do nothing other than revert, so that nobody else is aware that teh vandalism took place, or else simply not noticed, so that some articles have false information in them for months or even years. A minority of the edits are reverted by editors who post warnings on the relevant IP talk page. Because these warnings come only for a small minority of the edits, and because warnings from a while ago are treated as stale, it can be a very long time before the vandalism is reported AIV or in some other way brought to the attention of an administrator. Consequently, what often happens is that short blocks alternate with long periods when the IP address is not blocked, and vandalism flourishes on a large scale. Short blocks are therefore of very limited use in these cases of persistent vandalism, in contrast to the situation I described above of sudden short bursts of vandalism.
- Blocks are supposed to be preventive, not punitive. If a particular IP address or range of addresses has been the source of thousands of vandalism edits over the course of years, with no constructive edits or only a couple of dozen constructive edits among those thousands, then blocking the relevant IP address or addresses stands to prevent that vandalism. The argument that it is unlikely to be the same person who has patiently come back and vandalised years later is totally irrelevant, as the vandalism is the same whether it is one person or 200 people. The only possible way that I can think of that anyone could think that is relevant if they are thinking in terms of punishing the vandal, rather than in terms of preventing the vandalism. I also can't imagine why "this IP does nothing but vandalize" is described above as an "excuse" for blocking: isn't the fact that an IP address is the source of nothing but vandalism a perfectly good reason for blocking it? I also don't understand why "there's no clear sign someone is trying to sabotage the encyclopedia" is put forward as an argument: if there are edits at the rate of a hundred per day which add false information to articles, then those edits are disruptive and harmful, whether the intention is "to sabotage the encyclopedia" or not, and it seems reasonable to try to stop it. One's speculations as to what may be the intentions of the disruptive editors may influence the language one uses to describe it (e.g. whether one uses the word "vandalism") but there is no logical reason why a belief that disruption is not done with malicious intent should discourage one from taking what steps one can to prevent continuation of the disruption. The editor who uses the pseudonym "JamesBWatson" (talk) 09:41, 27 April 2016 (UTC)
- But one could also argue IPs in general persistently vandalize. My understanding of policy is that blocks for persistent vandalism are to prevent the Energizer Bunny from going and going and going and going... with malicious edits. I would agree that if an IP produces a daily dose of vandalism sprees it's silly to mess around with short term blocks. However, I'm sure we can agree that CCPS and FSW, both under long term block, were not producing daily doses of vandalism sprees, and had some good faith contributions. Another case study: 208.66.198.214 belonging to Gulf Coast High School in Naples, Florida. Mostly silly, pom-pom type nonsense edits, easily spotted and reverted, and even if it's not, everybody pretty much knows that Wikipedia is editable, and an occasional occurrence of nonsense isn't going to destroy our reputation (in fact, someone spotting that kind of obvious nonsense and reverting it could be the next administrator, bureaucrat, checkuser, ArbCom member, or Wikimedia Foundation employee's first interaction with Wikipedia, thus creating a net positive). But, three of the last 50 edits were constructive, that may have been that person's first edit, and that person may have registered an account now and could be writing featured articles now thanks to that first taste of editing Wikipedia. As for /16 ranges, don't be silly, just don't. For one thing, word of mouth has gone around that those institutions were blocked from editing for the last two years while that range was blocked, so it shouldn't come as a surprise that the only edits coming from 100s of thousands of users were curious test editors. Furthermore, if you look at the last 50 or 100 edits coming from a Comcast or CenturyLink /16 at the wrong time of the day (not any specific time, just wrong place wrong time) you'll probably find nothing but vandalism there too. PCHS-NJROTC (Messages) Jesus Christ loves you! 19:25, 27 April 2016 (UTC)
- According to one study, about 82% of all anonymous edits are actually not vandalism. If a single IP address/range shows around 20% vandalism, that's average; if it shows around 20% non-vandalism, that's very bad. If a single sample of 50 edits shows not a single non-vandalism edit, you can be almost completely (around 99.5%) certain that at least 90% of its edits are vandalism. עוד מישהו Od Mishehu 21:09, 27 April 2016 (UTC)
- If you're saying that these IPs should be blocked because they produce more bad then good, fine, but there needs to be policy on it. One of our foreign language sisters blocks all schools from editing based on a policy they created. Maybe we need that kind of policy here? Also, "test edits" are not vandalism per WP:Vandalism, but "silly vandalism" is. How do you differentiate between the two of them? I still think these blocks do more harm than good. PCHS-NJROTC (Messages) Jesus Christ loves you! 21:36, 27 April 2016 (UTC)
- I keep hearing the same rhetoric over and over again, these IPs vandalize, these IPs vandalize, what I don't see is anyone actually refute my arguments. 1,000 instances of obvious test editing or silly, pom-pom type vandalism does zero real damage to Wikipedia, whereas 10 good faith edits actually help Wikipedia, sometimes more than other times. Consider the net gain vs. the net loss. The exception to this is the ones who monkey around with numbers, which I see a lot of from schools, but at the same time, if a person does this from a school vandal patrols will be more suspicious of it than if the same person does the same thing from a cell phone, so the chances of it being caught and reverted are greater if it comes from the school computer vs. the vandal's cellular carrier. The most legitimate reasons I can think of to block schools are to protect the school IP user from being bit by someone assuming bad faith or being targeted for harassment by vicious trolls who have nothing better to do than harass Wikipedians. Other than that... I think we'd get farther if there were some way to technically restrict cheerleaders and ball players from editing Wikipedia. Seriously though, if you analyze the content of the pom-pom vandalism, I think it's more an issue with those two categories of people taking pleasure in monkeying around with the encyclopedia than school IPs themselves, and those categories of people happen to have access to the school networks. I've occasionally seen it be band members or ROTC members, so that wouldn't eliminate all vandalism, but probably would stop more of the vandalism than the school blocks do. (And yes, that's what you call a joke. User:Maddiekate gave us good edits. I guess you just can't generalize. But I am being somewhat serious, because although I know blocking them would be ridiculous even if it were possible, it seems like a disproportionate amount of the pom-pom vandalism does come from cheerleaders and ball players, that's why I call it pom-pom vandalism.) PCHS-NJROTC (Messages) Jesus Christ loves you! 22:00, 27 April 2016 (UTC)
- The net loss is that our editors spend time fixing preventable disruptive editing when they could be improving the encyclopedia elsewhere... Caeciliusinhorto (talk) 20:50, 28 April 2016 (UTC)
- Some people are content contributors. But then we have people who do nothing but vandal fighting. It seems a lot of the RC patrolmen only do RC patrol. If that's their niche, why do you assume they will take up improving the encyclopedia elsewhere if all vandals suddenly disappeared? PCHS-NJROTC (Messages)Growing tired of the bullshit day by day. 15:54, 2 May 2016 (UTC)
- The net loss is that our editors spend time fixing preventable disruptive editing when they could be improving the encyclopedia elsewhere... Caeciliusinhorto (talk) 20:50, 28 April 2016 (UTC)
- I keep hearing the same rhetoric over and over again, these IPs vandalize, these IPs vandalize, what I don't see is anyone actually refute my arguments. 1,000 instances of obvious test editing or silly, pom-pom type vandalism does zero real damage to Wikipedia, whereas 10 good faith edits actually help Wikipedia, sometimes more than other times. Consider the net gain vs. the net loss. The exception to this is the ones who monkey around with numbers, which I see a lot of from schools, but at the same time, if a person does this from a school vandal patrols will be more suspicious of it than if the same person does the same thing from a cell phone, so the chances of it being caught and reverted are greater if it comes from the school computer vs. the vandal's cellular carrier. The most legitimate reasons I can think of to block schools are to protect the school IP user from being bit by someone assuming bad faith or being targeted for harassment by vicious trolls who have nothing better to do than harass Wikipedians. Other than that... I think we'd get farther if there were some way to technically restrict cheerleaders and ball players from editing Wikipedia. Seriously though, if you analyze the content of the pom-pom vandalism, I think it's more an issue with those two categories of people taking pleasure in monkeying around with the encyclopedia than school IPs themselves, and those categories of people happen to have access to the school networks. I've occasionally seen it be band members or ROTC members, so that wouldn't eliminate all vandalism, but probably would stop more of the vandalism than the school blocks do. (And yes, that's what you call a joke. User:Maddiekate gave us good edits. I guess you just can't generalize. But I am being somewhat serious, because although I know blocking them would be ridiculous even if it were possible, it seems like a disproportionate amount of the pom-pom vandalism does come from cheerleaders and ball players, that's why I call it pom-pom vandalism.) PCHS-NJROTC (Messages) Jesus Christ loves you! 22:00, 27 April 2016 (UTC)
- If you're saying that these IPs should be blocked because they produce more bad then good, fine, but there needs to be policy on it. One of our foreign language sisters blocks all schools from editing based on a policy they created. Maybe we need that kind of policy here? Also, "test edits" are not vandalism per WP:Vandalism, but "silly vandalism" is. How do you differentiate between the two of them? I still think these blocks do more harm than good. PCHS-NJROTC (Messages) Jesus Christ loves you! 21:36, 27 April 2016 (UTC)
- Perhaps many of the non-vandalism IP editors make more edits, but from fewer IP addresses, so the average IP address will have a higher percentage of disruptive edits than that. Should it make a difference whether the same people are editing through random and constantly changing IP addresses in a /16 range or all from the same 2 or 3 IP addresses in the same range, if the edits are just as likely to be vandalism? Peter James (talk) 23:52, 27 April 2016 (UTC)
- I'd love to see some proof that people were IP hopping in that North Carolina range. Actually, from my experience encountering IPs in that range, I think most of them are static IPs with each individual IP representing thousands at a particular district (I know Avery County Schools fall under that range and their IP seems to be static). I'm not as sure on the Washington as a lot of the times you'll see one edit coming from there and never see them again, so it's quite possible Washington School Cooperative has some system where users hop around the range, but I've never noticed it. If the IPs are rotating rapidly, that changes everything. However, if Florida Information Resource Network ever gets rangeblocked like this, I can attest to the fact that those IPs are static because I used to constructively edit from one (mostly logged in though; sometimes the system would hiccup and I'd get logged out). PCHS-NJROTC (Messages) Jesus Christ loves you! 00:22, 28 April 2016 (UTC)
- As a former teacher, I applaud temporarily blocking school IPs when students vandalize Wikipedia. The inconvenience of contacting an admin and getting the block undone encourages educators to pay more attention to what their students are doing on-line... To supervise the students, and teach them proper on-line behavior. Blueboar (talk) 00:24, 28 April 2016 (UTC)
- Comments like that can only serve to encourage arguments from passion. The purpose of the blocks is in no way, shape or form to compel educators to become more involved with their students. Primergrey (talk) 00:50, 28 April 2016 (UTC)
- I never said getting teachers to be more involved with their students was the purpose of the block... But it may be the result of a block (and a positive one in my book). Call it an unintended consequence if you want. Blueboar (talk) 02:03, 28 April 2016 (UTC)
- My point is simply that, since most of this discussion is about the purpose of the blocks, a related but ultimately irrelevant interjection cannot aid in reaching a conclusion.Primergrey (talk) 02:27, 28 April 2016 (UTC)
- I never said getting teachers to be more involved with their students was the purpose of the block... But it may be the result of a block (and a positive one in my book). Call it an unintended consequence if you want. Blueboar (talk) 02:03, 28 April 2016 (UTC)
- Key word: Temporarily. I have no problem with short bans, or even long ones (six months or a year) if the IP does nothing but spew vandalism day after day after day. It seems a lot of these blocks turn out to essentially be permabans, because the IPs just keep getting reblocked for a year, two years, three years, five years, ten years, etc, and I do have a problem with that. I agree it's good for staff to recognize the importance of monitoring students activities (CCPS does that at district level, Winn-Dixie and the two hospitals I worked at also monitored activity very closely). PCHS-NJROTC (Messages) Jesus Christ loves you! 00:39, 28 April 2016 (UTC)
Add the State of Utah to the mix: https://en.wikipedia.org/w/index.php?title=Special:Log/block&page=User%3A205.121.0.0%2F16. Frankly, I don't like these unilateral state blocks; these should be discussed before being implemented. PCHS-NJROTC (Messages) Jesus Christ loves you! 05:27, 28 April 2016 (UTC)
Policy proposals by User:PCHS-NJROTC
Restrict discretionary blocks on IP addresses
- Restrict blocks on IP addresses to six months, except in the case of open proxies.
- Allow exceptions to this in truly exceptional cases, such as cases of demonstrated long term abuse. Not just because an IP belongs to a school and has a history of kids being kids (unless the second proposal is also passed).
- Require discussion and community consensus before implementing the long term block.
- Require CheckUser involvement before placing a long term block to determine exactly how bad the collateral damage would be if an extended softblock were put in place. An IP which may appear, to an ordinary contributor or administrator, to produce nothing but vandalism could, in theory, be responsible for 100 good faith accounts being created.
- Require an abuse report be sent to the ISP, school, agency, company, etc before placing the long term block? This would be a courtesy to the network administrator, to let them know someone's actions are going to cause something that could adversely affect other users to take place.
- Restrict blocks on IP ranges to three months, except in the case of webhosts.
- Again, allow exceptions to this in truly exceptional cases, such as cases of long term abuse.
- Again, require discussion and community consensus before implementing the long term block.
- As with the exceptions to the prohibition on long term IP blocks, any time a sysop wishes for an exceptional long term range block needs to consult with a CheckUser to see how bad the collateral damage would be.
- Yet again, should we require an abuse report be sent first?
- Restrict the use of rangeblocks to IP hoppers, not just because a sysop wishes to schoolblock an entire /16 range.
- Scratch that if the second proposal is implemented.
- Prohibit immediate implementation of another six month block following the expiration of a previous six month block, and require sysops to reset to short term blocks in assumption of good faith.
- Blocking a shared IP for six months over one sporadic unhelpful edit after a long term block expiration, claiming persistent vandalism, is as silly as the vandalism itself.
- Assume that silliness is always going to come from schools and only block them if there is truly disruption that requires administrative intervention, such as a vandalism spree or block evasion, not just because there's been a handful of editing tests over a months time.
- Once again, scratch this if the second proposal is implemented.
Advantages
- Any IP block has the potential to create collateral damage. I would rather 500 people keep the RC patrolmen busy than lose one good faith contributor due to heavy handedness.
- This establishes official policy on the length of blocks, vs sysops placing them for however long they wish. In the past, {{Shared IP edu}} actually said that blocks would only go up to one year. Now I see them for 5+ years.
- Some people may, for various reasons, be unable to request an account or make an account elsewhere. Some students or employees may not have access to email from school or work (and are very likely not to have an official email address from their institution as the block templates say to use when requesting an account) and may not have internet access elsewhere.
- In cases of schools, often time the actual damage to the project by their pom-pom vandalism is very minimal; I find it's often someone being silly rather than someone actively trying to cause serious disruption. In contrast, any time someone takes an interest in becoming an editor, it's a good thing for our project. We have a lot of good contributors who are students and school employees.
- Shared IP do give us some good edits, even some good Articles for Creation submissions.
Disadvantages
- School IPs are a major source of test editing and removing the blocks will mean more test editing.
Block all educational institutions on sight
- As soon as an editing IP address is determined to belong to a school, put an immediate, long term softblock on it.
- Duration should be comparable to that of open proxy blocks.
- Must know that it is a school, none of that "likely a school" business.
- If an educational institution owns an entire /24 or /16 range, block the range.
- Do we treat colleges, universities, libraries, and military basic training facilities different from high schools and school districts?
- Here's some examples to take into consideration when making the decision: 69.88.160.1, 169.139.115.67, 64.56.87.252, 131.247.0.0/16, 132.170.0.0/16, 128.227.0.0/16, 144.174.0.0/16, 131.91.0.0/16, 139.62.0.0/16, 204.29.160.0/24, 129.171.0.0/16, 169.139.217.0/24, 131.247.152.4, 199.87.224.33, 192.35.61.0/24, 147.253.0.0/16, 204.193.117.66 (library), 74.5.231.189 (library), and 169.139.19.96 (library).
- Change the {{school block}} template to reflect the new policy change.
Advantages
- Educational institutions generate a lot of test editing and vandalism. Blocking them all will eliminate this.
- Editing from a school IP opens one up for WP:Harassment. Worst of all, a really vicious troll could get mad at someone at a school for undoing their vandalism, post harassing comments on the IP's talk page, and cause mental anguish for a totally different person.
- This could result in Wikipedia being completely blocked out by the institution, meaning people couldn't even read Wikipedia.
- Again, considering the ugliness of some of the trolling, one has to question whether someone under 18 has any business contributing here anyway. Should elementary school students be subjected to random vandals calling them cunts or faggots? Should middle and high school students be subjected to cyberstalking by vandals? Is this a liability for Wikipedia or the Wikimedia Foundation?
Disadvantages
- These blocks could prevent someone from making their first edit, and they may not bother (or may even be unable) to make an account.
- A young editor may feel unworthy of contributing to the project after seeing that their school is blocked.
- These blocks could interfere with class projects.
- IPs could be reassigned.
- Blocking schools just pushes the vandals onto other mediums, such as cell phones. Vandalism is, frankly, easier for RC patrols to spot
coming from a high school than coming from a cell phone; you can often tell what IPs are institutional (school or otherwise) when RC patrolling. PCHS-NJROTC (Messages)Growing tired of this project day by day. 04:03, 29 April 2016 (UTC)
Comments
- Oppose. This is WP:BURO overkill looking for a solution when no one has shown that an actual problem exists. Further we shouldn't be changing the entire blocking policy, revising template and doing a multitude of changes via a discussion at WP:VPP. Propose these separate if you'd like but I'm not going to support five-ten wholesale changes at the same time. We are only blocking anonymous editing at these places. Editors can still log-in. I don't care about whether or not we can patrol and stop vandalism, the point of the matter is we shouldn't have to waste time on this just for the abstract possibility that blocking a school will somehow hinder some great potential editor from coming here if they don't know they can vandalize articles with abandon and have to instead create an account before doing that. The fact that blocking a school doesn't solve all vandalism isn't the point, the point is whether we are overall better off having the school blocked. -- Ricky81682 (talk) 00:32, 30 April 2016 (UTC)
- I'm glad you think that trying to establish some form or order here, instead of the chaos we currently have with admins doing things which affect thousands of users just as they please, is a waste of time. However, feel free to comment, support, or oppose any of my ideas individually; it doesn't have to be a wholesale motion. PCHS-NJROTC (Messages)Growing tired of this project day by day. 04:49, 30 April 2016 (UTC)
- I Oppose this motion
The wikipedia project is about democratising knowledge. That has to be the core of any discussion regarding censorship. Schools shouldn't be singled out simply because they are schools. I agree with the policy of blocking anonymous.school.users but genuine contributors may rely on school internet connections. Any there may be a case to be made for a general promotion of school involvement. Shinyapple (talk) 01:36, 30 April 2016 (UTC)
- I was playing devil's advocate with the proposal to block schools. Anonymous editing (or at least account creation) is just as important as logged in editing for people who solely rely on their school's internet connection (particularly in K-12 schools. If a student has no internet at home, (s)he probably doesn't have an email account even if the school allows students to access email from school, so (s)he can't request an account. I'm glad there's no raging support for a policy to block schools on sight, because now I can use that in arguments against long-term school blocks. PCHS-NJROTC (Messages)Growing tired of this project day by day. 04:49, 30 April 2016 (UTC)
- I don't understand that argument at all. If a user has to edit from school because they don't have internet access from home, it is extremely likely that either (a) they have an email account provided by the school, or (b) they can create an email account with a free webmail service using their school internet access. If you believe that there is a significant number of people who can only edit wikipedia using school-based internet and do not have an email address and cannot gain access to an email address, it would be fantastic if you could support that point, because in my experience that is not at all the case. Caeciliusinhorto (talk) 14:46, 30 April 2016 (UTC)
- I don't think too many middle and high schools provide school email accounts to students, and in fact, I think many of th prohibit the use of email from the school computers (and actively block the free email providers). Charlotte County Public Schools is this way. I will look online for some acceptable use policy links. Public school is a lot different from college. PCHS-NJROTC (Messages)Growing tired of the bullshit day by day. 19:47, 30 April 2016 (UTC)
- All the schools in my area (in the UK) provide their own email accounts to students; I am very surprised to hear that this is not common in the US. IIRC, my school didn't block any of the major webmail providers either. Caeciliusinhorto (talk) 23:16, 1 May 2016 (UTC)
- See page 7. You're just going to have to take my word for it that they don't give out student email accounts (they do however have intranet stuff like KidBiz2000/TeenBiz2000 and Florida Virtual School), but the only email permitted in the network is the teachers' district email accounts. Anything else is considered personal use. Actually, good-faith editing of Wikipedia would be a violation of the AUP, but is that our problem? I can get you a screenshot of the block page on Gmail if you don't believe it. Section 300.3 of Sarasota County's Code of Conduct has a similar policy prohibiting Using a computer, video, camera or program in any manner other than for appropriate educational purposes, but I honestly don't know if they block the free email providers like Charlotte County does. Only way I can think of to accurately find out would be to pull into the parking lot at North Port High School and scan for an open wi-fi hotspot. PCHS-NJROTC (Messages)Growing tired of the bullshit day by day. 04:52, 2 May 2016 (UTC)
- All the schools in my area (in the UK) provide their own email accounts to students; I am very surprised to hear that this is not common in the US. IIRC, my school didn't block any of the major webmail providers either. Caeciliusinhorto (talk) 23:16, 1 May 2016 (UTC)
- I don't think too many middle and high schools provide school email accounts to students, and in fact, I think many of th prohibit the use of email from the school computers (and actively block the free email providers). Charlotte County Public Schools is this way. I will look online for some acceptable use policy links. Public school is a lot different from college. PCHS-NJROTC (Messages)Growing tired of the bullshit day by day. 19:47, 30 April 2016 (UTC)
- I don't understand that argument at all. If a user has to edit from school because they don't have internet access from home, it is extremely likely that either (a) they have an email account provided by the school, or (b) they can create an email account with a free webmail service using their school internet access. If you believe that there is a significant number of people who can only edit wikipedia using school-based internet and do not have an email address and cannot gain access to an email address, it would be fantastic if you could support that point, because in my experience that is not at all the case. Caeciliusinhorto (talk) 14:46, 30 April 2016 (UTC)
- My district, the Pasadena Unified School District, gives every student an email, and they don't block anything except for porn, social media, and torrents. Here's the C:File:2015-16 PUSD Parent Student Handbook.pdf, which has the Acceptable Use Policy in it. To be honest, I didn't even read it before I signed it, which is my fault. But that shows how much kids don't care these days. TJH2018talk 01:23, 3 May 2016 (UTC)
- Funny thing is I was going to ask you that and hadn't gotten around to it (although I was going to ask about LAUSD, not knowing any better)... This is news to me, I thought it was common place for districts to block personal email. Of course, CCPS blocks Wikipedia too (again... after it had been unblocked, which I think was an accident); they're very authoritarian with their webfilter. It's a big surprise to me though because the guy who runs/ran the webfilter (who I used to email all the time when I was in high school) told me that the law required them to lock things down tight like that, but maybe the laws are different in California. PCHS-NJROTC (Messages)Growing tired of the bullshit day by day. 01:54, 3 May 2016 (UTC)
- My district, the Pasadena Unified School District, gives every student an email, and they don't block anything except for porn, social media, and torrents. Here's the C:File:2015-16 PUSD Parent Student Handbook.pdf, which has the Acceptable Use Policy in it. To be honest, I didn't even read it before I signed it, which is my fault. But that shows how much kids don't care these days. TJH2018talk 01:23, 3 May 2016 (UTC)
- Oppose This is solution looking for a problem. All of the proposals seem to throw nuance out the window, our admins are chosen for their discretions so lets allow them to use it. Our current procedure is not broken, so lets not fix it. HighInBC 15:58, 2 May 2016 (UTC)
- Our current procedure is not broken... Hahahahaha I almost spat my Dunkin Iced Coffee out when I read this ignorant comment. In addition to being a Wikipedian, I am a Conservapedian, and I have seen the results of excessive blocks there, and it's happening here too. PCHS-NJROTC (Messages)Growing tired of the bullshit day by day. 19:23, 2 May 2016 (UTC)
- Oppose per HighInBC. I will refrain from making ad hominem attacks based on the proposer's comment immediately above. BethNaught (talk) 19:39, 2 May 2016 (UTC)
- I'm opinionated and unafraid to say things that may hurt some feelings. If you don't enjoy encouraging test editors to contribute constructively or playing whack-a-mole with the vandals, you know there are articles you could be editing or creating instead of doing RC patrol. No one is making you do RC patrol. The only ones who are so in favor of long-term IP blocks are RC patrols (which I do plenty of myself) who think they are Barney Fife with his one bullet. PCHS-NJROTC (Messages)Growing tired of the bullshit day by day. 19:45, 2 May 2016 (UTC)
- I was referring to Conservapedia, but if you want to denigrate and slur RC patrollers who can barely keep Wikipedia safe as it is, be my guest. BethNaught (talk) 19:48, 2 May 2016 (UTC)
- RC patrol is a laudable thing to do, I enjoy doing it myself personally, but it desensitizes some people that they're like cops beating a petite young mother with a billy club outside of Publix for stealing a can of baby formula. Speaking of political stances... the people screaming "school IPs vandalize, school IPs vandalize!" remind me of the liberals screaming "guns kill people, guns kill people!". No they don't, people using school IPs vandalize, and people using guns kill people. PCHS-NJROTC (Messages)Growing tired of the bullshit day by day. 20:06, 2 May 2016 (UTC)
- I was referring to Conservapedia, but if you want to denigrate and slur RC patrollers who can barely keep Wikipedia safe as it is, be my guest. BethNaught (talk) 19:48, 2 May 2016 (UTC)
- I'm opinionated and unafraid to say things that may hurt some feelings. If you don't enjoy encouraging test editors to contribute constructively or playing whack-a-mole with the vandals, you know there are articles you could be editing or creating instead of doing RC patrol. No one is making you do RC patrol. The only ones who are so in favor of long-term IP blocks are RC patrols (which I do plenty of myself) who think they are Barney Fife with his one bullet. PCHS-NJROTC (Messages)Growing tired of the bullshit day by day. 19:45, 2 May 2016 (UTC)
- No thank you. We checkusers already have more than enough to do. I will note that over the years we periodically see schools *requesting* that their IPs be blocked because they do not want their (frequently traceable) IPs misused to vandalize Wikipedia. The students can still *read* Wikipedia even when the IP is blocked. Risker (talk) 04:14, 3 May 2016 (UTC)
- Some of that comes from trolls. Some of it comes from students unfamiliar with our policies. Other times it comes from administration and I would direct them to contact me via email from their district email address if I were an admin reading such request. Wikipedia is having trouble with editor retention, and the students' ability to read Wikipedia is irrelevant if Wikipedia falls into disrepair because of excessive blocking chasing away new editors. PCHS-NJROTC (Messages)Schoolblocks are like gun-control, they only stop good faith contributors. 04:32, 8 May 2016 (UTC)
- Oppose The proposal to restrict blocks on IPs is deeply flawed and appears to be based on the peculiar circumstances of an individual who wants to edit from school networks regardless of what problems those networks have caused. One point that I did not notice above is that relentless vandalism is a very big turn-off for many good content builders who wonder why they are contributing to a project which cannot take reasonable steps to defend itself against nonsense. Johnuniq (talk) 04:55, 3 May 2016 (UTC)
- I have an account, unless there's a hardblock, I can edit from schools and other shared IPs all I want. Not that there's much use in editing something that very may well go by the wayside within 10 years as long as simple minded people are running the project. Wikipedia is going to die because too many IPs are going to be blocked in attempt to stop the inevitable from happening in an open project and the only people who are going to go out of their way to become contributors are going to be people that have something to gain from registering (POV pushers, paid editors, spammers, vandals, etc).
GunsShared IPs don't killpeoplearticles, people using them do. Ha, I remember the initiatives we launched to support libraries, and to try and attract more female users, what about the libraries we block (school libraries, college libraries, and public libraries mistaken for schools), and what about all of the girls/young women we block with schoolblocks and anonblocks, poking that silly looking schoolhouse in front of them almost like some sort of insult? What about all of the test editing girls that we should be trying to convert into constructive editors? I'm not talking about the hard core, long term abuse vandals, I'm talking about the simple test editors, I'm sure at least some of them could be converted if the right efforts were made to do so. We're no longer a free, open project, so I think someone should propose a change in our slogan. PCHS-NJROTC (Messages)Growing tired of the bullshit day by day. 05:11, 3 May 2016 (UTC) - Something else worth adding. If someone can't handle someone coming in and vandalizing their creation, only for the vandalism to promptly go away, how are they going to react to someone making legitimate edits to their creation? PCHS-NJROTC (Messages)Schoolblocks are like gun-control, they only stop good faith contributors. 06:33, 3 May 2016 (UTC)
- I have an account, unless there's a hardblock, I can edit from schools and other shared IPs all I want. Not that there's much use in editing something that very may well go by the wayside within 10 years as long as simple minded people are running the project. Wikipedia is going to die because too many IPs are going to be blocked in attempt to stop the inevitable from happening in an open project and the only people who are going to go out of their way to become contributors are going to be people that have something to gain from registering (POV pushers, paid editors, spammers, vandals, etc).
- Comment All of these people harping about how one can create an account, just stop talking or find something you are more knowledgeable to talk about. Conservapedia briefly tried making everybody "request an account" and I don't think we had a single account registered while we had that setup. Do you think Wikipedia will fare better? I don't. PCHS-NJROTC (Messages)Schoolblocks are like gun-control, they only stop good faith contributors. 05:19, 3 May 2016 (UTC)
Intentional disruption by the very editor who is apparently making a good-faith proposal in this very section is not useful. |
---|
The following discussion has been closed. Please do not modify it. |
Humorous proposalSince we have successfully built a wall keeping all school children from editing Wikipedia through the use of schoolblocks, I propose that we build another wall to keep out the
|
Does IAR overule our Manual of Style?
In particular, does it overrule MOS:APPENDIX as Beyond My Ken claims here? How does obeying a MOS that the community has agreed upon "prevent you from improving or maintaining Wikipedia" (which is the requirement to invoke IAR)? --bender235 (talk) 20:16, 7 May 2016 (UTC)
- Ignore all rules trumps all other policies in my view. But this goes if, and only if, it makes improvements over general practice (for example because the situation is specific to the article under discussion). In the specific case you are referring to, the change makes the matter worse as the inline references are now suddenly labelled "notes" while the further reading section (which are not references to the article but suggested further reading) is listed under references. There is no reason to assume this exception is needed for this specific article, so without a very sound and complete argument why IAR should not be used. Arnoutf (talk) 20:22, 7 May 2016 (UTC)
- Can IAR "overrule" MOS? ... Yes. Does it "overrule" MOS in every case... Nope. Should it "overrule" MOS in some specific case... probably not. Blueboar (talk) 20:32, 7 May 2016 (UTC)
- Moreover, once IAR is cogently argued to support an edit against policy, if the edit is opposed then it must get consensus in order for it to stick. Since consensus is determined by the superior argument, all IAR really says is that the better argument in a consensus discussion isn't merely trumped by the argument that the opposite result is required by policy. IAR isn't a death pact which automatically overrules all other policies, even if there's a fairly decent reason for it, if the policy is supported by a better reason. Regards, TransporterMan (TALK) 21:00, 7 May 2016 (UTC)
- Does IAR overule our Manual of Style? Yes, IAR is a policy while the MOS is a guideline; and, as User:Arnoutf states, it is in some sense the most powerful policy. In this specific case, was it a good invocation of IAR? Absolutely not. The point of IAR is not to let policies or guidelines get in the way of improving the encyclopedia but unless there is a real good reason not to we stick with the guidelines and policies. There seems to be no such overriding reason here. The editor has a IAR banner on their talkpage but their edit summary here, where it uses its policy status as the means to the end, suggests a deep misunderstanding regarding IAR. To throw away the manual of style so willfully is half-deserving of a {{uw-mos1}} warning. I've seen the editor around quite a bit and although I don't remember specifics, I have favorable overall impression of their edits. Hopefully this is just a momentary lapse in judgment. Jason Quinn (talk) 17:54, 8 May 2016 (UTC)
IAR allows someone to ignore a rule when it prevents them from improving or maintaining the encyclopedia. Any action taken under it still needs to be accepted by the community, it is not a magic bullet. HighInBC 17:59, 8 May 2016 (UTC)
- Every instance of invoking IAR needs to be justified as being clearly in the interest of improving WP, it's not "get out of jail free" card. Roger (Dodger67) (talk) 18:13, 8 May 2016 (UTC)
- One case where you know IAR is inappropriate is when, without major privacy issues being relevant, you find out that consensus is against your action. עוד מישהו Od Mishehu 03:06, 9 May 2016 (UTC)
- IAR, on its very face, trumps all rules; but, as many here have suggested, it is not a mandate to break all—or any—rules, nor an invitation to mavericks, nor an excuse for selfishness or laziness. Strunk & White's Elements of Style, if I remember right, perhaps puts it better: "Break any of these rules, if you have a good reason." In other words, IAR is never, by itself, a sufficient grounds for departure from generally-accepted rules: it is merely a proviso allowing such departure in particular instances, where a given rule stands in the way of improvement or preservation of Wikipedia.
- The editing conflict cited by the OP seems to me to be a no-brainer: there are strong arguments in favor of a uniform order and format for fundamental elements of articles, particularly for appendices; and none that I can think of for variation. J. D. Crutchfield | Talk 16:40, 11 May 2016 (UTC)
Manual of Style (Japan-related articles) RFC
There is an important request for comment on WP:MOS-JA regarding the use of numeral romanizations in Japanese articles. The discussion can be found at Wikipedia talk:Manual of Style/Japan-related articles#RfC: Romanization of numerals in Japanese_articles. Lord Sjones23 (talk - contributions) 06:11, 9 May 2016 (UTC)
Implementing the results of the infobox RfC
I am going through the entire list of all forty candidates for US President in 2016 (many now withdrawn) and trying to make sure that the religion entry in the infobox of each page meets Wikipedia's requirements as per the recent RfC on this page
Here are the requirements for listing a religion in the infobox (religion in the body of the article has different rules):
- Per Wikipedia:Village pump (policy)/Archive 126#RfC: Religion in biographical infoboxes: "the 'religion=' parameter and the associated 'denomination=' parameter should be removed from all pages that use Template:Infobox person. Inclusion is permitted in individual articles' infoboxes as a custom parameter only if directly tied to the person's notability. Inclusion is permitted in derived, more specific infoboxes that genuinely need it for all cases, such as one for religious leaders."
- Per WP:BLPCAT: "Categories regarding religious beliefs (or lack of such) should not be used unless the subject has publicly self-identified with the belief or orientation in question, and the subject's beliefs are relevant to their public life or notability, according to reliable published sources" ... "These principles apply equally to lists, navigation templates, and Infobox statements".
- Per WP:CAT/R: "Categories regarding religious beliefs or lack of such beliefs of a living person should not be used unless the subject has publicly self-identified with the belief in question (see WP:BLPCAT), either through direct speech or through actions like serving in an official clerical position for the religion."
- Per WP:LOCALCON, a local consensus on an article talk page can not override the overwhelming (75% to 25%) consensus at Template talk:Infobox#RfC: Religion in infoboxes that nonreligions cannot be listed in the religion entry of any infobox.
The forty candidates are:
Extended content
|
---|
Source of list: United States presidential election, 2016
|
My goal is to determine whether Wikipedia's requirements are met for the above forty pages, and to insure that we have citations to reliable sources that meet the requirements.
Any help finding sources would be most appreciated. I have posted a query on many of the article talk pages. --Guy Macon (talk) 08:02, 9 May 2016 (UTC)
- As the closer of the RFC in question I don't think it would be appropriate for me to offer opinions on its implementation, but pinging Wehwalt as the editor with probably the most experience working with US politician articles at Wikipedia's higher end. ‑ Iridescent 20:06, 9 May 2016 (UTC)
- At Talk:Hillary Clinton there are comments that claim that your close is consistent with a position of "religion is relevant for every politician". You may wish to either confirm or correct that claim. --Guy Macon (talk) 21:37, 9 May 2016 (UTC)
- Arguably that is the case for US politicians at the higher levels. It is impossible for them to get elected without their religion being brought up and picked over by the pundits and journos. Only in death does duty end (talk) 00:02, 10 May 2016 (UTC)
- The US has never elected a president who did not profess a belief in Christianity at least to some extent. It's still relevant in American politics in a way, say, it is not in Australia, which has elected at least one atheist prime minister. Note the fascination with Obama's religion, from the Rev. Wright to today. I would say it is relevant to the office, at least until we elect a president without religious belief.--Wehwalt (talk) 01:28, 10 May 2016 (UTC)
- I don't think anyone disagrees that religion is still relevant in American politics. For that reason, there is likely to be at least some information on a candidate's religious beliefs in their article. What we're trying to determine here, however, is whether these candidates are also so notable for their religions that we should activate the reserved
|Religion=
field for them — just as we would for Ministers, Rabbis, Popes, Priests, Cardinals, Bishops, etc. Keep in mind that if religion is not already a significant part of Mr. Joe Politician's notability (i.e.; mentioned in the lead as a defining characteristic), it doesn't automatically become part of his notability when he declares his intent to run for US Presidency. The problem I expect the OP will run into, repeatedly, is that many editors don't realize that 'Religion' categories and fields in infoboxes are indeed reserved for people who are notable because of their religion; instead, editors wrongly believe that as long as a subject's religion is known and sourced, go right ahead and use the|Religion=
field. Xenophrenic (talk) 04:30, 10 May 2016 (UTC)
- Sigh. It appears that some of the editors who are working on Hillary Clinton do not agree, and are making good-faith claims that religion is automatically a defining characteristic of every US presidential candidate. It looks like I am going to have to post Yet Another RfC because they insist that the RfC at Wikipedia:Village pump (policy)/Archive 126#RfC: Religion in biographical infoboxes (and WP:BLPCAT, and WP:CAT/R, and WP:LOCALCON...) don't apply to US presidential candidates. And then, of course, whatever the result of the new RfC is, it won't be accepted either. So, what to do? I could really use some help here. All I want is sources that show compliance with our policies, but it keeps turning into a quagmire on every individual page. --Guy Macon (talk) 13:34, 11 May 2016 (UTC)
- Guy, your comments don't accurately reflect my position there, but as I'm the only one taking it I guess that's understandable. Improve the close of that RfC so that it clearly affirms a consensus on the notability point of your multi-point proposal, and I'll oppose inclusion at the Clinton article. As I said there, "This user abides by consensuses they disagree with." As for "quagmire", I looked that up in the dictionary and there was the Wikipedia logo. ―Mandruss ☎ 14:20, 11 May 2016 (UTC)
- I don't think anyone disagrees that religion is still relevant in American politics. For that reason, there is likely to be at least some information on a candidate's religious beliefs in their article. What we're trying to determine here, however, is whether these candidates are also so notable for their religions that we should activate the reserved
Discussion about No Personal Attacks
A discussion about a change to the no personal attacks policy has been proposed. Additional minds are requested at: Wikipedia_talk:No_personal_attacks#Personal_attacks_against_groups_of_people. HighInBC 17:01, 9 May 2016 (UTC)
Basic Data Page (A4 or 2xA4 max)
There are many excellent pages on Wikipedia BUT as an general-knowledge user rather than being an expert in any specific area I find that many articles are so large as to be very difficult to obtain the key data.
The introductory paragraph(s) vary greatly in quality - some are perfunctory, others begin to include quite small details.
When I look at, for example, Florence Nightingale - I don't need ALL 23 pages of the detail; nor do I need all the data for many topics I have had to look at recently. And I believe the assembled expertise of Wiki can build this secondary resource very well and very effectively and to the benefit of the Wiki-world.
SUGGESTION
That major articles and articles over, say, 8 pages are allowed or expected to have a 'Basic Details' section immediately after the introduction. Perhaps an alternative would be to have a section in addition to Article and Talk.
The aim would be to EXCLUDE the references as part of the print and to have a maximum of say two pictures - albeit that one picture can equate to a 1000 words.
I have created pages for this project to see how easy it is. I am very willing to create a page on almost any topic to show that this BasicA4 version is viable and useful.
(A Third alternative would be for this to be somewhat equivalent to the Childs' Wikipedia which has many fewer articles.) JK Joking99a (talk) 09:49, 10 May 2016 (UTC)
- The WP:LEAD is this, or expected to be so. --Izno (talk) 11:17, 10 May 2016 (UTC)
- But LEAD doesn't supply this and isn't even often anything approximating a worthwhile summary - such as an A4 page might offer. How do I push this idea a little further? Joking99a (talk) 10:44, 12 May 2016 (UTC)
- The response to "it's not often good enough" is for you to fix it, or at least tag it with {{lead too short}}. Pushing your idea is unlikely to go anywhere, and a proposal would likely be WP:SNOW-closed, because we already have a guideline which says "write a good summary in the lead", but you are always welcome to develop your idea and then propose it in a WP:RFC. --Izno (talk) 11:14, 12 May 2016 (UTC)
- 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)
Proposal to upgrade essay WP:BRD to official policy in edit warring issues.
A simple proposal. That BRD be upgraded to official policy. As an essay it is useful and thought - provoking. As policy I believe it would greatly increase discussion, editor retention through early and perhaps positive engagement with I.P's with potential to be useful and would lead to a steep drop in edit warring over a relatively short period of time. Just a rough initial series of thoughts here. If it gains any traction the community can discuss just how it would fit into existing policy. My initial thought is that it would replace 3RR as the bright line in edit warring issues, or that they can be used more in tandem. which the community can refine. Refusing to discuss a revert should be the trigger. It will give admins the power to nip (what are now) long drawn out and time-consuming visits to be board in the bud. Refusal to communicate is usually the major part of edit - warring. This would require communication at the earliest stage, and would weed out I.P's who are potentially WP:HERE from those who will just be a drain on the project's resources. It would also encourage more experienced registered editors with a documented reluctance to communicate to actually give their rationale for edits. Thoughts? Irondome (talk) 23:11, 10 May 2016 (UTC)
- Please review Wikipedia:Village pump (policy)/Archive 120#RfC: elevation of Wikipedia:BOLD, revert, discuss cycle to guideline status, held about a year ago. --Izno (talk) 13:25, 11 May 2016 (UTC)
- Izno Appreciate that. Looks to be covering similar ground. I doubt if consensus has shifted since then..Irondome (talk) 14:14, 11 May 2016 (UTC)
RfC: MOS vs COMMONNAME
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Proposed:
Resolve that style elements are not essential parts of the names of things. Modify WP:COMMONNAME to state that it defers to MOS as to style elements. ―Mandruss ☎ 10:22, 11 May 2016 (UTC)
The question remains unresolved. I know this because I'm not seeing any links to an unambiguous, community-level consensus in discussions. All I'm seeing is the same arguments being made in local discussion after local discussion.
That lack of resolution is causing undue conflict and costing untold editor time.
The issue is an open wound, and the project seriously needs an unambiguous consensus here, one way or the other. This is fundamental and foundational, and that means it should be addressed and resolved first—not allowed to fester indefinitely because it is highly controversial—even if that is difficult and painful. ―Mandruss ☎ 10:22, 11 May 2016 (UTC)
RfC survey: MOS vs COMMONNAME
- Support as proposer. 1. This is consistent with the application of MOS by other entities that have MOS. 2. Style elements are not necessary for disambiguation. 3. Style elements do not change essential meaning. 4. It does not elevate MOS to policy status if a single policy explicitly defers to it. 5. The project would benefit greatly from the elimination of this vast battleground, which diverts and distracts from more important issues. ―Mandruss ☎ 10:22, 11 May 2016 (UTC)
- Oppose this or any other proposal to make MOS compliance mandatory. The MOS is a cluster of arbitrary and sometimes contradictory proclamations written by whoever happened to shout loudest at the time the section in question was written, not a "manual of style" in any meaningful sense of the word, and shouldn't be taken remotely seriously. If you want the MOS and Wikipedia's usual practices to match with regards to a particular area, change the MOS to match our practices, not the other way around. ‑ Iridescent 10:29, 11 May 2016 (UTC)
- (adding) I'm assuming that by "style elements are not essential parts of the names of things", what you're proposing is that (for instance) Wikipedia have an article on Imac rather than iMac. You may want to make that clear. ‑ Iridescent 11:14, 11 May 2016 (UTC)
- Why is this argument advanced so seriously oh-so-often? The counter-argument is trivially {{sofixit}}--if you have a serious concern that the MOS is not internally consistent, or that it does not follow best English practices (or best Wikipedian practices--not the same things), you should work to change that, not base all future arguments related to the MOS-as-a-concept on this supposed fact. --Izno (talk) 11:36, 11 May 2016 (UTC)
- Because I consider the MOS a pointless talking shop and have got through the last decade ignoring it without suffering any apparent ill effects, so I couldn't care less what the half-dozen people who take it seriously (it's always the same names there) happen to have it saying at any given time. ‑ Iridescent 12:31, 11 May 2016 (UTC)
- Basically, you're admitting your argument is irrelevant to the discussion at hand? K. --Izno (talk) 12:36, 11 May 2016 (UTC)
You may want to make that clear.
I didn't feel the need to make it clear that there would be rare legitimate exceptions to this as with anything else. This is about a default policy. And I'm frankly surprised to see an editor with your experience, Iridescent, make that argument. ―Mandruss ☎ 13:21, 11 May 2016 (UTC)
- Because I consider the MOS a pointless talking shop and have got through the last decade ignoring it without suffering any apparent ill effects, so I couldn't care less what the half-dozen people who take it seriously (it's always the same names there) happen to have it saying at any given time. ‑ Iridescent 12:31, 11 May 2016 (UTC)
- Oppose Style very often is an essential part of a name so the premises is flawed. We should not be trying to dictate to the world how it should work, we should just be summarizing how it actually does work. Dmcq (talk) 11:58, 11 May 2016 (UTC)
- Opposed - If anything, the conflicts between COMMONNAME and MOS should be resolved in the other direction. Our MOS guidance should defer to COMMONNAME.
- To my mind, the single most important sentence in MOS is contained in the nutshell - where it says: "... it is a generally accepted standard that editors should attempt to follow, though it is best treated with common sense, and occasional exceptions may apply."
- The problem is that this key sentence is often ignored by our fellow editors who focus on conforming articles to MOS guidance... they think of MOS as a set "firm and fast RULES" - rules that should have no exceptions. That attitude needs to change. I strongly believe that, in situations when a significant majority of reliable sources all present a name using a particular stylization, that common stylization becomes included as part of the COMMONNAME. And if the common stylization it is contrary to what is indicated by MOS guidance... then we should make an exception to (otherwise good) MOS guidance, and follow the sources. Blueboar (talk) 12:19, 11 May 2016 (UTC)
- Oppose I'm completely with Blueboar on this one. It should be the other way round if we are going to explicitly state a preference. COMMONNAME already describes the accepted standard. If it is in conflict with the MOS, the MOS either needs to be ignored or adjusted. Only in death does duty end (talk) 12:42, 11 May 2016 (UTC)
- Oppose. MOS is for WP, only. COMMONNAME is derived from everyone else. There's no way WP can impose MOS on the outside world. I suppose there might be a few cases where the common name isn't very common, and some sources "fix" the name in ways that might conform to MOS, but those will be rare exceptions, already handled by IAR. --A D Monroe III (talk) 13:31, 11 May 2016 (UTC)
- Oppose per all. Johnbod (talk) 14:20, 11 May 2016 (UTC)
- Oppose First and foremost, decisions should be made based on the usability of the encyclopedia, hence COMMONNAME. MoS does help with usability, as a consistent(ish) style across WP can make reading easier, but it is not the priority. — crh 23 (Talk) 14:27, 11 May 2016 (UTC)
- Reject the premise – those who think that a "versus" relationship exists here are confused. Dicklyon (talk) 15:31, 11 May 2016 (UTC)
- @Dicklyon: I agree there there is confusion, but there is a "versus" relationship at the root of the discussion. I asssume we agree that capitalization is part of style and not part of a name. Then there are two ways to decide on the wording and capitalization of an article title. (1) Use WP:AT (not just COMMONNAME) to decide on the title of an article (2) apply capitalization as per the MoS. (2) Use WP:AT to decide on the title including how it should be styled, regardless of the MoS. These are genuine alternatives; the choice between them is real. Peter coxhead (talk) 16:46, 11 May 2016 (UTC)
- Both WP:AT and MOS:CAPS agree that we use sentence case for titles unless it's a proper name. I suggest using the discussion section below if you find a case where a difference between them was relevant to a title decision. Dicklyon (talk) 17:08, 11 May 2016 (UTC)
- @Dicklyon: I agree there there is confusion, but there is a "versus" relationship at the root of the discussion. I asssume we agree that capitalization is part of style and not part of a name. Then there are two ways to decide on the wording and capitalization of an article title. (1) Use WP:AT (not just COMMONNAME) to decide on the title of an article (2) apply capitalization as per the MoS. (2) Use WP:AT to decide on the title including how it should be styled, regardless of the MoS. These are genuine alternatives; the choice between them is real. Peter coxhead (talk) 16:46, 11 May 2016 (UTC)
- Oppose. Using the common name is an important principle of accessibility on Wikipedia while MOS is a guideline, something that helps editors format and structure the content they contribute. We should primarily think of our readers and only secondarily of our editors. --regentspark (comment) 16:02, 11 May 2016 (UTC)
- Oppose per Blueboar. The tail should not way the dog. oknazevad (talk) 17:03, 11 May 2016 (UTC)
- Oppose per Blueboar, who outlined my feelings much better than I could have. Calidum ¤ 19:19, 11 May 2016 (UTC)
- Support in spirit some clarification, but also reject the "versus" premise. There's an entire essay about why already, at WP:COMMONSTYLE. It is true that AT and the naming conventions guidelines defer to MoS on style matters (they do so in over a dozen places). However, "style" is broad and diffuse without a clear definition, and this is actually also true of proper names (the linguistic and philosophy definitions of the concept diverge), and how to determine what is the most common is often itself controversial. So there is necessarily a bit of overlap. MOS:TM, MOS:CAPS, etc., and WP:AT and the NC guidelines, already appear to adequately account for this. E.g., use "iPod" and "PlayStation", not "Ipod" and "Playstation", because the vast majority of reliable sources use those spellings (that's an MoS rule, independent of AT). What I do support strongly is that WP:COMMONNAME does need to be clarified that it is not a style policy, even if some style matters can sometimes – rarely – be part of a common-name determination on a WP:COMMONSENSE basis. I'll address specifics in the discussion section below. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 20:53, 11 May 2016 (UTC)
- 'There's an entire essay about why already, at WP:COMMONSTYLE'? Which you wrote. Dmcq (talk) 16:32, 12 May 2016 (UTC)
- And? Every essay was written by someone. Surely you realize they do not appear by magic out of nowhere. The point of essays is that they lay out once, and clearly, an argument we don't want or need to restate over and over again, and the point of referring to them is "go read this instead, so we don't waste time on this rehash again". — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 18:00, 12 May 2016 (UTC)
- 'There's an entire essay about why already, at WP:COMMONSTYLE'? Which you wrote. Dmcq (talk) 16:32, 12 May 2016 (UTC)
- I am agreed with SMC just above at "support in spirit some clarification, but also reject the 'versus' premise", as well as his extended comments below and conversation with Blueboar. --Izno (talk) 11:19, 12 May 2016 (UTC)
- Oppose per Blueboar et al. –Davey2010Talk 12:46, 12 May 2016 (UTC)
- Comment - Ok, it appears I asked the wrong question. As I see it now, the best approach is to SNOW fail this and start over with a new RfC (which I will leave to someone better qualified to frame this issue, I nominate SMcCandlish). I stand by my statements that we need dearly some kind of resolution here. ―Mandruss ☎ 13:51, 12 May 2016 (UTC)
- Oppose per almost everyone. A new RFC isn't needed, seems to be enough. Randy Kryn 17:14, 12 May 2016 (UTC)
- We have a SNOW consensus that COMMONNAME should not defer to MOS on style. That's great; the problem is that, apparently, no one but me felt that it should do so, or that that was even a viable question. So we have made no progress whatsoever as to the problem I described in the opener. We've had a bit of constructive discussion, but it was off topic within this RfC. There is no concise alternative proposal, and we couldn't !vote on it here if there were, not without creating an unworkable mess. This RfC was a misfire, and I don't think it seems to be enough. ―Mandruss ☎ 17:51, 12 May 2016 (UTC)
- I'm pretty sure that's not what you have. Any assertion to that effect would draw out the defenders of the MOS, just as an assertion that it should draws out the defenders of TITLE. The problem is not a "versus" relationship between these policies and guidelines, which actually work pretty well together, but rather between the people who want to shift the balance of responsibility between them. Better to just keep on coexisting, working together toward consensus results in article style and titles. We still have no examples of where this breaks down. COMMONNAME is a strategy in support of the Recognizability criterion. Following the recommendations of the MOS is a strategy in support of CONSISTENCY among other things. All worth considering, as TITLE says. Nowhere does it empower COMMONNAME to override other considerations. Dicklyon (talk) 18:20, 12 May 2016 (UTC)
- (edit conflict) We don't have consensus for that either. COMMONNAME doesn't address style at all. Negative reaction to an RfC misapproaching the issue is not consensus for an "anti-MoS" change in the extreme opposite direction, especially when many of the comments are about the erstwhile RfC itself and the lack of conflict between AT and MOS, rather than whether any changes should be made to either. It would be nice to see COMMONNAME clarified, but the approach to doing that is probably to work it out with AT, MOS, and RM regulars, who understand the effects of nuanced changes at these policypages. Village Pump is like ANI, a pot of emotional responses with insufficient background information and experience most of the time. The "common style" issue has been discussed before, and is nowhere near resolution yet. Aa recently at Jan. 2016 it was seriously proposed (with more support that most would have expected) to merge most of AT back into MOS. I more specifically raised the narrow issue you raised here, Mandruss, in late 2015 at WT:AT, and the response was basically "meh". That's probably because earlier in 2015 both MOS:TM and MOS:CAPS were adjusted, after substantial negotiation, to include wording that more closely aligned with COMMONNAME, in explicitly taking into account majority source usage, at the expense of some consistency. In Feb. or March of this year COMMONNAME was copyedited to stop burying its lead and otherwise being confusing, and this automatically brought it more into line with MoS (or, rather, corrected misinterpretations of it as conflicting with MoS). And so on. Incremental changing making the perception of conflict more and more moot.
Two years ago, virtually every day people were screaming about a "conflict between MOS and AT", and now the issue hardly ever arises. When it does, it can almost always be traced directly to the WP:COMMONSTYLE fallacy, the failure to distinguish between what the common name is ("PlayStation", however styled, vs. "PlayBox" or "WorkStation") and how it is styled ("PlayStation", "Playstation", "Play Station", "pLAYsTATION", "PLAYSTATION", "Play-STation", "Play-station", etc., etc.). The standards are different. COMMONAME wants us to choose the most commonly found name in reliable sources and run that through the criteria, which it will usually pass. It might have not that much of a majority (most common-name debates are about whether the statistical research to determine which name is more common was valid, because few people know how to use N-grams, etc., correctly). MOS:TM (and MOS:CAPS, etc.) expects that if a stylization does something non-standard in English (like using capitalization in the middle of a name, or starting a name with a lowercase letter, or using some kind of non-letter character in place of a letter, etc.) that it will be avoided unless it is found consistently in the vast majority of sources, not just a slight majority.
This is not a "conflict", it's a completely different analysis, of a separate matter. Failure to understand this is, as I noted elsewhere, is a general semantics problem, like being unable to understand the difference between the proper construction of a room and whether is painted (styled) white or off-white. Generally, people actually can tell the difference, and just want to pretend they can't because they have an interest in a promotional, non-neutral presentation of something; or they don't or won't understand that a specialist style for specialists to use with each other is often not how we write encyclopedic prose for the broadest audience ever; or they falsely believe that WP is a vote or a democracy swayed by off-WP demands ("It's 'SONY', dammit!"), or must do everything exactly the way some paper publications do it, especially those not really independent of the subject, but mired in it. WP's job is to summarize in encyclopedic style the facts as found in reliable, independent, secondary sources, not to ape the impenetrable, obtuse style of technical and legal publications, or the hipsterish, hyperbolic style of entertainment journalism and blogging. So, I don't see what we need another RfC for. AT and MOS work together much better today than they did only a year ago. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 19:03, 12 May 2016 (UTC)
- Ok. I saw a lot of policy debate in article talk—disagreement about what the policy actually says. Not how it applies to that article, but what it means for all articles. This essentially turns article talk into dozens or hundreds of scattered extensions of this page and other community-level venues, with a ton of overlapping and conflicting discussion. I saw that as extremely inefficient and counterproductive. I felt that kind of thing should be done here, once. If the community is ok with that, I'll just live with it. Now, are we prepared to close? ―Mandruss ☎ 19:29, 12 May 2016 (UTC)
- We have a SNOW consensus that COMMONNAME should not defer to MOS on style. That's great; the problem is that, apparently, no one but me felt that it should do so, or that that was even a viable question. So we have made no progress whatsoever as to the problem I described in the opener. We've had a bit of constructive discussion, but it was off topic within this RfC. There is no concise alternative proposal, and we couldn't !vote on it here if there were, not without creating an unworkable mess. This RfC was a misfire, and I don't think it seems to be enough. ―Mandruss ☎ 17:51, 12 May 2016 (UTC)
- Oppose: Echoing Blueboar and everyone who followed in assent that this is entirely backwards. COMMONNAME must not be held hostage to MOS. Fylbecatulous talk 21:26, 12 May 2016 (UTC)
- Strong oppose per Iridescent. MOS is routinely at variance with what everyone does, and its dictates are handed down by a tiny minority of people who feel like continually arguing over minutiae and then imposing their will on everyone else. Aside from general MOS provisions, such as WP:ERA and WP:ENGVAR, there's no reason to bow to the MOS types on article titles when we shouldn't be bowing to them on content. Nyttend (talk) 01:16, 13 May 2016 (UTC)
RfC discussion: MOS vs COMMONNAME
- Comment Personally I think pushing too hard for standards is damaging. Unless there is a clear reason otherwise I think articles should be left as they are written and not changed by people who know nothing about the topic. Yes the MoS is liberally sprinkled with exceptions like if the subject habitually said something else then it should be like that - but someone will go around anyway pointing to the MoS and changing it without knowing as much as the original author -and the author if still around will be beaten down by having some TLA WP refernece stuck into the change summary. Dmcq (talk) 12:39, 11 May 2016 (UTC)
- What about the scores of very knowledgeable editors who lack the writing skills to create a quality article? Are those who can write well to excuse themselves from improving the article because they lack knowledge of the topic? That, I think, more than anything in the MOS, would be at odds with real-world practices. Also, I had to look up TLA just now and, although it took ten seconds, I think I'll be alright. Primergrey (talk) 13:08, 11 May 2016 (UTC)
- Hopefully these very knowledgable editors actually know or read up enough to contribute. No I'm principally worried about people who'll for instance if something is called X-3 will put in a minus sign and change the 3 to 'three' because small numbers should be spelled out. Dmcq (talk) 14:31, 11 May 2016 (UTC)
- It's not happening, since it's clear that doesn't pertain to serial or model numbers, per MOS:NUM. The concern doesn't seem warranted. What's the evidence of a problem in this regard? Show us someone trying to rename the B-2 bomber article to "B-two". As for the earlier point in this sub-conversation: The vast majority of WP content is written by non-experts in the field in question. This is possible because WP is based mostly on secondary sources not primary. It takes no expertise to review the all major books on a topic and summarize what they're saying. It takes a great deal of expertise to wade through 2,000 journals worth of primary, unreproduced research and try to figure out what may have validity and what is bogus. There's a reason this is not Academipedia. Experts are of great use on WP in correcting Dunning–Kruger effect incorrect assumptions about source material (including the secondary), and weeding out secondary material that does not actually reflect the consensus in the field in question. But it is true that many scientists and other specialists are not good writers, and few people at all are great writers of encyclopedic material, which is a discipline unto itself, albeit a volunteer hobby for most who engage in it. That doesn't make 5 or 10 years of intensive experience at it less of an acquired and honed skill. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 19:03, 12 May 2016 (UTC)
- Hopefully these very knowledgable editors actually know or read up enough to contribute. No I'm principally worried about people who'll for instance if something is called X-3 will put in a minus sign and change the 3 to 'three' because small numbers should be spelled out. Dmcq (talk) 14:31, 11 May 2016 (UTC)
- Comment I think it would be helpful to the discussion if it were spelt out exactly which bits of "style" guidance in the MoS are under consideration. I guess from previous discussions that these include capitalization, the use of hyphens and various kinds of dashes, the use or non-use of periods/full stops in abbreviations and acronyms, and the use or non-use of commas in contexts like "Smith, Jr". What else?
- Another of my concerns is picking out WP:COMMONNAME from WP:AT; stylization also bears on some of the other principles, like precision and consistency. For example, we could re-open the discussion of how to style the English names of organisms based on showing that for a particular organism the title case style was the most common, even though for most organisms of the same kind the sentence case style was the most common. (I quickly found examples using Google ngrams: e.g. "European robin" beats "European Robin" but "Manx Shearwater" beats "Manx shearwater".) If COMMONSTYLE is to be used, it should be applied to categories of article title, not individual ones. Peter coxhead (talk) 15:34, 11 May 2016 (UTC)
- Another "what else" is character substitutions. This sort of this is already covered at MOS:TM pretty well. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 19:03, 12 May 2016 (UTC)
- Comments: The key point is that the most common styling/stylization of something is not automatically used at Wikipedia, but often eschewed, because the most common styling is frequently not independent of the subject, but outright promotional. In other cases, it may be a highly specialized style that is confusing to encyclopedia readers and found only in ivory-tower journals (or in in-universe geekery materials, or buried in technical jargon that assumes a decade of professional experience, or whatever – by no means is all "specialized", very-narrow-audience publishing of an academic character). In yet others, it may be a pop-culture topic, with most coverage appearing in low-end entertainment press publications, that use informal, efficiency-at-all-costs journalistic style, which has little in common with the encyclopedic register (news style is mostly about getting the most content into the smallest columns as possible, for quick visual scanning; encyclopedic style is about maximum clarity in communication). Worse yet, much of that newsprint, especially in pop-culture topics (entertainment, sports, etc.) is often try-to-sound-hip-or-clever-at-all-costs even more than it is expediency-driven, and its clarify and neutrality terribly suffers as a result.
In short, WP, like all serious publishers, has a house style, and it applies by default regardless what the topic is, absent very strong reasons to override it, and when (not very often) overriding it helps rather than hinders reader needs (not editor, wikiproject, or external third-party desires).
The vast majority of the time that people make bogus "COMMONSTYLE" arguments, it's when they're pushing something that does not belong here. Often it's inappropriately promotional (e.g. capitalizing "SONY" to mimic the logo), jingoistic (stripping diacritics from the name of a sports figure who uses the diacritics, just because Americans are less familiar with the proper spelling and the sport governing body is too lazy to use them itself in tournament charts), or an attempt by specialists to force WP to write for its broad readership the same way the specialists write to each other in their own journals (most commonly this is a) Overcapitalization Of Things The Specialists Find Important In Their Context; b) the dropping of hyphenation of compound modifiers in cases where specialists know its a compound modifier but a 7th-grader does not, as in "medium-chain fatty acids" which many scientists want to write as "medium chain fatty acids"; and c) the use of obtuse and often redundantly wordy terminology instead of plain English – "myocardial infarction" at every occurrence instead of "heart attack" which is better in a non-medical article, "party of the first part" instead of "first party", etc.).
:This is not a conflict between MOS and AT, it's a conflict between encyclopedists who understand the nature and audience of the publication, and people who (often subconsciously) try to misuse the encyclopedia as a tool for things that others will interpret as snobbery, aggrandizement, and/or browbeating.
— SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 21:02, 11 May 2016 (UTC)
- yes we do have a house style... But it is a house style that we can change if there is consensus to change it. If there is a consensus that we should follow source usage for stylization of names, then our "house style" should be changed to reflect that consensus. Blueboar (talk) 21:31, 11 May 2016 (UTC)
- A three-part response:
- There is no one source usage for much of anything. When there is a near-universal option, of course we use it, rather than make up something (thus iPod, PlayStation, and Deadmau5, not "Ipod", "Play Station", or "Deadmaus", which are almost unattested in RS). When a non-trivial number of the RS use one or more alternatives to an odd stylization, we use a less promotional/ridiculous/confusing option (thus Alien 3 not "Alien3" and Pink (singer) not "P!nk"). (MOS:TM already covers all this in quite a bit of detail.) When the sources are not uniform in a stylistic treatment, we have no reason to go with a visually aggrandizing, silly, or obfuscatory option, and plenty of reasons not to. The huge and stressy RfC about capitalization of common names of species settled this issue over two years ago (as did plenty of RfCs before that, and more since).
WP consensus is to use whatever sourceable style best serves the encyclopedia readers' needs. It can't rationally be any other way. Yes, theoretically, we could have a change of consensus to do everything the most common way, like a techno-hipster theme overall (e.g. [32]), andhaving banner ads all over the place, and HUGE SCREAMING ALL-CAPS HEADINGS, and stupid-but-funny cat GIF animations, and social networking features, and sneaky user-tracking cookies, and writing like bloggers and sports journalists, and photos and icons all over the place crowding our the text, and breaking up ever article into a "1 of 24 >" pane series so content is doled out a mobile-screenful morsel at a time, and yadda yadda yadda. Of course, we don't do any of these things, in spite of how common they are. The COMMONNAME policy fragment is about using commonly-recognizable names. It is not a policy to use the most numerically common style, or stylization, or capitalization, or layout, or font, or typographic effects, or coloration, or [insert whatever else here]. Virtually nothing about WP is done the most common way, but rather the best way we can muster for an encyclopedic purpose and audience (and, secondarily, a volunteer and largely untrained and nonprofessional editorship, though even that consideration has greatly reduced over time, as both regular editors get better at it, and the number of brand new people arriving to try editing for the first time has shrunken greatly now that the novelty has worn off). If anything, COMMONNAME sticks out, like some weird hairy growth on the nose of policy.
WP:COMMONNAME could actually be deleted with no harm to the project. Few people bother to actually read it and think about it. It is not a central policy concern of WP:AT in any way. It's nothing but a default to try first as the most likely candidate to fit the actual naming criteria at WP:CRITERIA. It is not itself one of the criteria at all, and those criteria would remain and still be applied, in the absence of the COMMONNAME wording that refers to them. It is actually superfluous instruction creep that has done little but generate drama and fanaticism. In the end, all of this flag-waving about how style "should" be part of COMMONNAME is just a bunch of pointless extra distraction about what is itself an underlying pointless distraction. We do not need a section in the policy that says "Try this first, as a shortcut for complying with the actual policy requirements" if people are just going to fetishize it and battleground indefinitely against any infidels who do not accept it as somehow replacing the actual policy requirements it was written simply as a funneling tool for. Mistaking COMMONNAME for the actual naming criteria is like taking a road trip to California, reaching the "Welcome to California" sign at the state border, then going home because you've seen California now. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 11:07, 12 May 2016 (UTC)
Examples?
I think that part of the problem is some people feeling more aligned with MOS or TITLE – but is there a problem, or just a perception? It might help to look at examples. If you know a case where there was a discussion of conflict between MOS and TITLE (or the COMMONNAME) section, list it here so we can look and understand what was at stake. I found one to start with:
- Sunn O))) – At Talk:Sunn_O)))#Requested_move_2, entire rationale for moving back from Sunn (band) to the stylized trademark (still pronounced "Sun") was given as "COMMONNAME". Personally, it looks to be squarely in the domain of MOS:TM, and could have been resolved within the recommendations there, which already says "When deciding how to format a trademark, editors should choose among styles already in use by sources (not invent new ones) ..." As Frungi wrote there, "Support unless we can cite some substantial reliable sources that do not include the decorative characters. Everything I’m seeing in e.g. Google News does include them, so it seems to me like we’re inventing a style by using 'Sunn' bare." So it looks like no modification of MOS is needed to get it to agree with the result that people were looking to get from COMMONNAME. The move was supported "per MOS". No conflict. The discussion was primarily over whether plain "Sunn" is a style in use or not, and it was decided not. No "MOS regulars" objecting, as far as I can see. Dicklyon (talk) 00:53, 12 May 2016 (UTC)
- Dot the i – At Talk:Dot_the_i#Requested_move_2, both COMMONNAME and MOS:CT were invoked. Both lost to the lack of consensus. They were both on the same side, of moving to Dot the I, but an interpretation of a blood splat over a capital I on a movie poster was taken by many editors as evidence that the lowercase i was intended. No conflict, just harmony between TITLE and MOS in this case, and conflict with fanboys. Dicklyon (talk) 05:59, 12 May 2016 (UTC)
- Mandruss has recently been working on styling per WP:JR, and may be reacting to comments by Blueboar on the talk page about that; he suggested "I don't dismiss the WP:COMMONNAME argument. When the majority of sources that are independent of the subject present the name with a comma, so should we... As that is the most recognizable variation." and "My view has consistently been that we should adopt a similar standard to COMMONNAME when it comes to issues like this." But COMMONNAME does not propose any such standard, so this idea went nowhere. And NONE of the related recent RM discussions had anyone claiming that COMMONNAME was something to consider with respect to the comma styling question, and all closed in favor of following the preference expressed by the MOS; these:
- Talk:Andrew_L._Lewis_Jr.#Requested_move_04_April_2016
- Talk:Robert_Downey_Jr.#Requested_move_04_April_2016
- Talk:Feodor_Chaliapin_Jr.#Requested_move_2_April_2016
- Talk:Benjamin_O._Davis_Sr.#Requested_move_2_April_2016
- Talk:Larry_Mullen_Jr.#Requested_move_20_March_2016
- Talk:Desi_Arnaz_Jr.#Requested_move_20_March_2016
- Talk:Arthur_Ochs_Sulzberger,_Jr.#Requested_move_2_April_2016
- Talk:USS_Frank_E._Petersen_Jr.#Requested_move_7_April_2016
- Talk:Harry_K._Daghlian_Jr.#Requested_move_20_March_2016
- Talk:Dale_Earnhardt,_Jr.#Requested_move_17_April_2016
- Talk:Alan_Hale,_Sr.#Requested_move_18_April_2016
- Talk:Barnett_McFee_Clinedinst_Jr.#Requested move 24 April 2016
- Talk:Martin_Luther_King,_Jr._Day#Requested_move_22_April_2016
- Talk:Harry_Connick_Jr.#Requested_move_04_May_2016
- Hundreds of other comma restylings have gone unchallenged; nobody has suggested that any of the names became less recognizable without the comma; nobody (that I can recall) has suggested looking to see what a majority of sources do (doing so would mean nullifying the MOS, which a few people would like, but there was a big consensus to prefer the commaless style, as essentially all modern style and grammar guides recommend, so this would not fly). I see no actual conflict between TITLE and MOS here, even if Blueboar does and would prefer to throw out the MOS. As with MOS:TM, WP:JR makes allowance for exceptions if a name is found that is consistently styled one way in sources; but no such have been found so far. Dicklyon (talk) 19:48, 12 May 2016 (UTC)
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)
Suppressed RevDel'ed edits
Theres nothing in talk but why were these edits suppressed? Nothing in talk or otherwise for removing the content additions from history? [33][34]. What is WP doing with lack of accountability? My page someone claims its content vio but that can be reworded by consensus instead of suppressing itLihaas (talk) 16:08, 13 May 2016 (UTC)
- Wikipedia:Oversight#Complaints explains what to do. --Jayron32 16:42, 13 May 2016 (UTC)
- @Lihaas and Jayron32: This isn't an Oversight issue, it's a revision deletion issue. According to the revision deletion guidelines, discussion of those actions should happen on the administrators' noticeboard. {{Nihiltres |talk |edits}} 16:57, 13 May 2016 (UTC)
- Why did you bring this here? You were specifically invited by the editor to open a dialog with them if you had any questions about the removal or thought it was in error. It appears you underestimate how seriously we take copyright violations at Wikipedia and have a misunderstanding regarding the nature of our licensing policy. We cannot "reword" copyright violations because the violation "taints" any subsequent derivative work. Copyright-offending material must be deleted. Jason Quinn (talk) 18:07, 13 May 2016 (UTC)
- The logs for both pages say that the redactions were done by Diannaa, due to copyright issues. עוד מישהו Od Mishehu 06:16, 15 May 2016 (UTC)
- @Lihaas: The edit was detected on April 30 by a bot as being a potential copyright violation, and was reported here. I removed the content on the 5th of May and revision-deleted it under criterion RD1 of the revision deletion criterion and left a short note on your talk page. While in an ideal world it would be nice to post on the article talk page first and discuss how the content should be re-worded, in reality this is not going to be possible, as there's 75 to 100 copyright violations being detected by this bot every day. The content is readily available at the source newspaper article here, or if you wish I could send you a copy of the removed material via email. If you feel my actions violated policy and you wish to bring them to the attention of the wider community, I suggest posting at WP:AN as recommended in the revision deletion policy page. — Diannaa (talk) 13:45, 15 May 2016 (UTC)
- The logs for both pages say that the redactions were done by Diannaa, due to copyright issues. עוד מישהו Od Mishehu 06:16, 15 May 2016 (UTC)
Arbcom Probation Templates
I just noticed that several articles that had been on article probation, but no longer are, still had the associated notices on their talk pages and were still included in the Category:Articles on probation. (For those interested, the particular articles should be relatively easy to find from Talk:First_Baptist_Church_(Hammond,_Indiana)#Removing_Arbitration_Probation_Template.)
I would like to propose that, if it is not already part of the policy, that we modify the policy and procedure for Arbcom sanctions so that articles under probation have the notice removed when they are no longer under probation. I imagine there are likely instructions somewhere for what to do when a decision like that is rescinded. I noticed that we strike out the decision. The instructions should be changed to explicitly note that articles ought to have the notice removed from their talk pages and removed from the category at the same time that the original sanction is struck on the respective Arbcom page.
I'm not sure if this particular case was just an oversight and it is the general policy to do that, but if it is not the case, then it ought to be modified. Zell Faze (talk) 05:36, 14 May 2016 (UTC)
- Havent looked through any relevant policy pages, but this looks like a good idea. עוד מישהו Od Mishehu 06:13, 15 May 2016 (UTC)
RfC: Wikidata in infoboxes, opt-in or opt-out?
![]() |
|
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)
!Votes (Wikidata)
- Switch to opt-in, per below. Curly Turkey 🍁 ¡gobble! 01:05, 15 May 2016 (UTC)
- Switch to opt-in. Ruslik_Zero 08:19, 15 May 2016 (UTC)
- Switch to opt-in. Editor participation in such additions is important for verification, appropriateness, size of infobox, etc. Peter coxhead (talk) 08:24, 15 May 2016 (UTC)
- Switch to opt-in (mostly per below). — Rhododendrites talk \\ 12:40, 15 May 2016 (UTC)
- Continue opt-out: it is the whole point of having structured data – every editor does not have to re-invent the wheel. Assume WP:GOODFAITH that the structured data is verified just like any other facts in Wikipedia. –BoBoMisiu (talk) 13:37, 15 May 2016 (UTC)
- BoBoMisiu—my rationale below mentions nothing about whether the data is verified. Please respond to the actual rationale, which has nothing to do with good or bad faith. Curly Turkey 🍁 ¡gobble! 20:52, 15 May 2016 (UTC)
- @Curly Turkey: I read what is written again. The question is
"about how such data should be imported"
, the rationale is described by you as"editors lose control over the articles they edit"
, i.e. about who controls how and what data is displayed. The example of ISBN to me seems like the ideal use of structured data with little reason to exclude it. It is easier to correct structured data in a silo than to correct many articles that cascade from it. Another template that uses structured data is {{authority control}} – would your proposal also require an editor to opt-in for those kinds of templates which are not infoboxes but just as unverified? Nigel Ish's comment about Wikidata not being sourced may be a system problem or a classification problem but, just as with other content, editors can change it. –BoBoMisiu (talk) 23:02, 15 May 2016 (UTC)- BoBoMisiu—It is easier to correct structured data in a silo than to correct many articles' ...': again, you've misunderstood what the RfC is about. This is not about overriding what data is in Wikidata with local data—it's not about replacing the value for ISBN at Wikidata with a local value (let's assume we have no desire to do so). Nor is it about the reliability of Wikidata (let's assume it's perfect). It's about how we choose what to display, whether inclusion of each individual field should be explicit or automatic. Curly Turkey 🍁 ¡gobble! 23:15, 15 May 2016 (UTC)
- @Curly Turkey: I think I understand, and used {{authority control}} for comparison. I think it should be automatic, i.e. continue opt-out. If it displays incorrect content than correct the wikidata. If classes of infoboxes need to exclude some wikidata, then those templates should be changed; but if instances of infoboxes need to exclude some wikidata, then it should be overridden in the instance. If the concern is editors do not see content of new or changed wikidata fields, then that is a wikidata watchlist problem. I see the difference between the data and the presentation of the data. –BoBoMisiu (talk) 23:31, 15 May 2016 (UTC)
- BoBoMisiu: If it displays incorrect content than correct the wikidata.—the fact that you keep bringing this up shows you are still misunderstanding the what the RfC is about. We are assuming the data is correct, and that Wikidata is a good thing. This RfC is strictly about the display of this data in infoboxes. Curly Turkey 🍁 ¡gobble! 00:27, 16 May 2016 (UTC)
- @Curly Turkey: I think I understand. I assume all structured data is a good thing; I do not assume all structured data is correct; I think opt-out should continue for presenting that data in templates, including infoboxes. If I am misunderstanding, then is the RfC about aesthetics of a larger box? –BoBoMisiu (talk) 01:32, 16 May 2016 (UTC)
- Aesthetics would be one argument, but there are other concerns (such as: is every piece of data even appropriate for an infobox?). When I say "we are assuming the data is correct", I mean the argument to opt-in is not based on the correctness of the data—that would be an argument against Wikidata itself, which is not what this RfC is about. Curly Turkey 🍁 ¡gobble! 01:46, 16 May 2016 (UTC)
- @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
- 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. For template fields which should almost always be filled in – e.g. map image in {{infobox road}}, {{authority control}} identifiers – Wikidata should be included automatically, with the possibility of an override for rare cases which do not conform (opt-out). However, if the number of exceptions is not insignificant, and they can't be worked around (by using parser functions or lua to validate if the wikidata is appropriate – e.g. to not automatically include ISBN unless the publication year is after 1970s, which would stop older books having an ISBN displayed), then it should be opt-in. (And if the data in Wikidata is garbage, or not up to enwiki standards – e.g. Nigel Ish's WP:Ships examples – then it shouldn't be included at all) - Evad37 [talk] 03:24, 16 May 2016 (UTC)
- Continue opt-out, because well, it's sure going to screw up Template:Infobox road, which was designed to function this way. Or if not, at least provide an option so that individual templates do not have this new standard unwillingly enforced on them. --Rschen7754 03:39, 16 May 2016 (UTC)
- Continue opt-out (i.e., Wikidata as default unless an infobox opts out). I'm sympathetic to the proposal, but it looks like the core issue is getting consensus on each infobox's talk page on what parameters should default to Wikidata, as it's clear that the Wikidata shouldn't light up the whole infobox, but that call is for local consensus to decide. The bigger issue right now is turning on the firehose and getting the kinks worked out—looks like we're going one infobox at a time? @Ferret, has been working on arbitrary access with {{Video game review score}}s, and {{infobox video game}} is up next. On the technical end, I hope that someone with the chops is looking into how to have watchlisting on enwp simultaneously watchlist the wikidata entry. Time is nigh for toollabs:crosswatch. czar 05:26, 16 May 2016 (UTC)
- Continue opt-out I thought on a basic level this was to be decided on a infobox by infobox basis with local consensus, and for that matter, on a field by field basis. I don't see a reason to force opt-in across the board, if the infoboxes for particular projects prefer opt-out. If a particular field causes trouble on enwiki, the maintainers of that infobox can just remove Wikidata from that field till consensus develops. In some cases, Wikidata may just never be suitable. Each infobox can decide to do things as their needs dictate, and it should be easy enough in most cases to include a single parameter to cut off (i.e. opt out) of any wikidata population. -- ferret (talk) 12:21, 16 May 2016 (UTC)
- Continue opt-out: However, the method to opt out needs to be easier (as suggested) than by filling in ALL the empty params. A nice simple
|wikidata=no
(or similar) should suffice. As an encyclopedia, we have a duty to provide data that's both complete and accurate. Wikidata gives us this in spades, and it should be rare that we need (not want) to exclude it.Fred Gandt · talk · contribs
12:26, 16 May 2016 (UTC)- it should be rare that we need (not want) to exclude it—that statement needs backing up, and there's a lot more to editorial discretion that IDONTLIKEIT. There's little more to indiscriminate automatic inclusion than ILIKEIT. Curly Turkey 🍁 ¡gobble! 12:56, 16 May 2016 (UTC)
- I didn't say it will be or is rare; Do you disagree that it should be rare? Whether we LIKEIT or not, if the (Wiki)data is applicable, verified and accurate, we should be including it (accepting what should be rare exceptions, when editorial discretion takes over).
Fred Gandt · talk · contribs
14:13, 16 May 2016 (UTC)
- 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)
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)
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)
- 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)