Jump to content

Wikipedia:Village pump (policy)/Archive 128

Add links
From Wikipedia, the free encyclopedia
Village pump (policy) archive  

This page contains discussions that have been archived from Village pump (policy). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX, AY, AZ, BA, BB, BC, BD, BE, BF, BG, BH, BI, BJ, BK, BL, BM, BN, BO · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197

Designations or qualifiers for authorities cited

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

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

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

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

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

  • I am unaware of any such policy or guideline so if there is hopefully somebody will correct me. The first thing that sprung to mind was WP:CREDENTIAL but that really doesn't apply here since we are using the phrases like "twentieth-century historian" not as a title but as a qualifier (as you note). I suspect this is just a matter of editorial judgment. It sounds like a good idea to sometimes introduce individuals who are not famous to orientate readers. This helps answer any skeptical "Why should I care what Joe Bloggs' thinks?" questions that might bother them. But this is not a black-n-white rule because sometimes it will be clear from the surrounding text that we're supposed to assume the person has some relative background to qualify their opinion. For example if we're in a paragraph talking about critics reviews of a film, we don't need to introduced each person as a film critic because it will be assumed they are film critics within that context. So any GA reviewer always requiring qualifiers ("film critic") and even secondary adjectives ("Chicago Triune film critic") may have taken the idea too far. This example makes it clear that there's probably not any rules in the form of policy or guidelines on the matter as the solution is context-sensitive. Therefore I am going to say it is not necessary to introduce them with the qualifier, just frequently a good idea. I cannot define what good prose is, but people generally know it when they read it. Try to write good prose and sprinkle in qualifiers as it seems the text demands. As for the best location of a discussion, this too is often unclear. The manual of style talk pages might have been a better spot for this question but since you've started it and it's sort of policy-related (as you've framed it) it seems fine by me here. Jason Quinn (talk) 07:20, 12 May 2016 (UTC)
  • Opinions differ on this. I think most heavy content-writers don't qualify obvious names, only those of people who are not the type of expert on might expect in that context. Where the date the person was writing or speaking is significant I prefer to just give that. But some people think qualification is always expected, which it isn't - see FAC, where a range of styles are accepted. I suppose on some very broad subjects there is no "expected" type of expert, so it is worth always qualifying. Another problem is that "historian Dumas Malone" is grating to many British English readers (it should be " the historian Dumas Malone"), so best avoided per whichever policy that is. Johnbod (talk) 14:19, 12 May 2016 (UTC)
  • Using "the historian Name Here", "the 20th-century biographer Name Here", etc., is definitely helpful to readers. Too many articles name-drop in a manner that inspires tagging with {{Non sequitur}} (the documentation for which I just improved with a mention of the "historian Name Here" vs. "the historian Name Here" distinction). Any time a name is mentioned, its relevance in and connection to the context needs to be clear. WP:GAN and WP:FAC reviewers are not in a position to suggest there's some policy they're enforcing in this regard, but both processes have leeway to collectively make clear, by a valid WP:LOCALCONSENSUS, the criteria they expect, as the reviewers doing the actually pretty grueling work involved in these assessments. Clearing up non sequitur name-dropping seems like a perfectly valid criterion to insist on, just as a matter of encyclopedic, non-telegraphic writing. I would not be averse to seeing something about this added to MOS:BIO (in that it has to do with writing style surrounding name presentation), maybe WP:CITE (in that it's connected to attribution, tenuously), or at least the almost-a-guideline essay WP:Writing better articles (in that it's a how-to-not-make-articles-suck matter). PS: To answer the 1-2-3 questions: 1) No. 2) Not that I know of, and probably not recently. 3) This is a reasonable venue, though WT:MOS or maybe WT:CITE would also work  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  15:50, 17 May 2016 (UTC)
  • You should provide whatever context you believe will be helpful to readers. Frequently, but not always, helping readers will involve a very brief mention of the source's relevance. You do not need to start an RFC or to create any official written rules about this: just go improve some articles.
    In general, you should take statements from Good Article reviewers on a standard of trust, but verify. This is because the sole qualification for being a GA reviewer is figuring out how to log in to an account. Most GA reviewers are good or even excellent, but many are tempted to exceed the actual criteria in some respect (a temptation they resist with varying levels of success), and some are making their very first serious contributions to Wikipedia. WhatamIdoing (talk) 02:01, 22 May 2016 (UTC)

Promote WP:Tagging pages for problems to guideline

Support promotion of essay

  • As someone who does a fair amount of tagging, I've noticed that how to handle those tags from a conduct perspective is a frequent source of tension with fellow editors. It would be extremely helpful to have a guideline on this subject. I have cited this essay a number of times in disputes over tagging practices and I can't remember a single time when the other editor said there was something wrong with it. I do believe that the essay represents at least a rough consensus of the community. I'm not watching this page so please ping me if you want my attention. --Dr. Fleischman (talk) 19:10, 20 May 2016 (UTC)
  • Support -- I can't say I 100% agree with this (I see most drive-by tagging as a problem, see my user page). But I like that this encourages/requires discussion and explanation (by both the tagger and the tag remover). Hobit (talk) 15:51, 21 May 2016 (UTC)

Oppose promotion of essay

  • No. There are enough make-work contributors who like to leave their mark without giving their mission an elevated status. It would be much better to have an essay saying that people should focus on improving an article and engaging with others on the talk page, and promote that to a guideline. Johnuniq (talk) 23:23, 20 May 2016 (UTC)

* Opposed (in current state) I'll start my comments by emphasizing that those who have contributed to the essay have done a nice job and I think it is close to acceptable as a guideline. I also should acknowledge that I am in favor of a different approach to the problem—namely a system in which editors who add tags would volunteer to follow up on the tags, ideally with a notification system built-in. However, I recognize that we don't yet have consensus for that approach and even if we do it may take quite some time before it can be implemented, so an alternative approach such as this may well be a good stopgap and might even coexist for the long-term. I'm struggling to articulate my main concern, but I think my main concern is the essay doesn't acknowledge or articulate the fact that while brand-new editors, even anonymous editors about to make the first edit, are often available to address maintenance tag issues, many of them are not yet sufficiently versed in Wikipedia policies and guidelines to know whether their attempts to address the tags are adequate. I'd like to see a little more discussion explaining that, for example a brand-new editor might well be able to add references to an article that needs references, but might not be the best person to determine whether the added references are now adequate.

In general, this essay suggests that an editor seeing a maintenance template is encouraged to address it and then remove it. I'd prefer a slightly different model. To oversimplify, I'd say that an experienced editor, seeing a maintenance template, is encouraged to address it and remove it. A relatively new editor, seeing a maintenance template, is encouraged to address it, and if they think they have adequately addressed it, they should leave a note on the talk page indicating their belief, and ask for feedback. I don't want to micro manage but I'd be happy with a note that says "I believe I addressed maintenance tags X, and if I don't hear otherwise in three days, I plan to remove it". Some might feel more affirmative response is required but that's a detail for discussion. My main concerns can be illustrated with two examples - 1 a relatively new editor might see a copyright concern and think that changing a few words cures the problem 2 a relatively new editor might see a need for more references, add a couple references to IMDb and think they are done.
While the wording I am hoping for is not quite trivial, I am quite happy with much of what is in the essay and I would be prepared to support conversion to a guideline if there were more guidance for relatively new editors.--S Philbrick(Talk) 01:16, 21 May 2016 (UTC)
I misread - I thought the proposal was to promote Help:Maintenance template removal to a guideline; my comments were directed at that page.--S Philbrick(Talk) 13:09, 21 May 2016 (UTC)

Comments

  • Proposer comment: The essay was proposed for promotion on its talk page in December 2013 (@DrFleischman:), but never followed through on.diff There is a new Help page being curated at Help:Maintenance template removal; however, there is no official guidance concerning placing maintenance templates in the first place. Thus, the Help page (concerning removals) may be premature and lacking foundation. 009o9Disclosure(Talk) 17:38, 19 May 2016 (UTC)
    • Note Please discuss defects or problems you discover with the essay in this forum, since a vote has already been recorded, changing the content is much the same as changing another editor's vote. We are voting on this (revision, April 19, 2016) up or down. Changing the essay can occur after the RfC has closed, so we don't have to keep pinging voters to see if their vote still stands. I've requested page protection for the essay to avoid the problem. 009o9Disclosure(Talk) 21:22, 20 May 2016 (UTC)
No we are not voting on that version. I made one change here at 20:13, 20 May 2016 and a second change here saying the same thing at 00:25, 21 May 2016. There was only one plus !vote before then, and I have notified that person; the changes would not have affected the oppose !vote but I have notified them anyway. You work as a paid editor and it looks very bad for you to be arguing against a change that affects your paid editing. Just knock it off. Jytdog (talk) 01:39, 22 May 2016 (UTC)
  • Comment @Johnuniq and Sphilbrick: The reason I've proposed is to take the (baby) first step and require that tagging editors open a talk page discussion detailing their concerns, or have their tag summarily removed for cause. As it stands now, some editors feel that their header tag should be sustained in perpetuity until the other editor guesses what the problem(s) is. Finding consensus and then adding it to an essay futile, a more authoritative location is needed to discuss implement improvements. 009o9Disclosure(Talk) 04:21, 21 May 2016 (UTC)
  • Comment - I am concerned about the one-size-fits-all approach to the essay. A lot depends on which specific tags we are talking about. Some tags are so self-explanatory that requiring a talk page discussion to explain why they were added is pointless... While others definitely do need explanation. Blueboar (talk) 17:23, 21 May 2016 (UTC)
    @Blueboar: My contention is that an edit summary like, "Added XYZ tag (TW)" is not sufficient in almost every case. The maintenance templates are grouped at WP:TC, so the scope of which template are not subjective (or are self explanatory) can be noted as the guideline matures. My guess is that the shortlist would be groups of templates that are exempt from the talkpage requirement. Nothing is set in stone, but as Wikipedians, we are supposed to include the who, what, where, when and how to the best of our ability. I think this rule should also apply to maintenance templates, especially Neutrality templates. Header tags only provide the "what" the objection is not the "where" it is. 009o9Disclosure(Talk) 18:09, 21 May 2016 (UTC)
    Summary removal of inexplicable tags is already the rule for neutrality-related tags (see the /doc pages for the templates). I also disagree with your claim that "in almost every case" the tag isn't self-explanatory, or at least nearly so. Most source-related templates (e.g., {{fact}}, {{unref}}, {{failed verification}}, {{Please check ISBN}}...) are obvious enough, and some general templates (e.g., {{cleanup-reorganize}}, {{linkfarm}}...) sometimes might benefit from explanation, and sometimes are easy enough to figure out. Those that tend to benefit the most from explanation normally require a |reason= parameter or already have template-specific rules in the documentation about how and when to provide explanations. WhatamIdoing (talk) 04:28, 22 May 2016 (UTC)
  • @WhatamIdoing:The WP:TAGGING essay already differentiates between non-obvious and obvious tags in the first section. Primarily, we are discussing header tags here, I'm a big fan of inline and section tags, they are concise and you simply remove them as you fix the content. In fact, I feel that narrowing the scope with inline and section should be the BRD process for tags. I've never heard of a case where an editor goes to war over a section or inline tag. Header tags on the other hand, are just as often placed as a badge of shame, some editors get a kick out of sustaining them while not disclosing the problem. Generally, this is from a disdain for articles where the subject creates useful products instead of teaching at a college or writing best-sellers. Funny thing about the /doc pages for templates, they can be edited and the edit will not show in the history for the complete template.diff and history 009o9Disclosure(Talk) 08:35, 22 May 2016 (UTC)
  • Johnuniq There already is an essay like the one you describe (WP:RESPTAG). It is quite extensive and probably would not stand a chance of promotion at this time, but it could be cited and content imported into the guideline. Seems like promoting WP:TAGGING is the preliminary step to addressing your concerns. With good consensus here, WP:RESPTAG could be put up for RfC later.009o9Disclosure(Talk)

On the use of template Preloaddraft

My attention was drawn to {{Preloaddraft}} in a thread on WP:VPT. The template turns a conventional redlink into what looks to me like hell on wheels: puts you in draft space, as far as I can see, and inserts ... stuff ... into the new article. See, for instance, the redlinks at Wikipedia:WikiProject Missing encyclopedic articles/Art of the Middle East. Call me old fashioned, but I like it when redlinks yield a blank page in article space. Do we have any policy as to when this template can/should be used. I can just about understand it for an editathon - the documentation speaks of this. But as a general implementation, it seems to make wikipedia editing more scary (albeit in the hope that authors will follow a particular framework for an article) than less scary. --Tagishsimon (talk) 22:39, 19 May 2016 (UTC)

Why don't you just ask Evolution and evolvability about his goals for this new template? You might also want to look at Special:WhatLinksHere/Template:Preloaddraft, to see how it is being used. WhatamIdoing (talk) 04:31, 22 May 2016 (UTC)
Thanks Tagishsimon for your questions about the {{Preloaddraft}} template. My original intention when I wrote it was for use in editathons/wikibombs, when often a lot of first-time users are trying to edit. I'd previously found that novices typically stated feeling intimidated by a blank edit box, and often couldn't work out how to add in reference lists, or infoboxes, or basic sections. In general I've had good feedback from new users. Having a basic structure to start from seems to help give a basic standard of what sort of information is expected or e.g. a scientist or artist. My aim is for it to provide general structure and aid to novice editors, and that more experienced users would just blank the page if they wanted to. I'd be happy for some suggested guideline of when to avoid using it if it turns out to be getting in the way in other circumstances. T.Shafee(Evo﹠Evo)talk 11:16, 22 May 2016 (UTC)

Inconsistency between WP:Article Size and WP:Summary style

WP:Summary style states: "What constitutes 'too long' is largely based on the topic, but generally 30 kilobytes of readable prose is the starting point at which articles may be considered too long. Articles that go above this have a burden of proof that extra text is needed to efficiently cover their topics and that the extra reading time is justified." But WP:Article size states that for articles under 40 kB readable prose size "[l]ength alone does not justify division". To address this issue and a couple suggested improvements to WP:Summary style, I began a discussion at Wikipedia talk:Summary style#Inconsistency with WP:Article Size. Please keep discussion in one place by commenting in that discussion, not here in the village pump. AHeneen (talk) 09:31, 23 May 2016 (UTC)

Separate pages created by new editors from pages created by established user

All pages created by anybody is listed in this page:

https://en.wikipedia.org/wiki/Special:NewPages

The white background also causes eye strain, as people check the name of the page creator

We must separate this Special:NewPages into three parts.

Page A)- This page will only list new articles created by administrators, arbitrators, check users and users with auto patrolled rights.

Page B)- This page will list new articles created by those who don't have extended confirmed rights. All pages created by new users will be listed here.

Page C)- The third page will list articles created by those who have extended confirmed rights but are not auto patrolled, administrator, oversight.

This will make the job of new page patrollers easier as they will have maximum focus on Page B. --223.231.7.91 (talk) 11:40, 18 May 2016 (UTC)

I actually think this is very important — specifically as part of the toolset for users at Wikipedia:New pages patrol.
Also, unfortunately NPP does not consider paid editing, which this type of tool really could take a dent to. Carl Fredik 💌 📧 21:29, 24 May 2016 (UTC)

Joseph T. Fuhrmann

Today I started an article on Joseph T. Fuhrmann, and added four references within a few hours, there is also an entry in the Spanish Wikipedia. Then User:Doc James came up. The article was gone within 6 hours, although it says it needs at least one reliable source which could be the Mary Washington University, is not it? If that is not a reliable source than Wikipedia went crazy in my point of view. It is also says the article will be deleted after a week if there are no improvements.

I never saw the page he is referencing to. A new example that most people on Wikipedia are more interested in deleting than in improving. His bot did not tell me where to look, which is unacceptable, and nobody had a chance to improve it! I am not particularly interested in Fuhrmann, but some other people might be. He is an academic, one cannot change much in a account of universities he visited. Wikipedia became unacademic or should we say stupid?Taksen (talk) 18:19, 27 May 2016 (UTC)

Your page was not deleted for notability reasons or questions about reliability of sources. It was deleted for copyright violation. Did you copy the information about Furhmann directly from the university web site? Wikipedia takes copyright violation very seriously. The information on the university web site is reliable, but it is copyrighted by them. Copyrighted text should be rewritten thoroughly (a so-called close paraphrase is too close.) Robert McClenon (talk) 20:29, 27 May 2016 (UTC)
Details of the copy and paste is here User_talk:Doc_James#Joseph_T._Fuhrmann Doc James (talk · contribs · email) 00:59, 28 May 2016 (UTC)

MFD rename

Just a notice here but I've proposed renaming MFD to Miscellany for discussion rather than deletion. The discussion is here. It was last discussed in February 2011. -- Ricky81682 (talk) 18:57, 28 May 2016 (UTC)

Unauthorized electronic trails by the fa and id Wikipedia

I have recently noticed that some language versions of Wikipedia takes the freedom to create you a userpage or talk page just because you happened visit, not edit that Wikipedia, ONCE. I find that practice offensive and abusive to use the access to the global login system to create completely unnecessary electronic trail. The projects that seem practice this are "id.wikipedia.org" and "fa.wikipedia.org" maybe others. Until they fix this, one effective solution is to cut their access to the cookies that facilitate the global login system so that users explicitly have to permit cookie persistence when visiting those projects. Ie "make global login visible for project [en] [es]" etc. Bytesock (talk) 04:10, 24 May 2016 (UTC)

@Bytesock: this page is for discussing policies for the English Wikipedia, we have no jurisdiction over any other project. You may want to raise your point at meta:Wikimedia_Forum. — xaosflux Talk 04:15, 24 May 2016 (UTC)
@Bytesock: - Also, this is not how it works. When you visit the page while logged in your account is created, they give the message to created accounts, so this is inherent to the way Wikipedia works. Carl Fredik 💌 📧 07:39, 24 May 2016 (UTC)
@Bytesock: I replied to you on meta but I just remind you here in bigger detail that if go to "Preferences" there is a subpage called "notification" and you can deselect the box of cross wiki notifications. Personally I was against the massive introduction of cross-wiki notifications, as happened few weeks ago. I supported the information campaigns for user who wnatd to select the box as a possibility, and I could see the utility of its default introduction on some "meta" platforms such as mediawiki, meta, incubator and maybe later also commons and wikidata, but switching the cross-notification function on for all the platforms and also all the newbies was not well planned. if you remove the cross notification, other wikis won't bother you directly with their welcoming messages.--Alexmar983 (talk) 04:32, 25 May 2016 (UTC)
Bytesock is correct that this is a privacy violation. All the best: Rich Farmbrough, 09:10, 28 May 2016 (UTC).
Agreed. If this is what's happening, then it's a definite privacy problem. Read-only activity should not leave a footprint. -- The Anome (talk) 09:15, 28 May 2016 (UTC)
The WMF has always (well, since SUL went live) created a public log of every WMF wiki you've visited. Here's a list of every wiki you've ever visited together with dates, for instance. Preventing this happening wouldn't be trivial, as it would mean disabling WP:SUL which would be a massive technical and cultural change. ‑ Iridescent 09:24, 28 May 2016 (UTC)
It's still not our bag, since we do not have bots going around welcoming new visitors (they have been proposed, but always rejected). If there are legal or privacy concerns with the activities of other language Wikipedias, then meta: is the place to bring those up. --Redrose64 (talk) 10:17, 28 May 2016 (UTC)
The Special%3ACentralAuth is even worse. It's simple not the business of any other person which wikis anyone visits. With the exception of aggregated number of visits per article. WMF or whoever is responsible needs to seriously rethink this or technical countermeasures with collateral may show up. It's like they are tone deaf to what has been debated very publicly the last three years. Bytesock (talk) 19:13, 28 May 2016 (UTC)
Bytesock, for at least the fourth time, English Wikipedia has no control over other language Wikipedias, nor does it have any control over the workings of SUL. There is absolutely no point in complaining about this here. (As an aside, I fail to see how CentralAuth is a privacy violation in any meaningful sense. Since you're using me as an example, I can imagine no circumstances in which anyone would ever care that I apparently visited Udmurt Wikipedia on 2 May 2010. If you're that concerned, just go to List of Wikipedias and open each link, which will effectively scramble your history.) ‑ Iridescent 15:20, 29 May 2016 (UTC)

Ethnicity in infoboxes again (RfC notice)

FYI
 – Pointer to relevant discussion elsewhere.

Please participate in the discussion at Wikipedia talk:Manual of Style/Images#Proposed repeal of WP:NOETHNICGALLERIES. It is a proposal to vacate the previous consensus reached in the February 2016 RfC that resulted in the creation of the MOS:NOETHNICGALLERIES provision at MOS:IMAGES, and also relates thematically to Wikipedia:Village pump (policy)/Archive 127#RfC: Ethnicity in infoboxes (all of these discussions are ultimately about using infoboxes to identify individuals as members of particular ethnicities).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:13, 29 May 2016 (UTC)

"Customized citation" and WP:OWN

I asked a question at the Help Desk and was directed here instead. Here was my question:

I saw something on a few talk pages that had me raise an eyebrow. On Help talk:IPA for Tunisian Arabic, Talk:Tunisian Arabic and others, someone added a box with a "cutomized citation" that mentions four of the pages' editors with their contact info and some keywords and acknowledgement. The boxes make it look like these pages are scientific articles written by these four contributors. I'm not sure whether it's a violation of WP:OWN, but it definitely seems a bit strange to me. Does WP:OWN allow a few contributors to single themselves out in a customized citation displayed on talk pages? Abjiklɐm (tɐlk) 23:38, 30 May 2016 (UTC)

For purposes of a project-level page dealing with translation, this seems like simply identifying real-world experts that have helped to set up the page, and far from OWNership, or least the type we'd normally balk at in mainspace. We want expert-type help like this. --MASEM (t) 23:59, 30 May 2016 (UTC)
Agree... I don't think it's OWN. However, at a quick glance, it might be a WP:NOR issue (editors citing themselves for their conclusion as to how the language is pronounced). Not positive on that. Blueboar (talk) 00:14, 31 May 2016 (UTC)
Also looks like they're self-published, especially the citations used for Tunisian Arabic#Scripts where these contributors cite themselves for all kinds of proposed spelling standardizations. Clearly a lot of work has gone into all this, all in good faith too. I'm just not sure it's all admissible. Abjiklɐm (tɐlk) 00:39, 31 May 2016 (UTC)

RfC: Proposed draftspace deletion

Consensus seems to be that this proposal might be adopted, depending on future discussion of the specifics, as editors have various concerns about different aspects of it. The predominance of reasoned !votes is on the of adopting the proposal (although perhaps with various modifications). There are legitimate arguments on both sides, but the predominance of policy-founded argument also seems to be on that.

The main reasons for doing this seem to be: (1a) the current situation makes it difficult to find pages in draftspace; (1b) WP:NOTWEBHOST; (1c) if not adopted, editors who want to clear out draftspace may end up flooding WP:MfD with entries and creating a backlog; (1d) draftspace may be full of copyvios, attack pages etc. which will get buried if draftspace is not cleared out efficiently. The main objections seem to be: (2a) that there is no reason to delete these drafts, except in particular cases where they are actively harmful (and perhaps WP:G13, which operates on a similar principle, is unnecessary); (2b) it might put off contributors if we start deleting their drafts; (2c) there will be insufficient scrutiny on these deletions.

Further discussion now at WP:Village pump (policy)#Wikipedia:Proposed draftspace deletion.

(non-admin closure)

Closed initially by Dionysodorus (talk) 22:18, 8 July 2016 (UTC), and modified per this discussion by Dionysodorus (talk) 01:05, 13 July 2016 (UTC).

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

Non-AFC drafts in draftspace have no G13 method for automatic deletion or for any review at all. As such, there are hundreds of stale drafts that haven't been edited in a long time. Attempts to add G13 or other criteria have been repeatedly and expressly rejected so instead these pages take up a lot of time at WP:MFD where deletion is somewhat routine. I'd like to propose that we allow for a new draft proposed deletion system with the following rules:

  1. Draftspace drafts that are not tagged with AFC that haven't been edited in six months can be considered.
  2. If the deletion is proposed, it would go into a dated category similar to Category:Proposed deletion for at least one month at which time any one can remove the proposal for any reason whatsoever. This is similar to the 5 month notification of Category:AfC G13 eligible soon submissions with a month before G13.
  3. After a month with no deletion, an admin can then decide if it's worth deleting.

I've added header for support as is and a separate support in case people support the general concept but disagree on the six month/one prod timeline. -- Ricky81682 (talk) 21:34, 20 May 2016 (UTC)

Support as is (Proposed draftspace deletion)

  • support i don't see any harm arising from this very gentle proposal, and having this path available will hopefully reduce the disruption that we have had from people MacGyvering ways to delete stale drafts outside the MfD pathway. I don't understand why having a more efficient way to clear very stale drafts is very important to some folks, but it is. So let's reasonably accommodate them. Jytdog (talk) 01:33, 23 May 2016 (UTC)

Support generally (Proposed draftspace deletion)

  • I agree that drafts located in draftspace should have a reasonable expiration date... After which they are removed from draft space for "lack of interest". I would peg it at one year with no substantive edit. However, it can't be a simple "keep" or "delete" determination... Because there is also the option to "userfy" (moving it out of Draftspace and into Userspace... if there is an editor willing to adopt it). Blueboar (talk) 21:56, 20 May 2016 (UTC)
  • After the proposed draft is removed, I don't think there's any rules about what to do. It can go to userspace or mainspace or wherever else people want. This is just more of a single veto to deletion than MFD's consensus requirement. -- Ricky81682 (talk) 22:03, 20 May 2016 (UTC)
But the determination about what to do with the draft has to be made before it is removed... Thus the need to outline the options. Blueboar (talk) 22:39, 20 May 2016 (UTC)
I don't understand. There is no determination. Someone could remove it and just keep it there. The creator could be active but the draft is not. This is not like userspace where we check both the page and the editor so I don't see why anything more has to be done. -- Ricky81682 (talk) 22:42, 20 May 2016 (UTC)
Maybe I don't understand what you are proposing... How can you remove something from Draftspace and yet still keep it there? I thought the proposal was to institute some form of quick review of unfinished pages that have been sitting in Draftspace with no one working on them. If so... Then we need at least three options for the reviewer to choose from: 1) Delete it (due to the fact that since no one has worked on it, there is obviously a "lack of interest in having an article on the topic", 2) Keep in Draftspace for further work by the community, or 3) move to Userspace for an individual to work on personally. These are mutually exclusive choices. Blueboar (talk) 00:03, 21 May 2016 (UTC)
No, it's like proposed deletion: a quick review of pages that people think will never be something usable and that no one is working on. The lack of finishing is not a reason to delete something to me. I have a half dozen drafts I've started and haven't finished. I still work on them but if someone else took them to MFD, I'd argue to keep them and if proposed for deletion, I'd remove it. However, other people leave content there and that's it. Why should be done? -- Ricky81682 (talk) 04:14, 23 May 2016 (UTC)

Support: I believe WP:WEBHOST does apply here. Also, could someone provide diffs for an editor being chased away for their stale draft being deleted, I'm sceptical. I have, on the other hand, seen some editors jump back into the game and resume editing a draft that was stale because they did care about it. The point here is that if it's truly stale, they obviously DON'T care about it. I scrolled down the MusikBot stale draft report and clicked on three drafts completely at random. I found: Draft:Rusty Anderson Afternoon EP II, Draft:Ishan Sinha, and Draft:Hatim. This is at least the second time I have looked at a random sampling of these stale drafts and come up with NOTHING worth keeping simply for the sake of keeping. Those three articles don't even have a proper paragraph between them, much less potential for a mainspace article. Three more at random: Draft:Karl Gebhardt, Draft:Prime Lending, and Draft:Davula Estates Limited. Same problem. Authors aren't going to driven away by us deleting a BLANK draft, or one with only ONE sentence. This is cruft that we do not need cluttering categories, backlogs, search results, etc. My only proposed change to the proposal is to extend from 6 months to 1 year - the reason for this is that looking at the 6 Drafts and the contributors, it appears there's a small chance that the authors might want to come back to them (especially if they thought it might be deleted). Chrisw80 (talk) 19:37, 21 May 2016 (UTC)

The entire point of Draftspace is for the broader community to work on the draft. If no one in the broader community is interested in working on it, we should move it out of Draftspace. This does not mean, however, we have to delete the draft. It should be moved into the original author's Userspace, if there is even a remote chance of a potential that it might someday make a valid article. Blueboar (talk) 20:37, 21 May 2016 (UTC)
We've had policies for years that if a draft isn't going anywhere, it can go to MFD and be discussed there. The consensus has been for deletion overwhelmingly. The point is userification is beyond a minute occurrence. If you want to oppose all deletions, then go to MFD and argue that every draft should be userified back to the user but I'm certain you won't get a lot of support for that. That's how consensus works: you have to actually convince people of your proposal not just state it and then argue it at the policy stages to create procedural hurdles for everyone else. It's not like the option is "this proposal or these pages don't get deleted." These pages are already being deleted. I'm just trying to find a way to avoid either flooding AFC with 5000 more pages as people suggest or MFD with more pages. -- Ricky81682 (talk) 20:52, 21 May 2016 (UTC)
Blueboar, I'm not sure I understand you here. That a year old draft with no content should be saved? That a two year old draft about someone who will obviously NEVER meet WP:GNG should be saved? What is a "remote chance"? As Ricky81682 points out, the matter of the deletion of abandoned and poor-quality drafts has already long since been settled. The matter is whether the author ends up at the dumping ground that is MfD trying to salvage their draft (dealing with confusing terminology, contentious arguments, etc.), or they end up with a PROD style warning that gives them an easy and quick chance to continue working on their draft without all that. This idea seems perfect to me to keep potential contributors, while still dealing with the stale draft problem. Chrisw80 (talk) 21:22, 21 May 2016 (UTC)
I agree that most of the drafts in the backlog are likely to be deleted... But I doubt this will be the case with every one of them. With thousands in the list, there are bound to be at least a few that are worth keeping (perhaps in Userspace). I agree that we need a quick and efficient review process... I am just not sure a G13 like process is the right one. Blueboar (talk) 22:27, 21 May 2016 (UTC)
Hi Blueboar, I think I see what you're getting at now.. I agree, there is likely some of the drafts in the backlog have merit and shouldn't be deleted. The process Ricky81682 is describing is more similar to the PROD process, rather than the CSD G13 process. He is simply offering G13 as similar to the stale aspect of the drafts, not the speedy deletion part of it. He's talking about a full month where the "DraftPROD" tag would be present on the page and the author (or anyone else) can remove the tag at any time during that period, no big deal, no questions asked. It actually seems quite reasonable to me. Chrisw80 (talk) 23:47, 21 May 2016 (UTC)
Honestly, it's more akin to Category:AfC G13 eligible soon submissions to me. You have a month to review them (although I imagine them by individual date is better). Create a rescue task force and split it by letter or whatever to double/triple/quadruple review them, I don't care. It's not like I'm going to mass nominate 5000 pages in one day. -- Ricky81682 (talk) 00:38, 22 May 2016 (UTC)

Support Any draft in draftspace should be subject to WP:NOTWEBHOST. They should have an expiration date, like WP:AFC drafts. Tom29739 [talk] 21:25, 21 May 2016 (UTC)

  • Support by all means, certainly something I've considered before. SwisterTwister talk 22:50, 21 May 2016 (UTC)
  • Support – We are not a web host. There is no reason to keep stuff (potential junk) around like this for ages. An expiration date is required. If an editor really does come back after 20 years to work on some draft, he can always request a copy of it via WP:REFUND. Deletion is not permanent, after all. I think the opposers haven't realised this. RGloucester — ☎ 23:00, 21 May 2016 (UTC)
  • Support, hosting large amounts of poorly-reviewed content eternally is a problem in itself. I see editors concerned that there might be a hidden gem in these abandoned drafts. I don't see them volunteering to patrol the huge ever-growing backlog for copyright violations, attack pages and the like. Those could of course already be speedied, but discovering copyvios takes a lot of effort, effort nobody will want to spend on abandoned drafts. Getting rid of all that have been inactive for an extended amount of time will at least minimize the problem. Huon (talk) 12:07, 22 May 2016 (UTC)
  • Support - I do a bit of work on G13, and when I began it was because there was a backlog of several thousand, and another editor asked for help in reducing that backlog. It's tedious, and time consuming, and I do it as part of my gnomish morning activity. Probably 50% of the drafts can be nominated for deletion in under 20 seconds (blank, foreign language, "hi", obvious personal bios of non-notable teenagers, etc). Another small percentage are the other end of the spectrum, where, within 20 seconds you can ascertain the subject meets the notability criteria, and you postpone the G13 (it's a town in India, which just doesn't have any citations, or you click on the Scholar search and see the professor has several articles cited thousands of times, etc). Another 25% or so are obviously simply advertisements. Another 15% or so take a minute or so to check the references or the search engines, after which you can make a determination of whether or not to G13. After which an admin then makes one last check. Not sure what the issue is with applying this same procedure to these other types of drafts. The article's creator would receive a notice a month out, and they have that month to have input on whether or not they still intend to work on the article. Then they can still have it reinstated if they were spending a couple of months in the outback and missed the notice. Onel5969 TT me 22:21, 22 May 2016 (UTC)
  • Support. I don't think this is the ideal solution (I'd prefer new speedy deletion criteria for the worst, and blanking or redirection for the rest), but this is workable, and the current situation - massive overload and continuous bickering at WP:MFD - is far worse. —Cryptic 04:16, 23 May 2016 (UTC)
  • Support with some restrictions. No bots or fully automated scripts should tag articles with this CSD, as per the recent RfC that closed with clear consensus against a hard expiration time. Further, these deletions should not be routine in the sense that admins accept every one based on date alone. The admin should review the draft and any sources on the draft to determine if it's made a credible claim of possible significance now or in the future and could feasibly be used as the starting point for an article if the subject became notable. We don't need to rigorously define "credible claim of possible significance now or in the future", but my point is that the bar should be even lower than "credible claim of significance". If you can imagine a future world where the subject could make a claim of significance and the draft could be a useful start, the draft shouldn't be speedily deleted. That doesn't mean it shouldn't be deleted; MfD could be appropriate. ~ RobTalk 04:38, 30 May 2016 (UTC)

Oppose (Proposed draftspace deletion)

  • Oppose - I would like to see some material justification for deleting these things before we create a new process and then staff that process. What's the harm in allowing things to accumulate in draft space? Seems like there could even be some good in it. ~Kvng (talk) 22:41, 20 May 2016 (UTC)
I think we may have some confusion in terminology... pages that falls afoul of WP:WEBHOST are unlikely to actually be located in Draftspace to begin with (because the are not drafts). Blueboar (talk) 23:23, 20 May 2016 (UTC)
I don't know why we have G13? Do you? Still looking for a reason these things need to be deleted. WP:WEBHOST doesn't seem to be it. ~Kvng (talk) 14:03, 21 May 2016 (UTC)
We have a G13 so we don't have a million pages of junk to go through at AFC. There's probably a thousand pages a day that are deleted. Do you actually think the best way for us to actually work on creating a feasible encyclopedia is to keep what would possibly be a quarter million pages a year of old pages that no one is working on? We'd be approaching a million old pages from draftspace/wikipedia talkspace since the start if we didn't have it. Do you think AFC could function? Do you actually think anyone would want to review a single page if they had to go through thousands of pages of junk from years and years ago? -- Ricky81682 (talk) 20:58, 21 May 2016 (UTC)
You certainly can't keep all your physical junk forever but I guess I'm thinking outside the box here and asking what's the problem with keeping all drafts forever? It just sits there. It doesn't hurt anyone. It is cordoned off from mainspace that we'd like to keep tidy. If you think about it, the data storage requirements for text are small; With a million 1000 byte articles a year, it will take 1000 years to fill a hard disk. No one at AfC or anywhere else has to sort through any of this stuff. Editors can pull out bits using search. Authors may never return to finish an aborted draft but if they do, it will be waiting for them where they left it - friendly. What's not to like? ~Kvng (talk) 23:58, 21 May 2016 (UTC)
You want to propose, go right ahead. Most people find the goal of creating an encyclopedia is more likely to occur if we didn't have tens of thousands of extra pages of junk lying around. Your arguments are the same things I had a decade ago when we raised our standards for GNG: we should be more concerned about driving away potential "contributors" than about the people who are here and who do work here in terms of the clean-up and other projects. Either way, what does that have to do with this proposal? These pages are subject to deletion at MFD anyways. This is like opposing WP:PROD because you want to argue about some subset of WP:GNG or other notability guidelines. -- Ricky81682 (talk) 00:11, 22 May 2016 (UTC)
  • Oppose. To date, the instigators of the recent 2015-16 drive to clean up all old drafts, along with other pages swept up in the drive, have failed to present, at MfD or elsewhere, a coherent explanation of how they discriminate useful versus useless material. This proposal is just a proposal for them to continue mass deletion but without review. Prod was intended to depend mostly on page watchers noticing, and draftspace pages don't have watchers. If Ricky really wants to help the project by processing old drafts, I suggest that he classify, or categorize them, preferably by taggings, with one category containing all the pages he would see deleted. Then, if and when he is confident that the category is accurate, propose deletion of the contents.
Personally, I think that the effort is a net negative. DraftSpace was supposed to help the project, not create more work than it is worth. There is actually no reason to delete, or even process old drafts that don't violate anything at WP:NOT. --SmokeyJoe (talk) 00:43, 21 May 2016 (UTC)
You always suggest other nonsensical sorting scheme or "put them to AFC" or other projects that everyone else opposes, all of which in the end is the same solution: demand that other people do more nonsense you create while you sit back and just oppose any review of these drafts. As of this date, there are over 7000 old drafts that have not been edited in six months or more. Of those, the people who actually want to review and work on them would like to simply delete the ones that aren't going anywhere. Are you actually working on these? Have you moved any to mainspace? No one is out there in some lunatic craze to just wildly delete every page here. If you want, remove every single proposed deletion and just yell and scream some more that AFC or me or someone else should jump through the 50th hoop you've made up to save one sentence someone created in 2013 and never bothered with again. I set up the entire Abandoned Drafts project the way you suggested and then you ignored it. Otherwise, we continue on with these at MFD where you again oppose deleting these arguing that "G13 should handle these" and then oppose G13 handling then and then watch as AFC explodes that they don't want them and so on and so on. Is literally the only thing you do all day make up new kinds of bureaucracy so you can sit around and proclaim victory because something isn't done? I mean, if we go with your new "tag them with AFC" (after months of opposing the same thing), then in six months there will be 7000 new items in Category:G13 eligible AfC submissions. Ignoring this backlog so it's miserable that no one wants to touch is surely your end goal here. -- Ricky81682 (talk) 01:51, 21 May 2016 (UTC)
Categorise them by all means, but at this time I don't support an unreviewed deletion process for drafts. --SmokeyJoe (talk) 08:27, 21 May 2016 (UTC)
  • Oppose. Support SmokeyJoe's proposal that all these pages be organized and categorized instead. 166.176.56.99 (talk) 03:05, 21 May 2016 (UTC) WP:BANNED — JJMC89 (T·C) 07:48, 21 May 2016 (UTC)
  • No. 1) There's no reason to do this. 2) There's at least one good reason to not do this, in that it chases away contributors. I suspect that there is a perfectionist personality type who looks at imperfect things and wants to eliminate as many of them as possible to improve things. I respectfully suggest that Wikipedia is not the place where such intentions and tendencies will bring on the most satisfaction. Jclemens (talk) 07:38, 21 May 2016 (UTC)
  • Oppose: per the previous proposals. The statistic that "there are over 7000 old drafts that have not been edited in six months" only shows there is no effective reminder system which pings the contributors with a tickler about drafts. Just because someone creates a report with a number does not mean that number has any actionable meaning or that the number should even be thought of as a backlog when, in my opinion, it seems to be a to-do list. The difference for me is that backlog implies management of contributor efficiency. Less oligarchy is better. –BoBoMisiu (talk) 11:52, 21 May 2016 (UTC)
  • Can anyone articulate a reason why deleting these is useful? The proposal assumes that it is, but I don't see a reason given. Oppose for now. It's clear deleting people's work is likely to piss them off and drive them away from Wikipedia. Probably very few return to a draft years later, but even if one would have, deleting the drafts is hurtful. What is the help here? Hobit (talk) 15:47, 21 May 2016 (UTC) Following up to my !vote, I've not been convinced that there is any meaningful benefit to doing this and I'm concerned we will delete useful things and/or piss off contributors or potential contributors. My oppose stands. Hobit (talk) 03:57, 24 May 2016 (UTC)
    • You're arguing about the deletion policy in general. These pages are already being discussed at MFD (like at AFD). These drafts are regularly discussed and deleted on an ongoing basis. This is a suggestion for a proposed deletion system similar to WP:PROD. If you truly oppose any deletion of this sort, you'd be better off supporting this proposal and just removing all notices in mass rather than having to go to MFD and argue at every single discussion. Else, your opposition is entirely irrelevant to the issue of what method by which we can delete these pages since the consensus is that these pages are subject to deletion and are/have been deleted as such for years. -- Ricky81682 (talk) 20:45, 21 May 2016 (UTC)
We're not arguing about about deletion policy in general, we're talking about deletion policy for draft space. It make sense to delete crap from main space as that material is available through a web search and would reflect badly on Wikipedia if people were reading it thinking it is something produced by the project. The situation is different with draft space. It is not externally indexed and so it can be considered semi-public unpublished work. This is really not much different than past revisions of articles in mainspace which we only delete based on copy violations and similar touchy issues.— Preceding unsigned comment added by Ricky81682 (talk • contribs)
Please take a step back from your assumption that keeping everything is not sustainable (see my comments on storage above) and answer the question we've posed, what is gained by deleting abandoned drafts? ~Kvng (talk) 00:13, 22 May 2016 (UTC)
It isn't sustainable, though. Categories will grow, indexes will grow, disk usage overall will grow, etc. The problem isn't necessarily the technological limitations, though, it's how manageable the dataset is for humans to deal with. There's no reason to keep one line drafts that have no potential whatsoever, empty drafts, etc. The proposal is a reasonable way to try and keep a handle on this. Are you really proposing that we delete NOTHING in draftspace? Every random promo utterance by a COI editor, every half-hearted attempt at a personal profile, every mistakenly create draft by an inexperienced editor? We don't need to hoard random, nonsensical stuff. A PROD process makes sense to keep useful drafts with potential easily accessible and easily findable - people don't want to wade through tons of junk to find that one gem. Chrisw80 (talk) 00:28, 22 May 2016 (UTC)
Also, if they return, we'll just restore it. No one is on a wild mission to destroy good work but at the same time the people who actually go through the slog shouldn't have to suffer through millions of pieces of junk just for some philosophical debate about what "drives people away". We've done this for years and there's no evidence that these deletions are in fact driving any more people away that not doing them so it's odd that now that's a reason to not do it. -- Ricky81682 (talk) 00:34, 22 May 2016 (UTC)
I have done the math argued that keeping all drafts indefinitely is sustainable. You have simply stated that it is unsustainable. Please explain why you think it is unsustainable.
I agree that it is about making the dataset manageable for humans. My argument is that nothing is gained by time spent by humans reviewing these drafts. If there's a blanket technical or policy reason for deleting them, just delete them. If not, what is the harm in keeping all of them. How is going through this stuff now when you don't have a good understanding of how it may or may not be useful in the future better than going through it in the future when you know what you're looking for? ~Kvng (talk) 00:55, 22 May 2016 (UTC)
That's nice and all but what does this have to do with this proposal? If you want to propose a bot to review all these, go ahead. If you want to propose that people ignore it, go ahead but if you aren't interested in this, why in the world does it matter that other people volunteer to do this? -- Ricky81682 (talk) 01:10, 22 May 2016 (UTC)
Well, it's unfortunately not human manageable with 1 draft in 600 having any potential (mostly random stat, don't take at face value). Additionally, I have offered technical reasons for deleting them (growing categories, database indexes, disk usage, etc.). The direct harm is that the good stuff can't be found amongst the crap if we don't clean it up. We have people that WANT to clean it up, we are driving THEM away by refusing to allow crap drafts with no potential to be deleted. We shouldn't keep some poorly-written one-line or completely blank draft on the WP:CRYSTALBALL chance because it might happen to turn notable 10 years from now (we KNOW it's not suitable now). It's actually possible to draw in new contributors by offering them drafts that might have potential so they don't have to start from scratch - but we can't do that when draftspace is a complete disaster as it is now. Chrisw80 (talk) 01:18, 22 May 2016 (UTC)
It seems like technical reasons in favor of deletions would have to be pretty compelling. Otherwise it would seem to be a good bargain to burn some system resources to avoid expending the human resources required to sift through all this stuff.
I appreciate that there are Wikipedians who want to delete stuff and if we make that harder, maybe they'll be driven away or maybe they'll start using their time on activities that more directly affect the quality of the encyclopedia. I guess we must individually decide whether this is a potential problem. ~Kvng (talk) 04:11, 22 May 2016 (UTC)
Chrisw80, you don't need to worry about WP:PERFORMANCE. There's a whole department of really awesome tech folks that deals with this stuff. In the unlikely event that the draftspace gets to big or too complicated for them, then they'll let us know. In the meantime, if you want a quick point for comparison, keep in mind that you're talking about a few thousand tiny text files, and they're supporting Commons:, whose database includes more than 31 million not-so-tiny media files and nearly a quarter-billion revisions. WhatamIdoing (talk) 04:42, 22 May 2016 (UTC)
Hello there, WhatamIdoing. As I mentioned, the technological piece is only a part of the issue here. I'm well aware of how competent the WMF ops folk are. It doesn't mean we need to make their jobs any harder. Anyway, as I have pointed out it's not entirely about the technological piece, it's about the whole concept of collecting cruft in general. This whole idea is not wise, nor sustainable. However, I begin to repeat myself. I will not, nor will I ever, support keeping mountains of entirely useless drafts on Wikipedia. I do not believe that it will ever serve us to do so. Doing something simply "because we can", is foolish and short-sighted, IMHO. Chrisw80 (talk) 05:10, 22 May 2016 (UTC)
Yes, you are repeating yourself a bit. You keep saying that leaving these drafts around is not sustainable. Not sustainable implies that we're going to run out of something or be buried by something. You haven't said specifically what the sustainability problem is. We're not going to run out of disk space or take forever to complete a search or break system indexing by having too many things in a category. We're not going to put any burden on editors or administrators because leaving all the stuff there means that no one needs to sift through it or perform any delete operations. I think it is easier to argue that continuing to examine and selectively delete "expired" material is not sustainable; We're getting a constant flow of it coming in and have a declining number of qualified editors and administrators working on the project. ~Kvng (talk) 05:55, 22 May 2016 (UTC)
Regarding sustainability, I stated specifically: "A PROD process makes sense to keep useful drafts with potential easily accessible and easily findable - people don't want to wade through tons of junk to find that one gem." Keeping things clean so useful material is easy to find. We ARE geting buried with useless drafts. I wasted 30 minutes opening stale drafts at random for something I thought would be something I could pick up and roll with to prove myself wrong here. I found nothing worth keeping. Almost all were one-liners for completely non-notable persons or organizations, blank, or only had basic section headers and no content. There were a couple where the subject had potential, but the content was so poorly written that it would have needed a complete rewrite anyway. Perhaps there are others that I'm missing? In every borderline case I saw, it would be better simply to have a line item over at WP:RA. There are people that WANT to do this, I say let them do it, and it's possible we can convince them to do other things on Wiki as well in the process, rather than drive them away with refusal to let ANYTHING be deleted. Chrisw80 (talk) 06:12, 22 May 2016 (UTC)
In this same paragraph your arguing both that people do and people don't want to sort through all of this stuff. If you're talking about the same people, you're not making sense. If you're talking about different people that do and other people that don't, I would be surprised if these two groups would be able to agree on a criteria for determining what's a gem. ~Kvng (talk) 17:56, 22 May 2016 (UTC)
Hello Kvng, they aren't necessarily the same group of people, I wasn't suggesting they were - Wikipedia is a large project and there is room for all kinds of people who want to focus on different aspects of the project. And perhaps they wouldn't be able to agree on specific criteria, that's why a PROD process is a good idea. If anyone thinks the article is worth salvaging, they can remove the PROD, it's that simple. Anyone's definition of a "gem" will do, in this process. You are aware that with a PROD, anyone can remove the tag with no explanation required? I still can't figure out if you're really suggesting that if someone wants to have a blank or nearly blank draft deleted that they either have to ignore it and let it clutter the categories and backlog, or have to send it to MfD for it to be debated ad nauseam.. We should courtesy blank a blank draft instead of deleting it? Deleting a blank draft is going to drive away potential contributors? Chrisw80 (talk) 18:25, 22 May 2016 (UTC)
The problem with prod for this purpose is that a normal editor has no way of knowing what has been deleted and so it is impossible to know what to ask for at WP:REFUND when you're looking for a gem. Novice editors may find WP:REFUND to be too high of a barrier to continue their postponed work. Novice editors are sometimes reluctant to or otherwise unable or unwilling to deprod (they continue to improve their draft without deprodding). ~Kvng (talk) 19:23, 22 May 2016 (UTC)
  • Oppose — This is only a hypothetical problem. As long as drafts are not spam or things that do not belong on Wikipedia anyway, such as paid editing drafts there is no reason to actually delete them. If even a single draft can be salvaged from this space it is worth letting thousands accumulate — they aren't doing anyone any harm and barely impact the servers. Carl Fredik 💌 📧 21:45, 22 May 2016 (UTC)
    • It's not about the servers, it's about the people. Do you think people are going to be able to functionally go through and work in draftspace if you have to click through hundreds of pages like Draft:Kristoffer Hellkvist - Världens sämsta källkritker that no one finds useful but won't be deleted? Even then, how does that affect this proposal? The deletions occur with or without this proposal and instead of a month to work on the draft, the editor is told there's a week-long procedural discussion at MFD. -- Ricky81682 (talk) 22:27, 22 May 2016 (UTC)
Why does anyone need to go through them? We have other methods of deleting and detecting copyvio, slander, and other material that should not be on Wikipedia. I can not fathom a scenario where you will come across that article without looking for info on Kristoffer Hellkvist, where it might actually be useful. Also, that is a BLP issue and can be deleted on those grounds, this proposal makes no sense because it isn't a problem. Carl Fredik 💌 📧 22:41, 22 May 2016 (UTC)
For CSD violations? For BLP nightmares? For forks of mainspace? For content worth merging and using? Why does anyone review work at AFC? People check on old drafts that haven't been touched to get rid of the worst ones, and to figure out what's worth improving to get them to mainspace. Again, if you don't want to do that kind of stuff, fine but since they are already going to be reviewed and are subject to deletion on these exact same grounds, I'm trying to propose a more streamlined approach. It doesn't take a ton of time to see junk and that's why AFC has G13 to simplify it. This is better than a separate MFD for each page. -- Ricky81682 (talk) 04:08, 23 May 2016 (UTC)
But why do existing drafts that do not violate policy have to be deleted? It seems to me that all you need to do is patrol recent edits in draft-space, and ignore old drafts. Carl Fredik 💌 📧 14:22, 23 May 2016 (UTC)
  • Oppose as very few, and likely 0 people will be keeping an eye on the proposals to delete. So it would be akin to a delayed speedy delete. Graeme Bartlett (talk) 00:21, 24 May 2016 (UTC)
    @Graeme Bartlett: I would imagine that the number of people "keeping an eye on the proposals to delete" will be the same for a page in Draft space as for a page in article space. If your worry is that nobody will do anything before the time limit is reached, then you should have a similar worry with articles that have been WP:PRODded. The pages will be in Category:All articles proposed for deletion, or a similar category; and when the time limit does get reached, the draft will be automatically categorised into Category:Expired proposed deletions, or similar. --Redrose64 (talk) 14:39, 24 May 2016 (UTC)
  • Oppose - I've yet to see any good justification as to why we should delete any pages that just happen to be old, but are otherwise not harmful. Absent that justification, there can be no rationale for expanding G13's scope. Ivanvector 🍁 (talk) 21:32, 26 May 2016 (UTC)
    • Keeping around useless pages makes it harder to find actively harmful pages in the draftspace. A proliferation of pages is difficult to maintain. It takes editor time and resources. ~ RobTalk 00:25, 31 May 2016 (UTC)

Discussion (Proposed draftspace deletion)

  • I would suggest adding {{subst:submit}} to such pages instead. This will ensure that they are properly reviewed before being deleted. If WP:PROD is used, chances are that no one reads the page before it is deleted, and then we might lose useful stuff. --Stefan2 (talk) 21:41, 20 May 2016 (UTC)
  • To respond to a number of people, if your opposition is against deleting these old draftpsace pages in general, that's been resolved for years and you've basically lost that battle. These pages are currently taken to MFD and deleted on a regular basis. If this is rejected, then MFD remains an option for these. As opposed to an editor getting a notice that they have a week to go to an MFD discussion and gain a consensus to keep their page, they will be told they have a month to just go on the page and remove the notice. I think that's better. If you truly object to the deletion of these drafts at all, WP:MFD is available and this proposal actually makes it easier for you to just mass remove every proposed deletion than to go to MFD and argue against all deletion of these pages. -- Ricky81682 (talk) 20:41, 21 May 2016 (UTC)
@Ricky81682: from what I read, MFD is like a material review board which I understand well. Your proposal is about how to disposition draft pages that are identified by bots using the criteria of inactivity. You wrote above that "After the proposed draft is removed, I don't think there's any rules about what to do. It can go to userspace or mainspace or wherever else people want. This is just more of a single veto to deletion than MFD's consensus requirement." I am assuming removed in your sentence means queued for disposition. MFD deletes by consensus but your proposal would delete by individual admin as the last step in this new queue for disposition. What regulates that last step, i.e. the individual admin's decision to delete? Or maybe, if I reword that, how does she decide if the draft page is defective enough to scrap other than because it is inactive? –BoBoMisiu (talk) 23:14, 21 May 2016 (UTC)
I'm imagine this like WP:PROD. If a draft hasn't been edited in six months/whatever time period and someone thinks it's not worth keeping, then they can propose it for deletion. From there, an admin can decide whether or not to delete. On what basis, I'd argue if you think there's no plausible chance that it could become a legitimate article but there's been no consensus on a standard for when a draft should be kept (else, we'd have some basis at AFD for when to draftify/userify pages). Discussing that is impossible if people argue against deleting any drafts while at the same time there are votes (often the same people) for deleting certain drafts and a refusal to explain their criteria. We can define that separately now or later if that's a concern. There are no bots I'm suggesting here; the prod template could do the six month check within it as the G13 template does but it's still the admin's responsibility to make sure the rules are followed. We could add that WP:REFUND still applies or any admin can undelete it if requested but that's pretty much standard anyways so I don't see the need for it to be explicitly stated. Again, if people really do believe that drafts shouldn't be deleted, they are free to browse through these as well and see if there's anything worth keeping. I've been active in moving pages to mainspace for a while now, it's just not feasible to do that if we can't do some triage and rid of the stuff that no one sees going anywhere under the hope that editors will return after 2/3/4/5 years and do it for us. -- Ricky81682 (talk) 00:00, 22 May 2016 (UTC)
Triage is done by categorisation, aka labelling or minor physical separation. It is not done by on the spot euthanasia. --SmokeyJoe (talk) 05:03, 22 May 2016 (UTC)

I have not previously spent time at MfD but the intro at WP:MFD says "Miscellany for deletion (MfD) is a place where Wikipedians decide what should be done with problematic pages in the namespaces which aren't covered by other specialized deletion discussion areas." You say that abandoned drafts are routinely deleted at MfD. I assume that there is some routine argument given for why these pages are problematic. Can you share that reasoning with us? ~Kvng (talk) 00:18, 22 May 2016 (UTC)

I've had a look at active discussions at MfD and see that Ricky81682 is doing a lot of nominations that basically say, "This is crap and should be deleted." I'm tempted to chime in on all of these draft deletion discussions with. "Oppose, no indication this is a problematic draft." I don't wasnt to contribute to any more time being wasted on these nominations. The issue goes beyond the draft prod proposal for me. If you want to confine discussion here to your proposal, I can start something at Wikipedia talk:Miscellany for deletion. Let me know. ~Kvng (talk) 00:45, 22 May 2016 (UTC)
Engage you in what? A new academic debate based upon the MFD instructions? WT:MFD is not for deletion policy debates, it's for how to functionally run MFD. The fact that people have made the instructions into a maze of regulations is not a reason to engage further in that idiocy. We had two stupid RFCs on whether we can relist discussions because people argued that it was driving editors away. If you think those shouldn't have been deleted, take them all to DRV and convince people that they should be restored for whatever reason you have. I'm using the same reasons and rationales that have been discussed at MFD since 2008 and before that and these are being deleted for the same reasons. If you have some bold new insight as to why all those prior nominators, voters and closers were all wrong, go look for examples, get those discussions reversed and convince some people rather than badgering the people who actually just want to deal with this crap and not just engage in the same navel-gazing month after month. -- Ricky81682 (talk) 01:02, 22 May 2016 (UTC)
Looks like there's a very active discussion about this at Wikipedia_talk:Criteria_for_speedy_deletion#G13_Drafts. I will contribute there. ~Kvng (talk) 01:15, 22 May 2016 (UTC)
Looks like discussion has moved on to Wikipedia:User_pages/RfC_for_stale_drafts_policy_restructuring ~Kvng (talk) 20:13, 23 May 2016 (UTC)
If, as you say, you don't object to these being restored upon simple request, then what's the advantage of deletion over writing a close variant of {{inactive userpage blanked}} for draftspace? —Cryptic 01:38, 22 May 2016 (UTC)
Because there was no support for that before. If you want to support a policy change that better defines when blanking versus deletion is appropriate, I'm on board. However, that first requires some acknowledgement that deletion is appropriate and some definition of when since deletion is obviously done. Abjectly arguing against any policy line for deletions is why we keep going in circles. Otherwise, why not support this and then just mass unprod everything and replace with the template? -- Ricky81682 (talk) 02:08, 22 May 2016 (UTC)
  • Could someone please provide some concrete examples of contributors that have been "chased away" by deletion of their stale/useless drafts? It keeps getting brought up and I haven't seen any actual evidence. Chrisw80 (talk) 00:47, 22 May 2016 (UTC)
    • WT:MFD had two RFCs on whether or not to relist discussions arguing that relisting discussions was somehow a deletionist scheme to chase editors away. Don't be surprised at the evidence you'll get. -- Ricky81682 (talk) 01:02, 22 May 2016 (UTC)
    • I haven't made this claim myself but I do see new editors "chased away" at AfC, AfD and PROD. Unnecessary or overly-aggressive deletion definitely WP:BITEs and regardless of whether you can connect biting to new editor retention, we don't want to bite. ~Kvng (talk) 01:08, 22 May 2016 (UTC)
      I don't deny that it's happened at AfC and AfD, and it's something I disagree with strongly - I just don't see it with stale drafts. Not sure about PROD, though. Chrisw80 (talk) 01:19, 22 May 2016 (UTC)
  • Question: Why can't we just use plain old {{subst:prod}} in draftspace? This would naturally require changing WP:PROD (one sentence?), but that seems achievable, and it seems like a better way to get rid of completely inappropriate pages (i.e., pages that have problems beyond a lack of editing activity) than waiting about for six months. WhatamIdoing (talk) 05:01, 22 May 2016 (UTC)
    • Not a bad idea, it might clear up some of this.. Chrisw80 (talk) 05:22, 22 May 2016 (UTC)
      • I could agree to extending PROD to include material in Draftspace. Blueboar (talk) 18:20, 22 May 2016 (UTC)
      • Exactly. Extending PROD applicability to Draftspace certainly makes sense and would be a fairly minimal change that would still help quite a bit. Right now, apart from G13 and obvious CSD cases, the only other route for deleting pages from Draftspace is through MfD, which is bureaucratically complicated and time consuming for everybody. A simpler procedure, like PROD, for more straightforward cases, would be helpful. Nsk92 (talk) 15:17, 23 May 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Add new chapter Wikipedia:Categorization for topic categories

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

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

FYI

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

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

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

Remove bot flag from inactive bots

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

Some bots are only backups for other bots so infrequently run. Our last major cleanup was last year, and we usually do a prune from time to time. If a bot's operator is still active that is another sign that they could use their bot. — xaosflux Talk 05:16, 4 June 2016 (UTC)
If this is actually meant to be a proposal to change the Wikipedia:Bot policy, I suggest you workshop your proposal over at WP:BON first. — xaosflux Talk 05:16, 4 June 2016 (UTC)

RfC: Editinterface rights for template editors

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
I am self-closing this discussion as WP:SNOW.

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

Support (Editinterface rights)

Oppose (Editinterface rights)

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

Discussion (Editinterface rights)

  • I'm fairly certain this was explicitly rejected at some point, but the originating RFC doesn't appear to have anything about editinterface. --Izno (talk) 11:12, 27 May 2016 (UTC)
    No, but it does mention "MediaWiki space" (or similar) in a few posts, such as those by Jackmcbarn at 14:31, 12 October 2013 (UTC). Note the last thread, How are we defining what a template is?, which explicitly states that MediaWiki space is not included in the proposal. --Redrose64 (talk) 11:33, 27 May 2016 (UTC)
    @Izno: I think you may be thinking of Wikipedia talk:Requests for comment/MediaWiki editor, a completely separate proposal. Jackmcbarn (talk) 20:32, 27 May 2016 (UTC)
    Jackmcbarn, indeed, probably the one. --Izno (talk) 02:36, 28 May 2016 (UTC)
  • It's more that this should be a separate user right, with higher standards than template editor, but below admin. I agree that taking this ability onto TE would make TE harder to obtain, when we need more not fewer constructive template editors, and that it would lead template-competent but CSS-incompetent editors to make mistakes (but, yes, that the primary consequences of these easily reverted errors would be to the editors' own reputations). The actual problem we have right now is that MediaWiki:Common.css and other such pages are effectively WP:OWNed by a tiny cabal of editors, who will filibuster anything they don't like, refuse to implement anything they don't like even when there's clearly a consensus for it, and when cornered into implementing something will implement it they way they want it implemented instead of the way consensus said to implement it. This has been a problem for at least 5 years, and something does need to be done about it. The most obvious solution is to quadruple (or so) the number of editors who can work on these pages, thus undoing the hegemony of the controlling WP:FACTION. At this point, it is virtually impossible to get even the tiniest tweak to an existing class, or the addition of a new class, unless one is very buddy-buddy with the OWNers, who regularly reject WP:ACCESSIBILITY fixes, and the addition of classes for templates (etc.) that they don't personally favor.

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

    Site wide css/js pags are no place to be WP:BOLD. If there is a dispute resolution issue, there are venue to address that. — xaosflux Talk 15:27, 1 June 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC about April Fools' Day jokes

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

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

PROPOSAL DEFEATED
Overwhelming consensus against enacting this. Display name 99 (talk) 03:08, 7 June 2016 (UTC)

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

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

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

Comments for / against

  • Support, as the nominator. One of the reasons cited previously for removal of religion from the infobox was the controversy that it invites. However, non-BLP articles are generally less sensitive, and for the vast majority of them the religious affiliations of the subjects are not matters of dispute, but simple historical facts. I edit mainly historical articles, at which the parameter causes generally no controversy or strife. It is simply a random bit of information about the person, no different than birth date, office, etc. Display name 99 (talk) 22:24, 6 June 2016 (UTC)
  • Oppose Unless the religion is of significant importance to a biography, and is solidly sourced, most biographies will not benefit from having this parameter in an infobox at all. "Random bits of information" are not a rational item for any real encyclopedia, any more than having an infobox parameter for shoe size is a generally useful "good thing." And I can imagine the rush to add "Roman Catholic" to everyone on the List of Saints. Sorry - the fact is that infoboxen loaded with admitted trivia are not sufficiently utile here. Collect (talk) 22:51, 6 June 2016 (UTC)
  • Oppose - Collect has it right. A religion boxes should only be included if the religion is relevant to the subject's notability. The fact that William the Conqueror was Christian and Catholic is unnecessary trivia. Blueboar (talk) 00:13, 7 June 2016 (UTC)
Is the fact that he was born in Falaise, Normandy "unnecessary trivia"? Display name 99 (talk) 00:48, 7 June 2016 (UTC)
  • Oppose - Because all of the strongest reasons the community gave in the recent RfC you linked still apply whether the subject is living or long deceased. Our rules on Categorization of People apply to all people, living or not, and they single out "religion" as one of the five "sensitive" and problematic characteristics that require careful, restrictive handling when Cats & Infoboxes are concerned — unlike "date of birth" or other merely "random bits of information". The religion-related Cats and Infoboxes should, by default, not be used unless religion is a defining characteristic of their public notability; like clergy or religious figureheads, and the religion would not be out of place in the lead sentence of the article. Creating exceptions to a project-wide common-sense convention will only reintroduce many of the same old problems. Xenophrenic (talk) 01:09, 7 June 2016 (UTC)
I have edited countless history articles, and cannot recall any dispute or challenge regarding the religion category. If the material is properly sourced, I don't see the issue. Display name 99 (talk) 01:23, 7 June 2016 (UTC)
"If the material is properly sourced, I don't see the issue.". The issue is not the sourcing, the issue is why you feel a need to include something that is not a factor in the BLP's life. ? Moriori (talk) 03:08, 7 June 2016 (UTC)
  • Oppose unless religion is a major, rather than incidental or trivial, part of a person's notability, it doesn't belong in the infobox. --Jayron32 02:51, 7 June 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

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

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

How exactly would one plan on on doing this conceptually though? B seems unenforceable (How would we hold people accountable to this? It's a volunteer project.) A would be extremely counterproductive to B - lessening the number of people who can address the issues is going to slow things down even further, not speed things up. I don't see how C would affect anything at all - all you need to do to see if they're an Admin, is usually just click on their WP:USERPAGE. Sergecross73 msg me 17:14, 26 May 2016 (UTC)
For C, if you create an account you can use a gadget that will show peoples groups when you hover over their username links. — xaosflux Talk 17:30, 26 May 2016 (UTC)
  • Concerns raised at ANI are usually responded to faster than the OP indicates... so I suspect that his/her experience is non-typical. I don't think we should change our procedures unless it can be established that the issue is more widespread and systematic. Blueboar (talk) 17:49, 26 May 2016 (UTC)
perhaps it's an anomaly but I also can't imagine too many editors have gone all the way to complain about the very process; so it's impossible to know (ie first they run into a problem and bother to take it to ANI..they then go through the bother of dealing with the ANI thread...the ANI thread doesn't work well so they bother to look into the very process of ANI via where we are now..very unlikely..they just go away from Wikipedia editing)...I have read that Wikipedia is having a very hard time attracting new editors...so if fairly straightforward things could be done to make things more professional..68.48.241.158 (talk) 18:48, 26 May 2016 (UTC)
Well, plenty of people complain, its just that they either don't have a workable solution, or can't gather a consensus in their favor to enact the change. Much like this proposal. They're nice ideas, but how do you make it happen? How do you require admin to address AN/ANI concerns in a certain amount of time? And what happens if they don't? And who enforcing this? Sergecross73 msg me 18:56, 26 May 2016 (UTC)
Please read WP:NOTCOMPULSORY. WikiP is a voluntary organization not a "professional" one. I am sorry that you are not happy with the given situation. MarnetteD|Talk 19:06, 26 May 2016 (UTC)
not helpful imo..that's like saying nothing should ever be improved/attempted to be improved on Wikipedia because nothing is required to be..68.48.241.158 (talk) 19:10, 26 May 2016 (UTC)
It's definitely helpful, he linked to WP:NOT, which is a key Wikipedia policy that defines what it is and is not. And it quite perfectly defines a massive problem with your proposal - what exactly would your plan be to enforce point B of your proposal? Sergecross73 msg me 19:26, 26 May 2016 (UTC)
there would be no enforcement mechanism, obviously. It would involve, perhaps, a notice displayed at that space that states it is expected/encouraged that an admin will address each thread within a certain timeframe...perhaps a message sent out to all admins to inform them of the policy/encourage them to add the page to their watchlist etc so they can participate in making it happen..whatever...A is trivial you just announce the rule and enforce it...C would require coding for admins to be identified on just that page...so there you go..68.48.241.158 (talk) 19:51, 26 May 2016 (UTC)
So your plan to speed up the process at ANI is to have a notification that says "Hey volunteers, don't forget, you're expected to volunteer. And do so by x time."? And if they ask "And what if I don't?", the answer would be "There's no repercussions". That would elicit zero change from Admin. Admin are already helping as much or as little as they want to. Sergecross73 msg me 20:12, 26 May 2016 (UTC)
yes, I would expect many more admins to help out if was announced to them that this was the goal there that was going to be strived for..why not??? (I'm probably done going back and forth with you as you've clearly suggested you're not interested in being constructive along these lines, but only critical..so don't want to fill up the thread...you've weighed-in; I'll see if others come along)..68.48.241.158 (talk) 20:17, 26 May 2016 (UTC)68.48.241.158 (talk) 20:21, 26 May 2016 (UTC)
Because these are volunteers and honestly, this is not something that I would want Wikipedia to become. It's already implied on these boards that issues will be handled in a rapid manner, and they are both by admins and non-admins alike. RickinBaltimore (talk) 20:19, 26 May 2016 (UTC)
I was interested to see recently that WP:DYK states Review requirement (QPQ) – For every nomination you make you must review one other nomination (unrelated to you)—​​this is called quid pro quo or QPQ. DrChrissy (talk) 20:24, 26 May 2016 (UTC)
The B proposal not only doesn't make sense in Wikipedia's setting, but it doesn't even work in real life. To influence people, you need either positional power (police, your boss at work, a teacher, etc) or emotional power (family, friends) over people. Your idea lacks both. A random notification saying "Hey volunteers, volunteer harder now, because an anonymous editor is unhappy" lacks that entirely. It just isn't going to work. Sergecross73 msg me 20:37, 26 May 2016 (UTC)

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

C isn't necessary, its already very easy to find this information out, through the ways mentioned above. A isn't necessary either. Non-admin are very helpful in fielding questions before Admin even get there. Ironically, it was a non-admin who was first to notify you that the Village Pump was the correct area to have this conversation when you asked at an improper venue (AN's talk page), so you've literally seen this to be true. I'm sorry you feel that a non-admin gave you bad advice, but I'm not aware of this being a consistent, rampant problem that needs fixing. Do you have examples of this being a frequently recurring scenario? Sergecross73 msg me 20:31, 26 May 2016 (UTC)
I disagree that this discussion couldn't have occurred over there..but it's fine to have it here; doesn't matter. Dr. Chrissy just added something novel and interesting above..68.48.241.158 (talk) 20:39, 26 May 2016 (UTC)
That's not the point, the point was, a non-Admin gave you good advice faster than an Admin did, and he gave you the same advice Admin eventually gave you. And yes, I saw DrChrissy's post, and its a nice observation, but it doesn't negate my point. That situation is still different. They have a motivation to follow that rule - if you don't do DYK posts for others, they'll stop doing them for you. There's no such element in your proposal. Sergecross73 msg me 20:53, 26 May 2016 (UTC)
The point I was trying to make regarding the DYK page is that we have already invoked responsibility onto editors. This invoked responsibility could also be a part of becoming an admin. If admins don't close X number of ANI discussions in a year, they lose their admin rights. Part of my motivation for this is my perceived increase in the number of non-admin closures at WP:ANI when these clearly needed the eyes and thoughts of an admin. DrChrissy (talk) 21:02, 26 May 2016 (UTC)
Ah, I see, I didn't realize that's what you were suggesting. Yes, at least suggestions like yours are at least plausible in that they contain structure and logic to them. My main objection to the IP's plans is that they amount to little more than "Let do more good and less bad" without any realistic plan on how to get there. Sergecross73 msg me 21:15, 26 May 2016 (UTC)
because my suggestions contain no logic nor structure whatsoever...and admins will only do things if there are police officers waiting to arrest them..68.48.241.158 (talk) 01:31, 27 May 2016 (UTC)
That at least seems to make sense as a way of incentivising admin participation at ANI. Potential problems might be: 1) if admins are required to do certain adminny jobs, it might put off people who would otherwise go through RFA if they are not interested in the jobs that they are required to do as an admin. 2) Admins putting in their time and effort to close ANI discussions who are more interested/capable in other areas are a wasted resource. Assuming the number of hours an editor puts in a year is constant, each extra hour doing ANI stuff because requirements is an hour not spent doing something else. 3) Admins doing ANI stuff because requirements might put less effort/thought into it than they would if doing it because that is what they wanted to do. Caeciliusinhorto (talk) 16:08, 27 May 2016 (UTC)
see the link to the discussion I posted below...apparently a part of the problem is there is simply not enough admins and there has been a death spiral in their numbers...there are less than 600 active members over all of English Wikipedia!!68.48.241.158 (talk) 17:47, 27 May 2016 (UTC)
then Wikipedia has itself a major problem that is far beyond what is discussed here..why are there fewer editors and therefore fewer eventual admins? could it be because possible poor practice like that described in the OP is driving people away?68.48.241.158 (talk) 11:21, 27 May 2016 (UTC)
<citation needed>. From what I can see the OP was given reasonable advice regardless of the source it came from. Of course since they didnt actually provide a link to the discussion in question, I cannot be certain I am looking at the right one. Only in death does duty end (talk) 12:30, 27 May 2016 (UTC)
it was called "disruptive editing" and was archived a few days back (note: more appropriate to discuss proposals etc then get into what that thread was itself actually about here)..68.48.241.158 (talk) 12:39, 27 May 2016 (UTC)
Your proposal is dead from inception. Only in death does duty end (talk) 12:42, 27 May 2016 (UTC)
well, okay..thank you for your thoughtful and helpful contribution to Wikipedia.68.48.241.158 (talk) 12:45, 27 May 2016 (UTC)
You're welcome. Only in death does duty end (talk) 13:04, 27 May 2016 (UTC)

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

there's never anything wrong with having better admins...but appears we need more too..and you should probably clarify what exactly you're supporting..68.48.241.158 (talk) 20:23, 27 May 2016 (UTC)
  • Admins who only do speedy deletions are still helping the project. De-admining them because they don't attend AN/I would be negative. And indeed many admins would throw in the bit if they felt compelled to contribute there.
  • Restricting An/I to (parties and) admins is probably not a good idea. It would cut down on thread bloat though, so it's not without it's good points.
  • The same applies to NACs, there might be a few less bad closes (out of a pretty small number) but it would increase the workload on admins, or backlog, or both.
All the best: Rich Farmbrough, 09:07, 28 May 2016 (UTC).

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

I initiated this thread before discovering that there are like 500 something active admins...and apparently falling every year...this is bad imo and potentially ruinous to Wikipedia for a number of reasons...part of the reason there are less new serious editors is because aspects of the site are a mess (like ANI perhaps) and this just chases people away...so you end up with a death spiral...68.48.241.158 (talk) 23:58, 2 June 2016 (UTC)
ANI is only a mess for people who consistently and constantly break policy. RFC/U stopped having teeth after it just became a box ticking exercise just so editors could then go to Arbcom and say "look! ANI and RFC/U were both tried but nothing happened!" RFC/U was never much good for anything except maybe to drag the subject over hot coals and everyone who ever had a beef with the subject could come out of the wood work and throw some tomatoes. What's needed isn't stronger or tougher measures, what's needed is better guidance at the outset. Too many editors edit WP holding on to their precious POV's, COI's etc without any idea how the environment works. Blackmane (talk) 06:50, 7 June 2016 (UTC)

Expand the wording in MOS:POPCULT

Moved to Wikipedia talk:Manual of Style § Expand the wording in MOS:POPCULT
 – By BrightRoundCircle. ―Mandruss ☎ 23:01, 10 June 2016 (UTC)

Should the criteria for "recent deaths" listings on the "In the news" section of the main page be changed?

Following a one month trial, an RfC has been initiated at Wikipedia talk:In the news/2016 RD proposal#RFC: Criteria for the recent deaths section of the main page In the news section to determine whether the criteria for a recent deaths listing on the "In the news" section of the main page should be changed. Thryduulf (talk) 12:40, 11 June 2016 (UTC)

Conflicting info on BLPPROD criteria

WP:BLPPROD states that any source is sufficient for an article to become ineligible for BLPPROD, however, {{Prod blp/dated}} says "... must have at least one reference to a reliable source". I'm assuming the policy page takes precedence, but this needs to be corrected. nyuszika7h (talk) 19:54, 11 June 2016 (UTC)

The policy is a little confusing but both statements are correct. An article is ineligible to be tagged with a blpprod if it had any source in any form that verifies any information in the article. If an article has a valid blpprod then it can only be removed if a reliable source has been added. There are two different criterion, one to add the blpprod and a second to remove it. -- GB fan 20:04, 11 June 2016 (UTC)
Let me see if I understand... Suppose I create a BLP about my non-notable grandmother, and include the statement: "Donald Trump was born in Alaska" (an inaccurate statement which is completely irrelevant to my grandmother, who has neither met Trump, nor been to Alaska) ... And I cite my totally unreliable personal webpage to support this statement. That prevents someone from prodding the article on my grandmother? Something is wrong there. Blueboar (talk) 20:52, 11 June 2016 (UTC)
It's not (quite) that bad: the source has to support a statement "made about the person in the biography". Right in the second sentence of WP:BLPPROD. If your totally unreliable personal webpage was cited for "[Your grandmother] was born in Alaska", it would be ineligible if it was cited before the prod. —Cryptic 20:58, 11 June 2016 (UTC)
The notification about source reliability is the reason for the inconsistent requirements for adding/removing a PROD BLPPROD. If you find an article with bad refs you can't PROD BLPPROD it because there's a fair chance that it's a viable article created by a newbie who didn't know to cite better sources. That goes to AFD for examination. Once an article does have a PROD BLPPROD on it, someone wanting to de-PROD de-BLPPROD it is explicitly told that they need to add sourcing, and they are explicitly told that they have to do better than adding a junk ref. If someone is going to do work to fix/remove a PROD BLPPROD, they need to actually do useful work finding a proper source. Alsee (talk) 18:59, 12 June 2016 (UTC)
@Alsee: WP:BLPPROD is not WP:PROD. Not only does it use different templates, it has different rules. --Redrose64 (talk) 19:26, 12 June 2016 (UTC)
Redrose64 thanx, it was sloppy of me to type "PROD". I've corrected it. Alsee (talk) 19:46, 12 June 2016 (UTC)

Drafts for content already deleted before

I see a not atypical routine occurring with Draft:Austin Petersen where a new draft for a page that was deleted via an AFD discussion (sometimes from a CSD) from mainspace has been restarted in draftspace. WP:AFC will likely automatically reject the page as none of the reviewers want to essentially be overturning an admin's decision without very good reason and there's no clear-cut solution of how to resolve if the draft is worth returning. I've seen the following mechanisms used before:

  • A different WP:AFC reviewer ignore this "rule" and allows it to be submitted (if it's WP:SALTed, G6 would then be needed).
  • A WP:RM request is made and the discussion is done there.
  • A WP:DRV discussion is made about whether the prior discussion can be overturned based on "new evidence" so to speak. UFC 157 was a cross with a DRV allowing a draft to be permitted to then go to AFC before it went to mainspace.

Is there a single policy here or should we try to craft one? In my view I'd prefer DRV rather than RM for at least a discussion about whether to mainspace directly or whether to permit a draft through AFC as it really is to me a discussion about whether to overturn the prior discussion (or CSD criteria if that was the case) and all of three places, DRV isn't that busy in contrast and if there's a rejection the talk page would likely be deleted versus the DRV discussion. -- Ricky81682 (talk) 18:04, 11 June 2016 (UTC)

Its a tricky because why the page was deleted really matters, and this is also partly a question for the AfC project. So what if I create a draft about a topic with a previously deleted article, and when its done, I just move it to article space? Well, hopefully I'm a good enough editor that it it doesn't meet any CSD criteria (excluding G4). Assuming I wrote it myself, without reference or even knowledge of the deleted version, my version most likely does not meet CSD G4, as it wont be substantially identical to the version deleted via AfD. So from a non-AFC standpoint, there is nothing wrong with moving it to article space.
AfC intends to go further than just getting an article past CSD, and tries not to approve articles that will be deleted at AfD. So really, what the reviewer needs to figure out is whether the article has addressed what ever the concern raised at AfD was. Without access to the admin toolset, you of course can't see the deleted article, but hopefully from the AfD discussion and close, you can judge whether the current article has addressed the problem. If your confident it wont be deleted for the same reason, I'd say just go through the rest of the AfC process as normal. If it doesn't clearly deal with the problem, seeking additional input, possibly at DRV sounds like a good idea. Though if the author really wants to go to article space, and you can get an admin to check CSD G4, it can just be discussed after the fact at AfD. (Weighing the biteyness of the submitter's article ending up at AfD, vs not even letting them argue their case there) Monty845 22:02, 12 June 2016 (UTC)

Proposal regarding uncontested AfDs

I have started an RFC at Wikipedia talk:Articles for deletion#Treat uncontested AfDs as uncontroversial deletions. Thanks, SSTflyer 09:03, 13 June 2016 (UTC)

The latest example of the insanity of 1R of any kind per editor per article per day

Here and here. We cannot punish good faith, on either side of that coin. 🖖ATS / Talk 02:53, 13 June 2016 (UTC)

Completely agree. Reverts tend to fall into three categories: Clearly righteous, clearly detrimental to the encyclopedia, and content-related differences of opinion. Current 1RR (and 3RR) policy treats them all the same, but they couldn't be more different. The main problem is the lack of workable alternatives, short of having an admin referee present at all times at every contentious article (which is not feasible and therefore not workable). ―Mandruss ☎ 02:54, 13 June 2016 (UTC)
In "clearly detrimental to the encyclopedia" cases, it would be reasonable for multiple users to make a stand on favor of the good of the encyclopedia. In content-related issues, we shouldn't "gang up" on the other user. עוד מישהו Od Mishehu 14:53, 13 June 2016 (UTC)

Is there an equivalent to { { Template:In-universe } } for religious articles?

Thanks! - Richfife (talk) 02:22, 14 June 2016 (UTC)

Hello, I've found none. Try something like this:
--NaBUru38 (talk) 19:04, 14 June 2016 (UTC)
It would approach neutrality to say "This article or section is written from a believer's perspective." Mangoe (talk) 19:07, 14 June 2016 (UTC)
That could also work. --NaBUru38 (talk) 19:44, 14 June 2016 (UTC)
See {{Faith primary}} for the usual template for this sort of thing. ~ RobTalk 03:58, 16 June 2016 (UTC)

RFC on setting up a separate section for BLPs at requests for page protection

Are we allowed to delete a referenced statement if we all agree that it is false?

I don't know whether this is the right place for this question, because at the top it says, "If you have a question about how to apply an existing policy or guideline, try one of the many Wikipedia:Noticeboards", but over there it says to come here to discuss existing policies! But here goes. We've been having a discussion at Talk:Sea level rise#Seawater penetration below ice about whether we can delete a statement in the article if we agree that it is false, but it has a reference. In this case the reference is not a peer-reviewed journal or anything, but I maintain that even if it were, we should delete things that are false, or at least mark them as Dubious. Others claim that that is "original research" on our part. It seems to me (and another contributor) that the prohibition of original research applies to what one puts into an article, not what one takes out of an article, and that a reference is no excuse for putting false information into Wikipedia. (Of course, there may be cases where it is not clear, but that's another question. I'm talking about cases where everybody agrees that the statement is false.) Eric Kvaalen (talk) 14:19, 12 June 2016 (UTC)

If it is Fringe claim then you can argue it should be ommitted per WP:FRINGE, and if there are other sources around that claim the opposite and clearly outweigh the "false" claim then you can argue that it fails WP:DUE, and that it is within your editorial prerogative. However, for editors to simply reject a claim outside of those arguments simply on the basis they believe the claim is not true would seemingly violate WP:TRUTH. Betty Logan (talk) 15:14, 12 June 2016 (UTC)
Such issues are also handled under WP:ONUS. Alanscottwalker (talk) 15:23, 12 June 2016 (UTC)
In addition (or perhaps as an alternative) to the above, presuming you have other reliable sources for 'true' fact, and if appropriate, you can present and rebut the 'false' fact in the article: Source A claims X, but Sources B & C claim Y. I think a central hinge of the whole thing should be that you evidence your action against a reliable source rather than basing it upon what you know. --Tagishsimon (talk) 15:34, 12 June 2016 (UTC)

In this particular case, the discussion on the article's talk page seems show little support for the idea that the material in the article is "false". Indeed, most of the other editors there suggest that you have misunderstood the material. If you really could convince everyone else at the article that the claim in question is dubious, they would probably support removing it. But to convince them, you may need to rely on more than your own personal opinion.

You are correct, however, that the concept of "original research" is based on what actually appears in the article. The issue of whether to include something at all is a more complicated one. The choice has to be based on an overall knowledge of the reliable sources in the area, combined with editorial judgement. It is not the case that, just because one source says something, that something must be included in an article - otherwise our articles would be mere copies of their sources. Editors are supposed to work together to determine how to synthesize the material in numerous reliable sources into a single, coherent article. This will necessarily require making decisions about what to include and what to leave out. — Carl (CBM · talk) 15:46, 12 June 2016 (UTC)

Originally I marked it as Dubious, and explained on the talk page. Someone reverted and gave his explanation. In the end he changed his mind and removed the statement completely, so I'm pleased with the outcome. But I argued for a long time that if we all agreed it was false, we should remove it or at least mark it. It was hypothetical because they hadn't yet agreed that it was erroneous, but I couldn't see the point of convincing them if they were just going to say that we should leave it in even if it's wrong, because it has a reference. In my understanding of the English language, "verifiable" implies "true" as a necessary but not sufficient condition. As for finding a source to support my contention, I didn't think it was necessary. All one needs is a couple elevations and then one does an elementary calculation. Eric Kvaalen (talk) 16:00, 12 June 2016 (UTC)

Let's assume for the sake of argument that the sources for the elevations are impeccable and that your calculation is without error. Let's also assume for the sake of argument that nobody in any reliable source has ever done that calculation and come to that conclusion. Do we allow this Synthesis? No. We do not. There may be a reason that we don't know about that invalidates either the data, the calculation, or the conclusion. It is surprisingly easy for even intelligent and well-educated editors to miss something subtle. Furthermore, if we allow your calculation/conclusion we would also have to allow claims that are supported by data/calculations that are carefully chosen to deceive. Pseudoscience is full of such calculations leading to wrong conclusions. --Guy Macon (talk) 16:53, 12 June 2016 (UTC)

Yes of course, "if we all agree that it is false" we will not include it. How is this even a question? But it's probably not relevant to your actual situation. Dicklyon (talk) 17:12, 12 June 2016 (UTC)


Well, it is a question. Look at what the people above have been saying – that it's "synthesis", that we have to have a supporting source... And on the talk page I mentioned, people were taking the same line, that we can't remove it because it's sourced. They didn't ask me to convince them that the statement was false (until one guy did near the end), because they wouldn't accept the principle that we should take a sourced statement out if we agree that it's wrong. Eric Kvaalen (talk) 19:09, 12 June 2016 (UTC)

Eric, See WP:Consensus. If everyone agrees that something is wrong, and everyone agrees to remove it... Then yes it can be removed. However... that isn't what happened at the article in question. Everyone didn't agree... In fact most of the other editors disagreed with you. That's not a consensus. Blueboar (talk) 22:19, 12 June 2016 (UTC)
True. Eric Kvaalen (talk) 04:46, 13 June 2016 (UTC)

Carl, and anyone else that comes along: This extended discussion arises from a statement that had been garbled by a secondeary source. (It has since been removed, and without any objection, and could have been deleted at any point.) The on-going problem has been that Eric wants a determination that he can delete material on the basis of falsity. More particularly, on his own intuition of falsity. When he was disabused of that he wanted to substitute a "simple" calculation (except that the necessary work is not simple), which is where the OR issue comes in. In short, he was not proposing a cacluation, demonstration, or other argument that might convince the rest of us that the sky is blue (or some such), he was proposing a justification for acting on his own. Ironically, there were bases on which he could have proceeded (such as failing verification), and some of these were suggested to him. But he seems to have a massive WP:HEARing problem, and I suspect all further discussion (like the past discussion) is futile, and a giant waste of time. ~ J. Johnson (JJ) (talk) 20:10, 12 June 2016 (UTC)

Fully agree. Eric, let me be even more direct: No. If you do this you will be blocked from editing Wikipedia. --Guy Macon (talk) 21:41, 12 June 2016 (UTC)
What J. Johnson says above is not true. I was not asking whether I could delete it, I was asking whether we could delete it. Nor did I say something like "on my own intuition of falsity". I repeatedly emphasized "if we all agree". (I made the "mistake" in my first entry of saying that the statement "seems totally illogical", giving the impression to J. Johnson that I was just going on intuition.) They accused me of "original research" before even hearing me support with numbers my initial verbal explanation. I was not proposing acting on my own. As for "verification", the source really did say what was alleged. Eric Kvaalen (talk) 04:46, 13 June 2016 (UTC) Every word we speak and every sentence we write is recorded, and we must give account one day. Eric Kvaalen (talk) 19:43, 13 June 2016 (UTC)
They acted correctly. If everyone agrees that some original research is valid and leads to a correct conclusion, they still cannot edit the page to match what they are now all convinced is true. Thus there is no point in discussing whether or not everyone agrees with the original research -- it make no difference to the content of the page. This is a necessary part of writing an encyclopedia as opposed to some other form of writing.
Imagine a Wikipedia page where someone argues that celery has negative calories, based upon the simple calculation of comparing a reliable source for the calories expended in chewing the celery with another reliable source for the amount of calories in the celery and finding that the first number is bigger than the second. Now imagine that every editor working on that page agrees 100% with the sources and the calculation. Could they then have the page say that you use up more calories chewing the celery than you get from it? No. That would be original research. They would have to find a source that comes to that conclusion. Of course in my made-up example, none of the editors happened to know that there are two things commonly called "calories" -- the real scientific definition and the definition on the labels of the foods you buy, which are actually kilocalories. That's why we don't allow original research. Sometimes there are subtleties that invalidate what seems like a simple calculation. --Guy Macon (talk) 17:27, 13 June 2016 (UTC)

There are many reasons to remove referenced statements (e.g. for it being wp:fringe, or making an wp:undue point. However, removal because the reference provide false information puts the onus of evidence to the editors proposing the removal. A retraction or rectification would do, but even another reliable source claiming the first source is false is not necessarily enough as such claims and counterclaims are part of the scientific process. At best we could mention there are opposing view. If we find mainstream consensus that a claim is indeed false we can of course delete it (e.g. the 19th century models of light as either wave or particle have been shown to be irrelevant). As stated many times above, intuition and even agreement of editors will just not do. Arnoutf (talk) 17:47, 13 June 2016 (UTC)


You and Guy make it so that once a referenced statement has been put into Wikipedia, no matter how obviously wrong, and no matter how many editors can see that it's wrong, it can never be taken out again unless someone finds another reference specifically addressing the point and saying the opposite. And even then maybe not. I'm glad that some people disagree with you, such as Dicklyon and User:Gravuritas (June 5 and June 11 comments on the talk page). Eric Kvaalen (talk) 19:43, 13 June 2016 (UTC)

You misread my post. Fringe (agreement a source interprets evidence and fact following absurd theories) and Undue (agreeing that the facts, while true, are irrelevant to the article; or by their mentioning bias the scope of the article) are examples of very good reasons to remove a sourced phrase. But agreement something is false (agreement that the facts in a reliable source are wrong) without any factual, reliably reported, support of that allegation is not. If we allow that in, many articles could easily be taken over by groups of fanatics claiming that all sources that do not follow their worldview are false. Arnoutf (talk) 19:58, 13 June 2016 (UTC)
No single rule can account for this. On one hand, if there's conflicting sources and clear problems with some that editors can work out, they are not obliged to be stenographers. No number of citations certifying common misconceptions require us to put them in every relevant article. Similarly, if a couple of reliable sources were to report something extraordinarily unlikely, it could still be excluded from the encyclopedia per WP:EXCEPTIONAL. On the other, these powers should be used sparingly and based on consensus. Imho, someone in the conversation arguing these OR and SYNTH concerns must also put forward a prima facie case that the sources are factual, reasonable, and reliable.--Carwil (talk) 20:49, 13 June 2016 (UTC)

Fundamentally, if "we all agree", we can do whatever we want, including re-write policy. But that's not so relevant. Do situations come up where sourced statements are found to be false? I'm sure they do. It's kind of pointless to speak generally about "synthesis" without looking at cases, but basically what you need is consensus; consensus that the source is not reliable, or that it was misled by a hoax, or whatever. Frankly, I think editors do such synthesis all the time, and that WP:SYNTH is being over-interpreted here. Dicklyon (talk) 22:02, 13 June 2016 (UTC)

(ec) It's not so much an over-interpretation as it is an accepting for the sake of argument the hypothetical situation of everybody agreeing that a particular bit of synthesis leads to a truth but everybody also agreeing that it is indeed synthesis - that no source exists that has reached the same conclusion. In that carefully-defined hypothetical (carefully defined by Eric Kvaalen because he thinks that his particular synthesis leads to truth and objects to other editors refusing to discuss whether or not it really does lead to truth), we follow the sources, not the results of the calculation. What you describe above is consensus to reject a source, which happens all the time. What Eric tried to do is to draw a conclusion based upon his calculations about whether seawater will flow under ice in a particular situation -- a conclusion that exists in no sources. And he wants the other editors to debate him about whether his calculations are correct, not simply tell him that we cannot use his unsourced conclusion even if it is correct. It's a reasonable request, but it isn't how Wikipedia works. We need sources, not the results of calculations. — Preceding unsigned comment added by Guy Macon (talk • contribs) 23:13, 13 June 2016 (UTC)
I'm sure there are sources somewhere that state explicitly that water cannot flow under ice if the top of the ice is as high above the water level as the bottom of the ice is below! I don't think anybody who was in the discussion would deny that, or would deny that sources could be found for this well-known fact. The trouble was that they didn't agree that we could take the statement out based on our own so-called "original research". Actually in the end one of them did take it out, but another maintained his position that we cannot remove something just because it is false. Two others at this point said the situation is too complicated to decide whether the statement was true, so my hypothetical question of what to do if we all agree does not apply in this case. Eric Kvaalen (talk) 08:39, 14 June 2016 (UTC)

I haven't looked at the specific example that inspired this discussion. As a general point, we adhere to the principles underlying Wikipedia, but not to the point of defying common sense. For example, sometimes an otherwise reliable source will contain an obvious error. If knowledgeable people all agree it's an error, we shouldn't make a fetish out of including it anyway. That said, the best way to deal with errors in sources that usually are reliable, at least over the long term, is to find other reliable sources that cover the same material correctly. We wouldn't continue to rely on a source that says X, even if that source is usually reliable, if five other equally reliable sources say not-X. Newyorkbrad (talk) 22:51, 13 June 2016 (UTC)


I would note that there is a difference between violating verifiability by including something that editors believe is true without reliable sources, versus not including something that editors believe is false, but which is supported by what are thought to be formally reliable sources. The first is much more serious than the second. If it is clear that the source has made a mistake, but no contradictory source can yet be found, this is probably something to work out in the context of WP:IAR, not by saying something that contradicts the presumably mistaken source, but by just not saying anything. --Trovatore (talk) 23:32, 13 June 2016 (UTC)

I wouldn't even call that IAR, its just sound editorial judgement. When the subject matter is actually uncontentious, it is routine to make a judgement call to not include material that you could have sourced, and it can be for a variety of reasons, including this one. Monty845 02:44, 14 June 2016 (UTC)
  • Yes we are: If there's consensus to remove content, content gets removed. It's as simple as that. If there's consensus to use one source rather than another to source the exact same point, it's OK to remove that one source. Wikipedia is about making choices; we can't expect to have EVERYTHING the way Google can. pbp 04:13, 14 June 2016 (UTC)
    Absolutely. Reliable sources can become incorrect at any time as events unfold. Hawkeye7 (talk) 04:58, 14 June 2016 (UTC)
The- for want of a better word- anti-Eric group is misrepresenting the case. Let's go back to the actual wording in question: the actual words in the article were: "Because the basin lies kilometres below sea level, seawater could penetrate beneath the ice". That seems to me to be a straight non-sequitur, which has no place in a WP article, and it does not require Eric's or anybody else's intuition to recognize it as such and delete it. If the received and published wisdom within the iceologist expert community were that, in fact, basins 'kilometres below sea level' always do allow seawater penetration below the ice, then the WP article, addressing the general public, needs to impart that knowledge in the article beforehand.
So I would suggest with hindsight that it would have been reasonable to delete the sentence as the conclusion doesn't follow from the premise, and the imbroglio about whether the latter part of the sentence was true or not was unnecessary.
Turning to the further debate about whether or not to delete something because there is evidence that it is false: I am sorry to see so many people misunderstanding WP:OR. If a line of reasoning (whether WP:OR or not) shows that something in a WP article, (yes-even something that is referenced), is false, that is a good reason to leave it out (or delete it if it already in the article). If anyone wishes to differ from this view then please quote the precise wording form WP:OR which says that OR is banned from being used in the /debates/ about what is in article (as opposed to the content of the article itself). Much of the talk pages (including the legit stuff, not just the blabla) consists of WP:OR, quite rightly.
Gravuritas (talk) 12:49, 14 June 2016 (UTC)
You may want to read about Saltwater intrusion. This does not seem at all like a non sequitur. Saltwater intrusion under the ice is exactly what you would expect (under suitable circumstances). WhatamIdoing (talk) 20:04, 17 June 2016 (UTC)
I certainly agree that statements that are agreed to be false should be removed even if cited. I think you should raise a RfC in such cases though to ensure there is such agreement. I went through this business some time ago when someone put in a statement from a maths textbook that was wrong. I tried arguing at first that it was simply wrong by showing a proof but it needed other editors to come along to get rid of the business against the insistence of the contributor that it was in a textbook and correct. If something false is noted by a number of reliable sources then it gains weight even though wrong and one should try and find something saying it is wrong and put that in. Dmcq (talk) 20:27, 14 June 2016 (UTC)
Framing this as "deleting a false statement" is a bit of a red-herring, as the sentence involved was not so much "false" as garbled. And Eric's conception of what it implied was even more garbled. Note that there was no objection to removing the sentence; the issue was entirely on the basis for doing so. The issue of WP:OR was not about developing an argument on the Talk page for the purpose of convincing other editors; it was about him making a determination of "falsity" on his own work. This, as well as suggestions as to how he could proceed in getting that sentenced removed, were explained to him, but he has been resistant to instruction.
Eric's "if we all agree" was an entirely hypothetical assumption, and I think he got some resistance for trying to back everyone into acting on that assumption. His query is not a genuine point of inquiry, but an attempt to get cover an action on which he was already set. ~ J. Johnson (JJ) (talk) 22:43, 15 June 2016 (UTC)
So JJ, why did I say "if we all agree"? I couldn't take "an action on which I was already set" because you would have reverted it (obviously). As I said above, all is recorded. Eric Kvaalen (talk) 07:24, 16 June 2016 (UTC)

Discussion re Verifiability issues with Wikidata

Regarding the recent RFC - WP:VPP#RfC: Wikidata in infoboxes, opt-in or opt-out?... Based on some of the negative comments, I am becoming concerned that Wikidata is adding unverified and unreliable information to Wikipedia. My initial reaction was to start a formal RFC on the issue, but it was suggested that many of those negative comments were based on misunderstandings. I am not all that familiar with how Wikidata works (and I suspect the same is true for others). So... before starting any formal RFC, I think it would be useful to have a Q&A session... I where those with questions about Wikidata can ask them... and get answers from those who are more familiar with it. Please don't debate the questions or answers... the point here is to clarify, not confuse. Blueboar (talk) 12:05, 17 June 2016 (UTC)

Questions and answers

  • Question: Where does Wikidata get the information it compiles? Is it user generated? Blueboar (talk) 12:05, 17 June 2016 (UTC)
    • It's mostly user-generated. Sometimes bots provide the data, such as in limited cases after {{Persondata}} was deprecated, but the point of origin is still a person. ~ RobTalk 16:39, 17 June 2016 (UTC)
    • Bots and a number of semi-automated programs/scripts have done an extensive job pulling content from each of the client wiki's categories, infoboxes, and a few other points, usually where the data is semi-structured (where a client wiki is any language Wiki*). There are also manual changes made. --Izno (talk) 16:50, 17 June 2016 (UTC)
  • Question: What steps does Wikidata take to ensure that the information it compiles is accurate, reliable and verifiable? Blueboar (talk) 12:05, 17 June 2016 (UTC)
    • This is a monolithic question and with literal Wikidata pages (plural) dedicated to an answer. Do you have more discrete questions that could be answered separately? --Izno (talk) 18:27, 17 June 2016 (UTC)
      • well, could you summarize one or two of the steps? Blueboar (talk) 22:20, 17 June 2016 (UTC)
        • I guess the problem I'm having here is one of literally monolithicity (probably not a word): Wikidata is not one creature. Just like en.WP, there are a number of different people working in different ways to add data to the project. There's nothing that Wikidata (as in, the program that displays on your computer) itself does to ensure that the information it has is accurate, reliable, and verifiable. OTOH, there are pages like d:Help:Sources which indicate how to add a source, and d:Template:Constraint and d:Help:Ranks which help in weeding out horrifically bad data or in sorting good from bad data. A large number of the statements in Wikidata also don't need sources or which are self-sourcing (and so it makes no sense to formally add a source--such as IDs in national library databases). There is the question of requiring verifiability, as below, which isn't required now, but is certainly desired by a good part of the project, as we are aware that we are a wiki. Then there is the question of vandalism, as asked in #Discussion (Wikidata verifiability)--there is work being done from an automatic viewpoint there, and people of course handle vandalism where they can. Is there anything else I didn't touch on that sparks from your question? --Izno (talk) 00:30, 18 June 2016 (UTC)
  • Question: Does Wikidata have any provision to prevent circular referencing? That is, does Wikidata pull a fact from, say, English Wikipedia, and then re-add it to English Wikipedia based on the source from English Wikipedia? If Wikidata does this, is there an easy technical fix to prevent this? Tazerdadog (talk) 18:08, 17 June 2016 (UTC)

    • Per my comment above, yes, but in a "static" capacity--that is, the information was imported once and rarely is it re-imported. Bots working in this capacity now are usually required to use a source statement of the sort "imported from: X wiki", which would be one way of excluding this information, but that is only for the newest of additions. Older additions will not have this source set, or most-usually, any source set. A module on Wikipedia could prevent use of the Wikidata entry where a source is lacking for the information, or where that source is "imported from", or any of another set of solutions. (Note: There may be multiple sources per single statement in Wikidata, so a module would need to check for the existence of other sources.) --Izno (talk) 18:24, 17 June 2016 (UTC)

  • Question: Does Wikidata have a verifiability or similar policy that requires data to be reliably sourced? SarahSV (talk) 19:39, 17 June 2016 (UTC)
    • There is a proposal at d:Wikidata:Verifiability. Note that it demands data from "authoritative" sources, not merely "reliable" ones. WhatamIdoing (talk) 20:12, 17 June 2016 (UTC)
    • The proposal is just that. It neither a policy or a guideline. The RfC's at d:Wikidata:Requests for comment/Sourcing requirements for bots make interesting reading. The result seems to be As a whole, the idea of requiring sources is rejected. As I read the page the oppose votes seem to feel that a project can choose not to import data that is not referenced: a consumer - e.g. a Wikipedia - can choose to discard unreferenced statements in Lua. StarryGrandma (talk) 22:47, 17 June 2016 (UTC)
      • Thanks WhatamIdoing. It seems it was proposed several years ago and hasn't been edited since January 2015, so I take that to mean there is no sourcing policy. I noticed recently that a bot collected unsourced (and contentious) text from the Italian Wikipedia, added it to Wikidata, and it then ended up on the English Wikipedia, so I've been wondering how these decisions are made. SarahSV (talk) 22:54, 17 June 2016 (UTC)
        • The proposal was a nearly blank page until ~18 months ago – little more than an aide-mémoire that they should probably have a policy about this. The RFC that StarryGrandma links to is a discussion that happened about eight months after the first edit at Wikidata. It's possible that the community's views have evolved since then. WhatamIdoing (talk) 23:07, 17 June 2016 (UTC)
          • Consider d:Wikidata:Project chat/Archive/2016/06#Verifiability policy from June 2016. Correct me if I am wrong, but the reason Wikidata is stalled on their Verifiability policy is: 1) Most feel that, like other projects, they are responsible for the quality of their own data. 2) They can't reliably import references. 3) They don't have the manpower to add references. After reading this and the discussion below I would suggest that the English Wikipedia, as the largest project, could help. Those of us who like infoboxes, in an opt-in manner, could start using Wikidata in the boxes and add the references to Wikidata. StarryGrandma (talk) 07:02, 18 June 2016 (UTC)
  • Question: How does Wikidata prevent the transmission of Original Research? If Someone adds OR to an article hosted on (say) the Russian language version of Wikipedia, could it end up being picked up and transmitted to the English language version via Wikidata? Blueboar (talk) 10:27, 18 June 2016 (UTC)
    • Only if someone deliberately adds it to Wikidata. OR is rarely a concern; the information we most-often deal with at Wikidata are factoids on the level of infobox statements which are usually trivially verifiable by Google searching, not complex ideas that would indicate OR. --Izno (talk) 13:03, 18 June 2016 (UTC)
      • what about bots... What is concerning me is that if someone deliberately adds an OR factoid to one of the WPs... A bot will pick it up and add it to WD... And then it will be transmitted to all the other WPs from WD. Can this happen? Blueboar (talk) 21:46, 18 June 2016 (UTC)
        • Rarely is it the case that something of completely fictitious nature is added that is not done so via a vandalism edit. A bot could pick it up, but the likelihood at this stage, I would say, is low, doubly so because there aren't a large number of bots actively running. Most users who are adding data via semi-automated means usually check their data before addition, and a number aren't using the wikis at this point--they're getting data from public domain sources like the United States government and sourcing it appropriately as such. Where users add false data in this fashion, they're usually called out pretty quick and asked to revert their edits--and where they don't, they are reverted by others. This behavior is little-different from en.WP. --Izno (talk) 23:52, 18 June 2016 (UTC)
  • Question:
    • Insert answer here
  • Question:
    • Insert answer here

Discussion (Verifiability issues with Wikidata)

  • Wikidata has all the same pros and cons of the "anyone can edit" philosophy on Wikipedia. The issues stem from lower vigilance on Wikidata for errors, at least as I perceive it. They don't appear to have enough editors to comb over everything like we do on the English Wikipedia. Additionally, vandalism on Wikidata is rarely obvious, since it takes the form of introducing a false tidbit of information rather than inserting whole sentences that appear blatantly ridiculous. Ideally, Wikidata should have the capability for references for every single data point, and unverified data points should be considered a backlog worth clearing. ~ RobTalk 16:41, 17 June 2016 (UTC)
    References can be inserted for each data point. --Izno (talk) 16:49, 17 June 2016 (UTC)

    To answer some more of those comments, yes, there are fewer direct editors. So vandalism is an issue in that regard presently. (I suspect we're getting to the point where a ClueBot would be good, and steps are being made in that direction; c.f. d:WD:ORES.) Watchlist integration is present for Wikipedia editors, should they enable the option in their preferences.

    Regarding the "curating" point of view, yes, there are fewer, but just as on any wiki, when we see an error, we correct it. What would help in this regard is page stewards here stepping in on the Wikidata items related to their topic-of-interest and updating the Wikidata item with referencing statements. It's a big step for a lot of people I would suspect, but it will have massive gains down the road for every other project in the Wikimedia movement. (Contrast: French Wikipedia has already largely gone the route of "we don't want the data, or at least, we don't want any of the unreferenced data--we're big enough not to care"; while I can't comment on how that's working out for them, it would have been beneficial for English Wikipedia if they had, clearly--and conversely, if we had had this discussion earlier.)

I wonder if some of the scepticism about Wikidata comes from a sense that it is just another, slightly different, language Wikipedia; it contains information and references, and so does en-wiki; en-wiki is in fairly good shape, so why would we allow in data from another wiki that is outside our control? It's certainly true that we rarely interact with other language Wikipedias (though some editors work in more than one). But that leads to a lot of duplicated effort. To address the point SarahSV made above about the genre of Night (book), think about how that is handled now in multiple Wikipedias -- each language wiki has to make its own decision about whether the book has an agreed-on genre, and the effort they expend in making that decision has no value to other wikis; it must be duplicated. If, instead, many different Wikipedias all referenced that data value from Wikidata, the discussion would happen once, and in one place.

There's no question that if we can achieve that situation, all Wikipedias will be better off; and those of us who share the utopian dream of making the sum of all knowledge available to everyone will surely want that end result; the question is whether working towards that is a net benefit to the project. To the right is a diagram that shows how I think about this. (I'm not very knowledgeable yet about Wikidata, so I hope if I am making a mistake here, others will correct me.)

Here are a few questions and concerns, along with what I see as the current answer, and a sentence or two about how things should evolve.

  1. What if an article I'm working on contains data sourced in Wikidata, and it's wrong? Right now, if you're editing an article and the data is wrong, you just fix it in the article. Occasionally you have to do something a bit more complex, such as fix a template or upload a revised map image, but you don't have to leave en-wiki to do it. If data is wrong in Wikidata and it affects your article, you have two choices: (a) go to Wikidata and fix it, or post a note requesting a fix if you don't know how; or (b) delete the reference to Wikidata and replace it with local information.
  2. What mechanisms are there for ensuring that data sourced from Wikidata adheres to a minimum quality standard? The possibilities here, which aren't mutually exclusive, are (a) only allow Wikidata in by explicit reference, choosing to do so article by article and infobox by infobox (this is opt-in), or (b) require that all data coming from Wikidata has minimum standards, defined in terms of Wikidata's data structures. Some approaches to this have been discussed above, and I think this is where SarahSV's question about WP:V is relevant. If we think of WP:V as a filter on the data we allow in en-wiki, then it clearly should apply to Wikidata too. Sarah is asking about Wikidata's version of WP:V, which is a good question, but the "allowing in" of data is happening on the line on the diagram above that joins Wikidata to en-wiki. That's where our WP:V should apply, which means that the methods of including Wikidata should be equipped with filters that help ensure WP:V is satisfied. But this can only happen if there's any data on Wikidata that satisfies WP:V in the first place, and that takes us back to the previous question.
  3. How can I prevent the contents of articles I work on from changing without notice because Wikidata has changed? This is Curly Turkey's original complaint, and since I'm almost exclusively a content editor myself, I sympathize, and originally !voted for opt-in to prevent this. I've since become convinced that the best answer is to make WP:V apply to the data that shows up in our articles.

Sorry for such a long post, but this is a complicated topic and I hope this can contribute to clarifying the discussion. To sum up, I would say that if we embrace Wikidata, it means that our article content will gradually become distributed between en-wiki and Wikidata. This will make editing harder, and we have many non-technical editors who will probably never figure out how to edit Wikidata at all. However, the benefits to en-wiki are real, and the benefits to the global Wikipedia project, in all languages, are potentially enormous. We ought to want to make that happen, and I believe it's a solvable problem. Mike Christie (talk - contribs - library) 16:34, 18 June 2016 (UTC)

Mike Christie: That's not my "original complaint". My original complaint had more to do with data from Wikidata being forced on infoboxes where they had been deliberately left out (isbns, religion, etc). Opt-in would mean that once an infobox has opted in to use Wikidata for particualr fields, editors accept that the data can change. Until now, any parameter left out of an infobox was interpreted as DO NOT WANT and didn't display. With the new Wikidata-enabled infoboxes, these fields that have been deliberately excluded instead get re-interpreted as FETCH FROMWIKIDATA—and thus isbn, genre, and religion fields showing up where it had been decided not to use them. Curly Turkey 🍁 ¡gobble! 22:14, 18 June 2016 (UTC)
Great post Mike - whether the diagram is totally accurate or not, I think it encompasses the model simply and very well. I agree that the potential benefits are huge but so are some of the issues.
One of which has been the well meaning use of bots to export data e.g. persondata from WP to WD. Great but they haven't taken the references, if any, as well, which is why people are commenting about circular data and until there is some sort of reference bot I don't see much alternative to double entry and references being manually copied from WP to WD. Nthep (talk) 18:57, 18 June 2016 (UTC)
Persondata was unsourced, so there were no refs for them to take along with it. WhatamIdoing (talk) 20:26, 18 June 2016 (UTC)
A statement also true of most infoboxes and categories, from whence much of the Wiki-data comes. Even were they sourced, we'd somehow have to account for hand-written citations, or malformed citation templates for the references, since those are not machine-readable. Even citation templates are only barely machine readable, in that their placement in or near an infobox is not trivially identified by a machine. --Izno (talk) 21:05, 18 June 2016 (UTC)
It sounds like a classic case of GIGO (if you put Garbage In... you get Garbage Out). Because WD takes in unverifiable info ... It gives out unverifiable info. That's a problem at both ends. Blueboar (talk) 21:40, 18 June 2016 (UTC)
I'm not sure I said it clearly enough, but perhaps I should: I doubt anything on Wikidata is actually unverifiable, as per my statement re Google-able above. This is a lot-the fault of having guidelines at en.WP and elsewhere which discourage adding references in infoboxes (or in the lead!) as there exists a presumption that, where an piece of information is important-enough for the infobox, it's probably going to be referenced in the text (and where categories can't be sourced!). I wouldn't necessarily call it GIGO in this case, but it's probably not "brand-spanking new car in, brand-spanking new car out" either. --Izno (talk) 23:56, 18 June 2016 (UTC)
That's the process at fault extracting information from infoboxes which en:wp uses as summary rather than searching the text for the information and hopefully the reference. 86.159.69.162 (talk) 10:17, 19 June 2016 (UTC)
There is just about no other way to move information automatically, and even semi-automatically makes it difficult. Wikidata has a mission too, and while sourcing is desirable, having content also is desirable. Calling that mission misguided, or even faulty, would be going the completely wrong direction, since we wouldn't even be having this discussion then. :) --Izno (talk) 13:04, 19 June 2016 (UTC)
Style over substance, eh? Content that others aren't prepared to use because it's not verified is a wasted mission. 86.159.69.162 (talk) 13:51, 19 June 2016 (UTC)
Surely the question here is not whether what Wikidata does makes sense in its own terms (that's a question to be debated on Wikidata's talk pages) but whether what it does can be used here, and if so how. If we are able to be selective about what Wikidata we use here, we shouldn't care about the data that doesn't get selected. Mike Christie (talk - contribs - library) 14:02, 19 June 2016 (UTC)

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

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
As this RfC wound down, some participants decided to propose a new RfC, the one concerning where Wikidata fields will be allowed. If that happens, as seems likely, then that RfC is likely to supersede this one, in one way or another. That solves a problem that I was struggling with in closing this one. When people decide over the course of an RfC that they're not sure what they're voting on, or that they'd rather be voting on something else ... and that came through loud and clear from the start ... the safest conclusion to draw is no conclusion, because we're not mindreaders, and we don't actually know how the discussion would have played out if people had been talking about what they really wanted to talk about. Also, the participation here was relatively small for such a big question, and that was probably because the question concerned infoboxes (more about that below) and because many voters perceived the question as being somewhat technical. Also, the question posed in the RfC wasn't clear to the voters, and different voters responded as if they had been asked a different question. I don't see in even a single "opt-out" rationale an acknowledgment of the question that Curly asked. For all those reasons, I think the wisest course of action is to avoid making a call on this RfC at this time, to chalk it up as inconclusive. The alternative would be to ask probing questions about what people really meant, did they really understand the question ... and that would only serve to make the next RfC less pleasant and less productive. The only downside to not making a call is waiting another 30 days or more before taking action, and that's the right thing to do here. That doesn't mean that this RfC was a waste of time; I got the sense that voters on both sides really didn't have uniformly strong feelings to start with, but developed their opinions as the discussion progressed. Of the last 11 votes that went one way or the other, 10 were for opt-in (roughly speaking, the anti-Wikidata-in-infoboxes position). I've noticed when closing previous RfCs that when a pattern develops toward the end, that tends to signal which way things are going in the future. I have one suggestion: don't overshoot with the wording of the question in the next RfC. If voters decide to erect barriers to Wikidata content in infoboxes or article text, that's not at all the same thing as deciding that Wikidatians (or Wikidatans, take your pick) aren't welcome on Wikipedia, or that it's time for them to toss their work in the trash. Wikidatians have been told for many years that infoboxes were a good target to aim for, and many of them have been working with that goal in mind. But infoboxes are the last place I'd choose as the only focus of a community that is just taking its first tentative steps at merging its work in some way with Wikipedia. When I mentioned that I was closing this RfC over at the admin's noticeboard, the replies I got were "sounds more daring than wrestling crocodiles naked" and "Warm yourself up first with negotiating Kim Jeong Un out of his nuclear arsenal". Arbcom basically threw up its hands the last time it wrestled with infoboxes. I would have reservations about any RfC that's framed in infobox-or-nothing terms. I don't have any answers here; I'm just asking that you not make the question in the next RfC broader than it needs to be. See you there in 30 days or more. - Dank (push to talk) 23:04, 17 June 2016 (UTC)

There's a challenge to this closing statement at WP:AN#WP:VPP#Closing; I would welcome any comments there, and I try to be responsive to any challenge. It's roughly along these lines: that I wasn't the right person to do this, that the closing statement is inadequate because it doesn't reflect the opinions of the voters and the hard work they put in, and that "inconclusive" isn't an answer (and if it is, then it means "no consensus", which is not supported by the facts).

  • Maybe I'm not the right guy for this ... who knows? But that part of the challenge doesn't seem to be getting anywhere at WP:AN.
  • I didn't reflect all the voters' rationales in my close because
    • Anyone can read the RfC; you don't need my interpretation of it;
    • Over the years that I've been closing RfCs, I've found that not many people read very long closing statements;
    • The next RfC will probably cover all of these points and more; and
    • It wouldn't be helpful to focus on things that a few people said. The next RfC will probably have many more voters arguing these issues from all sides; if so, that will present a more complete picture, and that's where the focus needs to be. Having said that, some of the voters' rationales were quite enlightening, and I recommend reading all of them, Sarah's in particular.
  • I'm comfortable calling this "no consensus". The key is that "opt in" and "opt out" probably meant at least three or four different things to different people, and you don't have a majority for one position if people are voting for different things, even if they use the same words. The only way we'd know for sure would be to survey everyone who voted, and that would cause a lot of uproar for no gain at all. This point was raised by Rexx right at the start, the point was never rebutted, and I got the sense that the "opt out" voters generally agreed with Rexx on this point. The usual meaning of an "opt out" feature on Wikipedia is one that is automatic, that users have to affirmatively turn off if they don't want the feature. Some voters may have been influenced by this usual meaning of the term ... and who wouldn't vote against that? But Wikidata fields don't just sprout automatically, someone has to choose a template that uses Wikidata fields, and it has to survive the editing process. And there's more confusion: at WP:AN, User:WhatamIdoing finds "a significant fraction of editors disagreeing about whether "opt-in" or "opt-out" means "each template, case-by-case", "each parameter, case-by-case", or "each article, case-by-case"." Also, the tone of the RfC changed as it progressed, so that "opt in" was less likely to mean "I'm in favor of having the gadget work a certain way" and more likely to mean "Ugh, Wikidata is awful". We can't assume that all the early "opt in" voters would have voted the same way if they knew that's where the discussion was leading. In short: IMO I had good reasons for making the call that I made. - Dank (push to talk) 21:26, 18 June 2016 (UTC)

Copying here what I said at WP:AN: This is getting personal enough that it's probably time for me to recuse myself from the discussion. Several points made [in the latest discussion at AN] are just wrong. I won't be participating in or closing any future discussions about infoboxes or Wikidata, if that helps. Best of luck. I understand that it's easy to lose track of what's been said when you care about about what's at stake. Someone please ping me when the discussion is over, or when someone evaluating the discussion needs my input. Unwatching. - Dank (push to talk) 22:02, 19 June 2016 (UTC)

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

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

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

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

The above is a biased presentation of the issues in contravention of WP:RFC, which requires the filer to "include a brief, neutral statement of or question about the issue". It is untrue that "such data will be included in Infoboxes by default if such data exists, and it will be included silently, without any notice on people's watchlists" and it is also untrue that "such data can be excluded only by including an empty parameter: e.g. "|isbn=". If the parameter is absent (rather than empty), inclusion of WikiData will still happen automatically." The implementation is entirely customisable by the infobox coders and can be 'opt-in' or 'opt-out', depending on what the users of the template want. --RexxS (talk) 10:38, 17 May 2016 (UTC)
Please note this. I doubt there's a credible excuse for this attempt to derail the discussion. Curly Turkey 🍁 ¡gobble! 11:12, 17 May 2016 (UTC) UPDATE: Also note this. Curly Turkey 🍁 ¡gobble! 12:05, 17 May 2016 (UTC)
There's no excuse for your attempts to railroad this discussion, either. I'll move my refutation to a "Background" section, along with your move your non-neutral commentary. Let's see if other editors are unhappy with that. --RexxS (talk) 11:23, 17 May 2016 (UTC)
I believe that this is an accurate summary of prevailing practice and a natural consequence of the previous RfC. The adopted option 4 reads, '[this option modifies] only a selected field, and only when there is no existing data in that field ... Modification to any Wikidata content in the field could be done either centrally at Wikidata, or by adding information to that field locally, which would override the data from Wikidata'. ('Selected' here means a parameter in the template that has been enabled for use with Wikidata.) Our implementation is - in fact - more conservative, allowing for an empty value to override Wikidata. Izkala (talk) 12:00, 17 May 2016 (UTC)

!Votes (Wikidata)

  • Switch to opt-in, per below. Curly Turkey 🍁 ¡gobble! 01:05, 15 May 2016 (UTC) Opt-in by default, with opt-out to be determined by consensus for individual infoboxes. When I opened this RfC, it was because Izno told me at Template talk:Infobox book that opt-out that the result of the RfC was "an 'opt-out' mechanism, not an 'opt-in' mechanism" across Wikipedia, and therefore undiscussed changes at Template:Infobox book was following the RfC. It appears that is not true—although this should be made explicit somewhere to avoid these undiscussed changes in the future. Curly Turkey 🍁 ¡gobble! 22:49, 17 May 2016 (UTC)
  • Switch to opt-in. Ruslik_Zero 08:19, 15 May 2016 (UTC)
  • Switch to opt-in. Editor participation in such additions is important for verification, appropriateness, size of infobox, etc. Peter coxhead (talk) 08:24, 15 May 2016 (UTC)
  • Switch to opt-in (mostly per below). — Rhododendrites talk \\ 12:40, 15 May 2016 (UTC)
  • Continue opt-out: it is the whole point of having structured data – every editor does not have to re-invent the wheel. Assume WP:GOODFAITH that the structured data is verified just like any other facts in Wikipedia. –BoBoMisiu (talk) 13:37, 15 May 2016 (UTC)
    • BoBoMisiu—my rationale below mentions nothing about whether the data is verified. Please respond to the actual rationale, which has nothing to do with good or bad faith. Curly Turkey 🍁 ¡gobble! 20:52, 15 May 2016 (UTC)
      • @Curly Turkey: I read what is written again. The question is "about how such data should be imported", the rationale is described by you as "editors lose control over the articles they edit", i.e. about who controls how and what data is displayed. The example of ISBN to me seems like the ideal use of structured data with little reason to exclude it. It is easier to correct structured data in a silo than to correct many articles that cascade from it. Another template that uses structured data is {{authority control}} – would your proposal also require an editor to opt-in for those kinds of templates which are not infoboxes but just as unverified? Nigel Ish's comment about Wikidata not being sourced may be a system problem or a classification problem but, just as with other content, editors can change it. –BoBoMisiu (talk) 23:02, 15 May 2016 (UTC)
        • BoBoMisiu—It is easier to correct structured data in a silo than to correct many articles' ...': again, you've misunderstood what the RfC is about. This is not about overriding what data is in Wikidata with local data—it's not about replacing the value for ISBN at Wikidata with a local value (let's assume we have no desire to do so). Nor is it about the reliability of Wikidata (let's assume it's perfect). It's about how we choose what to display, whether inclusion of each individual field should be explicit or automatic. Curly Turkey 🍁 ¡gobble! 23:15, 15 May 2016 (UTC)
          • @Curly Turkey: I think I understand, and used {{authority control}} for comparison. I think it should be automatic, i.e. continue opt-out. If it displays incorrect content than correct the wikidata. If classes of infoboxes need to exclude some wikidata, then those templates should be changed; but if instances of infoboxes need to exclude some wikidata, then it should be overridden in the instance. If the concern is editors do not see content of new or changed wikidata fields, then that is a wikidata watchlist problem. I see the difference between the data and the presentation of the data. –BoBoMisiu (talk) 23:31, 15 May 2016 (UTC)
            • BoBoMisiu: If it displays incorrect content than correct the wikidata.—the fact that you keep bringing this up shows you are still misunderstanding the what the RfC is about. We are assuming the data is correct, and that Wikidata is a good thing. This RfC is strictly about the display of this data in infoboxes. Curly Turkey 🍁 ¡gobble! 00:27, 16 May 2016 (UTC)
              • @Curly Turkey: I think I understand. I assume all structured data is a good thing; I do not assume all structured data is correct; I think opt-out should continue for presenting that data in templates, including infoboxes. If I am misunderstanding, then is the RfC about aesthetics of a larger box? –BoBoMisiu (talk) 01:32, 16 May 2016 (UTC)
                • Aesthetics would be one argument, but there are other concerns (such as: is every piece of data even appropriate for an infobox?). When I say "we are assuming the data is correct", I mean the argument to opt-in is not based on the correctness of the data—that would be an argument against Wikidata itself, which is not what this RfC is about. Curly Turkey 🍁 ¡gobble! 01:46, 16 May 2016 (UTC)
  • Continue opt-out. A better solution would be to better link to Wikidata from the infoboxes. That is the entire point of the project, and editors are not losing control over their content - they should just be filling it in elsewhere. If Wikidata was fully integrated and used properly, then we wouldn't need to re-invent the wheel for every project using the same data. This is a clear step away from that. Ajraddatz (talk) 20:02, 15 May 2016 (UTC)
    • Ajraddatz—it's not about re-inventing the wheel or abandoning WikiData. Please respond to the actual rationale, which has nothing to do with keeping data on Wikipedia separate from WikiData. Curly Turkey 🍁 ¡gobble! 20:52, 15 May 2016 (UTC)
      • I did respond to the rationale, as you had written it below. Particularly the part about editors losing control over their content, which is just wrong. I agree that there needs to be some steps towards more effective integration, but I don't think this is the way forward. Ajraddatz (talk) 23:20, 15 May 2016 (UTC)
  • Switch to opt-in: It needs editors to determine whether information in Wikidata is relevant and appropriate. What's put in infoboxes in En:Wiki needs to confirm with consensus here. As an example, consider all the fuss about whether or not the "religion" field gets filled in on biographical infoboxes. We have guidance as to when such optional fields are used. Autofilling fields means that this guidance may not be repected and could lead to problems (for example, opinions over someone's nationality or religion may differ between different language wikipedias). Also Wikidata is fundamentally unsourced and not a reliable source, while data fields on Wikidata are liable to change without warning and discussion, which can break things here (WP:Ships had problems with this - see Wikipedia_talk:WikiProject_Ships/Archive_44#Wikidata_.E2.80.93_again and Wikipedia_talk:WikiProject_Ships/Archive_46#wikidata_and_ship_infoboxes.Nigel Ish (talk) 20:20, 15 May 2016 (UTC)
  • It depends (i.e. allow for both opt-in and opt-out). For template fields which should almost always be filled in – e.g. map image in {{infobox road}}, {{authority control}} identifiers – Wikidata should be included automatically, with the possibility of an override for rare cases which do not conform (opt-out). However, if the number of exceptions is not insignificant, and they can't be worked around (by using parser functions or lua to validate if the wikidata is appropriate – e.g. to not automatically include ISBN unless the publication year is after 1970s, which would stop older books having an ISBN displayed), then it should be opt-in. (And if the data in Wikidata is garbage, or not up to enwiki standards – e.g. Nigel Ish's WP:Ships examples – then it shouldn't be included at all) - Evad37 [talk] 03:24, 16 May 2016 (UTC)
  • Continue opt-outAllow for both opt-in and opt-out, because well, it's sure going to screw up Template:Infobox road, which was designed to function this way. Or if not, at least provide an option so that individual templates do not have this new standard unwillingly enforced on them. --Rschen7754 03:39, 16 May 2016 (UTC)
  • Continue opt-out (i.e., Wikidata as default unless an infobox opts out). I'm sympathetic to the proposal, but it looks like the core issue is getting consensus on each infobox's talk page on what parameters should default to Wikidata, as it's clear that the Wikidata shouldn't light up the whole infobox, but that call is for local consensus to decide. The bigger issue right now is turning on the firehose and getting the kinks worked out—looks like we're going one infobox at a time? @Ferret, has been working on arbitrary access with {{Video game review score}}s, and {{infobox video game}} is up next. On the technical end, I hope that someone with the chops is looking into how to have watchlisting on enwp simultaneously watchlist the wikidata entry. Time is nigh for toollabs:crosswatch. czar 05:26, 16 May 2016 (UTC)
  • Continue opt-out Neither I thought on a basic level this was to be decided on a infobox by infobox basis with local consensus, and for that matter, on a field by field basis. I don't see a reason to force opt-in across the board, if the infoboxes for particular projects prefer opt-out. If a particular field causes trouble on enwiki, the maintainers of that infobox can just remove Wikidata from that field till consensus develops. In some cases, Wikidata may just never be suitable. Each infobox can decide to do things as their needs dictate, and it should be easy enough in most cases to include a single parameter to cut off (i.e. opt out) of any wikidata population. -- ferret (talk) 12:21, 16 May 2016 (UTC)
    • Changed vote to better reflect my position. Same rationale, in line with several other recent comments like RexxS and Happy5214. -- ferret (talk) 22:33, 17 May 2016 (UTC)
  • Continue opt-out: However, the method to opt out needs to be easier (as suggested) than by filling in ALL the empty params. A nice simple |wikidata=no (or similar) should suffice. As an encyclopedia, we have a duty to provide data that's both complete and accurate. Wikidata gives us this in spades, and it should be rare that we need (not want) to exclude it. Fred Gandt · talk · contribs 12:26, 16 May 2016 (UTC)
    • it should be rare that we need (not want) to exclude it—that statement needs backing up, and there's a lot more to editorial discretion that IDONTLIKEIT. There's little more to indiscriminate automatic inclusion than ILIKEIT. Curly Turkey 🍁 ¡gobble! 12:56, 16 May 2016 (UTC)
      • I didn't say it will be or is rare; Do you disagree that it should be rare? Whether we LIKEIT or not, if the (Wiki)data is applicable, verified and accurate, we should be including it (accepting what should be rare exceptions, when editorial discretion takes over). Fred Gandt · talk · contribs 14:13, 16 May 2016 (UTC)
  • Broadly, opt-out. In response to each of CT's points below:
    1. This is an issue of two things in conjunction: arcane template syntax and the rollout of Wikidata, if in fact these fields are not being filled in because of "thousands of editors" electing not to have them filled in (a claim deserving of a {{dubious}}). Once we're at the steady-state of including Wikidata, these issues will fall by the wayside due to watchlist integration and correct implementation of the links at Wikidata.
    2. "Long lists of parameters" is strawman fallacy--correct coding of an infobox prevents this as an issue.
    3. This is an issue of education and of "trying what works". Because so few templates have converted to use Wikidata, no-one has worked out the best way to deal with discovery of Wikidata (which may be a good thing? it depends on your POV). There is also work on-going on the back end e.g. with Capiunto. In the meantime, the documentation page for an infobox should be very explicit about the expectations it has.
    4. Bringing up the specifics of ISBN muddies the water of this RFC. I don't see value in discussing it here. --Izno (talk) 12:42, 16 May 2016 (UTC)
    Izno: You'd better reread strawman fallacy. As implemeted now, long lists of empty parameters are the only way to prevent these fields from being automagically filled in later on. Curly Turkey 🍁 ¡gobble! 12:56, 16 May 2016 (UTC)
    And what concrete educational plan do we have? Curly Turkey 🍁 ¡gobble! 12:56, 16 May 2016 (UTC)
    Concrete examples are "muddying the water"? Then what are we supposed to discuss? Curly Turkey 🍁 ¡gobble! 12:56, 16 May 2016 (UTC)
    Please don't interleave your comments within mine as it muddies attribution. I numbered my comments for ease of response. I have subsequently WP:REFACTORed. In reply:

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

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

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

    Izno—you're still showing an extremely poor understanding of what a strawman is. A prime example is your remark about "prevent[ing] inclusion of all parameters".
    Your accusation of disruptiveness is straight out of nowhere. What's being disrupted?
    So my 20+ good fields to your 1 bad field—huh? Please look at the example for The End of the Road I left at Template talk:Infobox book. Curly Turkey 🍁 ¡gobble! 13:57, 16 May 2016 (UTC)

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

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

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

    I don't where you get "3", and you still obviously have no idea what a strawman is. Your comments are getting less and less coherent, which makes them especially difficult to respond to. If you can't point to where I've attempted to be disruptive, then please strike the comment. Curly Turkey 🍁 ¡gobble! 14:19, 16 May 2016 (UTC)
  • Opt-in and I really like the Parameter=Wikidata idea. This keeps it clear where the data is coming from, makes it obvious and easy to remove, and if a value is incorrect it points people in the right direction for figuring out how to correct it. It's easy to include Parameter=Wikidata when a template is typically copy-pasted in in the first place.
    A good exception is something like Authority Control which normally should not include any parameters. In that case it's obvious to check the template page to figure out what's going on. Alsee (talk) 13:01, 16 May 2016 (UTC)
  • Opt-in. We had a problem recently with Wikidata at the infobox of Night (book), a featured article. Night is a book about Elie Wiesel's time in concentration camps with his father during the Holocaust. I noticed that the infobox was suddenly listing the genre as "autobiographical novel." I had left the field empty because scholars can't agree on the genre, and Holocaust deniers call it a novel in their efforts to fictionalize it. The author has strongly denied that it is a novel.
    It transpired that a Wikidata bot had lifted the genre data from the Italian Wikipedia, which does call it a novel. Because the infobox had no genre field, the addition to Wikidata caused it to be added to the English Wikipedia too. See the discussion.
    What was very annoying was that I couldn't see how to remove it, because when I looked for the words "autobiographical novel" in the article, they weren't there. It also wasn't easy to see when the change had been made; when I looked through the article history, the Wikidata addition was showing up in old versions of the article. This is caused by a MediaWiki feature to do with the way it handles templates.
    So the current situation means (a) articles are being edited remotely, including featured articles, sensitive articles and BLPs; (b) the edits are being made without reliable sources; (c) the edits don't show up on watchlists unless you watchlist Wikidata, and a lot of us don't want to have to do that, so false or unsourced material could be there for a long time before anyone notices; (d) you can't see how to remove the new material by looking at the wikitext; (e) you can't locate when the change first appeared by looking at the history, because the way Mediawiki handles templates means that old versions of the article will appear to include the new material. SarahSV (talk) 15:21, 16 May 2016 (UTC)
    • @Kusma and SlimVirgin: I keep needing to repeat myself on this: A preference to watch Wikidata edits from your local watchlist already exists (though it currently lacks integration with the "enhanced" watchlist, and there are some other bugs and kinks that need to be worked out). Please do not misinform other users, and please review your watchlist preferences to set the preference accordingly. --Izno (talk) 14:05, 17 May 2016 (UTC)
      • When I last tried, enabling that option overwhelmed my watchlist with junk, making the watchlist useless. If anyone has Wikidata enabled on a watchlist with over 1000 articles, they might like to say how it works now. Johnuniq (talk) 23:21, 17 May 2016 (UTC)
    • Separately, @SlimVirgin: regarding point e, you can review when that change was introduced at Wikidata, so arguing that MediaWiki templates don't recall the correct version of things relative to the historical page you are reviewing is something of a strawman. --Izno (talk) 14:05, 17 May 2016 (UTC)
      • An example was given of the inappropriate words "autobiographical novel" appearing in an article. The first step in tracking down how that happened is to examine the article history. A good procedure is to look at some old revisions, but that was useless because the inappropriate words magically appeared in all old revisions. What is the easy procedure for an editor to find where those words came from? Johnuniq (talk) 23:27, 17 May 2016 (UTC)
  • Opt-in per Sarah. Ealdgyth - Talk 16:59, 16 May 2016 (UTC)
  • Opt-out — must be kept in order to deliver any functionality at all. Wikidata is an international collaboration across languages, requiring editors to opt-in for each and every parameter would undermine the entire purpose of it. If templates include wrecklessly many parameters, they should instead be fixed — so as not to display useless data at all. We need to think about the future of using Wikidata on Wikipedia — and the only way to ensure that Wikidata will be useful is to continue opt-out.
    Wikidata is already being put to use is creative and useful ways in the Template:Infobox medical condition(new) at Gout — and removing this functionality from default would hinder using the amazing open source resources that can be "harvested" for simple data statements. Carl Fredik 💌 📧 18:02, 16 May 2016 (UTC)
  • opt-out per Carl Fredik rationale--Ozzie10aaaa (talk) 18:56, 16 May 2016 (UTC)
  • Opt-in. The machinery for the opt-out option is inadequate. Notably, editors receive no notification the infobox data has changed when migrating to Wikidata; they only receive notification for changes that have come after and that is only if they know to enable the display of Wikidata changes on their watchlist. Furthermore, editors might not be interested in all of the changes that are made to data on Wikidata - which are most often technical in nature - but only in those that affect the article content. To make matters worse, to hide information retrieved from Wikidata, you've got to insert a blank property in the template invocation. This is totally opaque to most people. Izkala (talk) 19:14, 16 May 2016 (UTC)
    • Striking my !vote. Per RexxS below, there's no need to force the same rule on each and every infobox. Though subtly and not-so-subtly incorrect information might sneak its way in from time to time, and though the tooling is lagging far behind, both of these issues can be circumvented through careful planning or may be reasonably deemed to be outweighed by the benefits in some circumstances. Izkala (talk) 13:24, 17 May 2016 (UTC)
  • Opt-in per SarahSV. Mike Christie (talk - contribs - library) 19:22, 16 May 2016 (UTC) Striking for now. I now think I don't understand the issues well enough for me to !vote usefully. I'll be back if/when I get to that point. Mike Christie (talk - contribs - library) 18:31, 18 May 2016 (UTC)
  • Opt-in per SarahSV. Simon Burchell (talk) 19:34, 16 May 2016 (UTC)
  • Broadly, I think that these should be opt-out, but we need an implementation such that we can force specific parameters to be empty if needed, and maintenance tools that reflect the new cross-wiki-transclusion reality. {{Nihiltres |talk |edits}} 21:00, 16 May 2016 (UTC)
  • Opt-out, let's expand the Wikidata infobox project per BoBoMisiu, Ajraddatz, czar, Izno, CFCF, and Ozzie10aaaa. Here are my own reasons -
    • Wikidata infoboxes connect all language Wikipedias. This is a big deal. This realistically will increase the reach of Wikipedia by a billion people and further establish Wikipedia (and the concept of non-profit, advertising-free media) as the dominant publication in every language that does not have an extremely wealthy publishing sector.
      I have no special loyalty to English Wikipedia, and am ready to say that English Wikipedia should make some compromises if that benefits other language Wikipedias. The compromise requested in this case is that when the feature does not work, and it usually should, then English Wikipedia contributors have to do the labor of turning it off. Turning it off should take one edit and not more than a few seconds for someone who knows how to do it. I am ready to advocate for English Wikipedia taking on this risk, because I think that usually the Wikidata content will be welcomed and because when it is not welcome, I think it will be easy to turn it off.<brCrowdsourced human contributor translation of information across languages will not be a viable way to share information cross-wiki in the foreseeable future, except for the present opportunity to share some basic data with Wikidata infoboxes. English Wikipedia can enjoy the privilege of setting standards for how those boxes will appear. Other languages will have much less say in the matter, and are likely to accept the translation and presentation of that originates from English Wikipedia choices.
  • Wikidata infoboxes increase quality control. The sort of data which goes into infoboxes will usually be more stable and have higher verification standards than typical Wikipedia content.
  • Wikidata infoboxes attract institutional oversight Portal:Gene Wiki has done this with Wikipedia articles on genes. Other institutions will follow. I think that it is reasonable and conservative to anticipate that adopting Wikidata infoboxes will attract content donations in fields of science, medicine, economics, library information, and popular media. This kind of information in the past would have cost large sums of money to create, and now expert institutions are prepared to give it away if they can identify media partners who will share the content to a large audience. What happened with Gene Wiki can happen again in many other fields. Research institutions already contact Wikipedia organizations regularly to propose data sharing collaborations. Wikipedia volunteers are important, but it is also important to establish compelling reasons for the world's experts to invest labor in the development of free public information at the direction and under the oversight of the Wikipedia community. The Gene Wiki team made fantastic and generous contributions to Wikipedia that I hope can serve as a model for what is expected of other organizations who would donate data.
  • Wikidata infoboxes follow contemporary social trends Technology commentators talk about how concepts of open data and Semantic Web will inevitably drive the development of the media that most people consume. I agree - this is inevitable. Storing basic data in a format that is machine-readable and which generates clear, uniform presentations on various Wikipedias is an option worth serious consideration.
  • Wikidata infoboxes were a major reason for the establishment of Wikidata Integration with the information presentation of various language Wikipedias was always part of the end game for Wikidata, and before Wikidata, the idea of having a shared database for shared information is an idea older than Wikipedia, the World Wide Web, or the Internet. I think that Wikimedia community culture has its own internal pressures which lead contributors to want Wikidata infobox integration. It might happen sooner or later, but under some circumstances, I expect this to happen. If anyone opposes the idea, then I think a good way to oppose would be to critique the system and call for restrictions on it, rather than to argue that it never happen. When these things get established it is much easier to write early rules than to prohibit the entire system. If anyone wants to demand some wild compromise or concession then now might be a good time to make a request.
Blue Rasberry (talk) 21:15, 16 May 2016 (UTC)
"Wikidata infoboxes increase quality control. The sort of data which goes into infoboxes will usually be more stable and have higher verification standards than typical Wikipedia content." - Really? Why? One can more easily argue just the opposite. Johnbod (talk) 18:25, 18 May 2016 (UTC)
I see several important reasons why wikidata-driven infoboxes are likely to end up being more stable and contain higher verification standards. Its easier for people to get the data right because editing by filling in values in a form is much easier than editing data inside a wikitext template. Its easier for bots to get it right for essentially the same reason. Representing data in a database rather than mangling it into wikitext will lead to fewer errors and I would argue, eventually more editors. Because it is much easier to maintain a database as a database, authorities on specific domains should be more likely to help keep data up to date - particularly via automated methods. The other aspect here is the ability to add computable reference statements to support wikidata claims that might appear in infoboxes. A lot of anti-data people complain about wikidata having many un-referenced claims. Rather than complain, how about (a) adding references and thus solving the problem and (b) helping to code templates that make use of references in deciding whether data should be rendered or not. Because the data is in a computationally amenable form, the Lua code driving the templates can take advantage of this information and perform quality control when an article is rendered. For example, a template author could decide to only show content from wikidata that had references into sources that they judged to be high quality. This quality control would be over and above that performed by other bots that focus on patrolling and verifying the content in wikidata itself. --Benjamin Good (talk) 16:29, 20 May 2016 (UTC)
There is a bright future promised in the comment above, but we have to think what we want to do in the immediate future. At the moment, most of the data in Wikidata is unreferenced, and I haven't seen any templates that make any attempt to attempt to "add computable reference statements to support wikidata claims" (although RexxS has made good progress on modules to display whether wikidata claims have references). At the moment, Wikidata cannot be regarded as a reliable source (but there might be specific areas that could be).
I dislike the fact that editors who have concerns about "wikidata having many un-referenced claims" are being lumped together in a Luddite anti-data group. I am very much pro-data, and can see massive potential in Wikidata for sharing information between different wikipedias, improving quality, and making aspects of creating articles easier - but the key word is "potential", and quite frankly, as Wikidata stands today, I don't think it is ready for mass updating of infoboxes (but there are some areas where "obvious" data might usefully be included).
We should also not forget that infoboxes are intended to be a summary of what is in the article (and that should be supported by a reference). If something is not in the article, then it needs a specific reference, or the article should be updated (with an appropriate reference).
And by the way, I've just started to have a go with Wikidata, adding some items (with references). Using the current forms is fairly painful compared with entering wikitext... I will persist though and explore bots etc... Robevans123 (talk) 18:16, 20 May 2016 (UTC)
@Robevans123: I apologize for the luddite implication. Its easy to get frustrated and start creating "us" versus "them" when anyone that is bothering to spend their spare time chatting here is very much on the same side. I guess I'm a little confused why people here seem to think that data originating in a wikidata statement without a reference is, by default, less reliable than data sitting in Wikitext infobox also without a reference (where it was likely pulled from in the first place). But, that is beside the point. My motivation is to get more knowledge out to more people - both as text and as computationally re-usable claims in a database that could support WIkipedia and many other applications with massive social benefit. The claims used in wikidata are much more valuable when they have references. Adding references to the claims that would appear in infoboxes is a very achievable goal and one that it seems would solve many perceived and real problems with wikidata in all the contexts it is and will eventually be used. Lets figure that process out and realize that bright future, it could be much closer at hand than you might think. --Benjamin Good (talk) 22:12, 22 May 2016 (UTC)
@Benjamin Good: No worries! This whole RFC is very complicated now - different threads in different sections - I've said elsewhere that the manual data in infoboxes is not as well supported by references as it should be (and by implication that this is not "a good thing"). Since the extraction of data from infoboxes into Wikidata didn't include the references (and that would be quite difficult to do - you'd need to work out which bit of text in the article supported the infobox data, and possibly, if a sentence or paragraph has two or more references, which reference to extract...), then we're not really sure how good the extracted data is.
Of course, a lot of Wikidata is from infoboxes from this Wikipedia, and so is not that likely to be re-imported as it's already there. However, wikidata from other language wikipedias is likely to be imported, and with that, again we're not really sure how good the data is.
I'm intrigued by the possibility of an achievable goal of adding references to claims. I'll stick my hand up for helping with that process! I could see that it might well be possible to create some sort of tag (with no visible output) to link an item in an infobox to the reference that applies, but that would be human-intensive (unless you've got a really smart bot?). Regards Robevans123 (talk) 23:53, 22 May 2016 (UTC)
  • Leave it up to editors to decide. We gain nothing by forcing either opt-in or opt-out on every implementation of wikidata-aware infoboxes, and we don't need petty bureaucrats telling each different group of infobox editors "You can't do it that way because the RfC decided your way is wrong." There are no wrong ways to implement Wikidata-awareness in infoboxes, because every template has a different audience with different needs and flexibility in approach is key. --RexxS (talk) 23:21, 16 May 2016 (UTC)
  • Opt-in Due to the problems outlined above. BLP specifically - there is no way an external project should be able to effectively include unsourced information in a BLP without being manually checked by a wikipedia editor first. The BLP policy actually requires that information on a wikipedia article is reliably sourced, and Wikidata does not comply with this in general practice. So any automatic inclusion currently is prohibited by policy for BLP's. I would not object to it being opt-out if the opt-out method is made a lot easier. The previously mentioned 'wikidata=no' parameter being one option. Only in death does duty end (talk) 11:01, 17 May 2016 (UTC)
  • Continue opt-out and increase use of Wikidata material as much as possible, per RexxS, Blue Raspberry and other clueful contributors. The WP:OWNership and "not invented here" displayed in this debate by those opposing such progress is lamentable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:13, 17 May 2016 (UTC)
    • Insulting half the editors voting here by claiming they are not 'clueful' and accusing them of ownership and NIH issues is neither constructive, civil, and is a personal attack. Address the arguments rather than attacking the editors. Given your previous repeated sanctions regarding infoboxs, you are more than aware of the requirements here. Only in death does duty end (talk) 13:24, 17 May 2016 (UTC)
  • Opt-in – I encourage everyone commenting here to read this Signpost article. The key sentences are these two: "Half of all statements in Wikidata are completely unreferenced. Close to a third of all statements in Wikidata are only referenced to a Wikipedia." Once you read that, it's clear how problems like Sarah's pop up. Sorry Andy, but whether we invented it or not isn't relevant in my mind. The concept of Wikidata is noble and I'm rooting for the site's success, but my interest here is in making sure that the English Wikipedia isn't disrupted by the addition of unsourced/false information that we won't be able to track unless we commit ourselves to being active on another site. I feel like this site is being pushed on us a few years before being "ready for prime time", as it were. At a minimum, I encourage supporters of opt-out to consider a "wikidata=no" parameter, as discussed above, to make opting out easier. Giants2008 (Talk) 13:22, 17 May 2016 (UTC)
  • Continue opt out but try to find solutions for the problems explained by Sarah. For example, can we make any template that relies on Wikidata visibly state that it relies on Wikidata, at least until we are all used to it. Or make a preference "automatically watch Wikidata items for articles I watch". —Kusma (t·c) 13:27, 17 May 2016 (UTC)
    • There is, see your watchlist preferences for "Show Wikidata edits in your watchlist". If an article on your watchlist has its corresponding Wikidata updated, it will appear in your enwiki watchlist. -- ferret (talk) 14:11, 17 May 2016 (UTC)
      • ferret: That works only if the data is new (and editors happen to know there's such a box to check and don't mind having their watchlists flooded with Wikidata changes). If a change is made to the Infobox to add another field for importation from Wikidata, and the data's in Wikidata, then it won't show up on people's watchlists. Curly Turkey 🍁 ¡gobble! 14:15, 17 May 2016 (UTC)
      • Thank you. Too bad it doesn't work with "enhanced recent changes". —Kusma (t·c) 14:21, 17 May 2016 (UTC)
  • Continue opt-out, or it's kind of pointless. The Night (book) case is a trivial error, and there are solutions for this (e.g. including the parameter, with an HTML comment that it's blank on purpose, in this case because the sources conflict). One problem cropping up, that people unnecessarily wrung their hands off about is not a good argument against stymying the rollout of major functionality. Yes, there will be kinks, as there always is when we do something new, and we always work them out. Business as usual.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:03, 17 May 2016 (UTC)
  • Leave it up to editors to decide With Rexx on this one. We do not need all infoboxes to act the same. Different boxes may benefit from different functionality. Doc James (talk · contribs · email) 16:28, 17 May 2016 (UTC)
  • Opt-in: per WP:V. Ed [talk] [majestic titan] 18:34, 17 May 2016 (UTC)
I don't follow — how? Carl Fredik 💌 📧 19:14, 17 May 2016 (UTC)
@The ed17: Do we need a citation to prove that California is a state in the United States? This is where a blanket "per WP:V" doesn't really work. --Rschen7754 00:50, 18 May 2016 (UTC)
If you want to talk geographically, yes. Not for California specifically, obviously, but Crimea? South Ossetia? Etc. Ed [talk] [majestic titan] 03:12, 18 May 2016 (UTC)
Or that File:California State Route 78.svg is a map of California State Route 78? Which is a particularly good use case, as it allows for maps to easily be shared across the different languages of Template:Infobox road. Just because there are some problematic cases doesn't mean we have to prohibit the uses that are actually working. --Rschen7754 05:35, 18 May 2016 (UTC)
Thank you, that's a great argument for opt-in. ;-) Ed [talk] [majestic titan] 18:19, 18 May 2016 (UTC)
How so? When opt-out was turned on for Infobox road, we immediately gained several road maps that enwiki did not have, mainly on roads in countries where English is not the first language. This is an easy way to counteract problems with systemic bias. And you want to prohibit this? --Rschen7754 00:17, 19 May 2016 (UTC)
"Opt-in" doesn't "prohibit" anything. Curly Turkey 🍁 ¡gobble! 00:23, 19 May 2016 (UTC)
It would prohibit the automatic inclusion of such maps, which is the real benefit here. --Rschen7754 00:44, 19 May 2016 (UTC)
It's a perfect argument for opt-in: "Just because there are some problematic cases doesn't mean we have to prohibit the uses that are actually working." There are problematic cases, so we'll opt-in for the uses that are actually working. Ed [talk] [majestic titan] 17:43, 19 May 2016 (UTC)
No, in fact it's not. Also it entirely defeats the purpose. Having it opt-in by default is the same as saying we shouldn't use it. There is no benefit to be gained if the opt-in needs to be manually performed, then it is not only useless, but a waste of time and money. Carl Fredik 💌 📧 17:48, 19 May 2016 (UTC)
I think you're referring to opt-in by template. However, this proposal as written is for opt-in by article, which would prohibit the uses that are actually working. --Rschen7754 18:31, 19 May 2016 (UTC)
I think also one of the issues here is that we aren't really clear about what Wikidata should be used for — some properties are simply poorly situated for relying on Wikidata, they shouldn't be included in templates/infoboxes at all, genre comes to mind. Carl Fredik 💌 📧 19:42, 19 May 2016 (UTC) 
  • Neither - We don't need a project-wide policy on this. Individual WikiProjects can and should establish local consensus for their own infoboxes. Imposing so-called "opt-in" or "opt-out" mandates on all infoboxes does a disservice to Wikipedia. -happy5214 22:30, 17 May 2016 (UTC)
  • Continue opt-out per BoBoMisiu: centralization and importation form almost the entire benefit of Wikidata, and it would be incredibly short-sighted to undermine that. Whatever issues arise with verification can be addressed narrowly as they arise, and will largely be obviated as the editor base becomes more familiar with the idea that factual statements are increasingly centralized. Already, users can opt for their watched Wikidata pages to appear on their Wikipedia watchlist; I think that under-recognized capability has a huge impact on the rationales for "opt-in" given here. —swpbT 13:30, 18 May 2016 (UTC)
  • Opt-in per SV and others. Johnbod (talk) 18:25, 18 May 2016 (UTC)
  • Opt-in per the above discussion. Carrite (talk) 18:46, 18 May 2016 (UTC)
  • Opt-in by default. I saw the discussion at Night (book) when it occurred and it concerned me. The issue is this: a Holocaust survivor writes an important and notable book that can't be identified as a specific genre because of its content and the author's intentions. That the genre was left blank in the infobox and then later the field filled in with an incorrect genre might seem trivial, but it's not trivial, because in this case it brings into question whether the author is writing a fictional account of a fictional event (the Holocaust) or not. This is not an issue of ownership but rather an issue of good stewardship of our content, and unless there's an easy way to see that the change was made (yes, there's the watchlist button, but what if someone isn't logging in every day?), then The ed17's comment is correct. We need to be certain elements in infoboxes are verified and that's difficult if the changes are being made remotely. Victoria (tk) 20:02, 18 May 2016 (UTC)
  • Opt-out In the rare cases where we shouldn't have info (like the genre of Night), we should have to make it clear we don't want the info, rather than having it left out when it's available automatically. Jackmcbarn (talk) 18:36, 19 May 2016 (UTC)
  • Opt-out, however I am sympathetic to the arguments of Sarah and others. Perhaps GA's and FA's should be opt-in by default, because we can assume that they are sufficiently maintained. however, especially on less-edited articles, wikidata updates in a clear net positive for the wiki as a whole. If technically feasible, wikidata updates should be noted in the page histories of the affected pages. Tazerdadog (talk) 22:50, 19 May 2016 (UTC)
  • Opt-in per SV, Curly and others. Resolute 23:06, 19 May 2016 (UTC)
  • Continue opt-out per BoBoMisiu, although I read Sarah's argument about Night. I agree with others that making Wikidata opt-out partially defeats the purpose of including Wikidata in the first place. APerson (talk!) 00:54, 20 May 2016 (UTC)
  • Continue opt-out --Nouill (talk) 06:24, 21 May 2016 (UTC)
  • Opt-out, with a couple of caveats. I would like to see the option of having an infobox include Wikidata values for parameters by default, but only if they are supported by a reference at the Wikidata end. Unreferenced data from Wikidata would not appear in the infobox. That would have a couple of benefits: it would prevent a huge initial flood of uncited (and possibly incorrect) data being added to infoboxes across the wiki; and it would lead in a natural way to an effort to improve referencing on Wikidata, rather than focusing on simply loading it up with more data. This wouldn't prevent all instances of incorrect data appearing suddenly in an infobox with no notice to the article editors, but it would surely eliminate most cases. To SarahSV's comment that she couldn't see how to fix the problem I would say that I sympathize, but that that's a one-time technical problem for each editor -- we all had to learn how to italicize an article title or indent a blockquote for the first time, and once we've learnt it it's part of our toolbox. This seems the same to me. If it turns out not to be technically possible to limit the use of Wikidata in parameters to ones supported by references, then I would still support opt-out. I have been mostly ignoring Wikidata for the last couple of years, and finally learned a little more about it this week, prompted by this RfC (and thank you, Izno, for answering my questions about it) and I can see why some people are arguing that anything but opt-out makes a mockery of the idea of Wikidata. That doesn't eliminate the problems it causes for content editors, as described by the opt-in supporters above, but I think we're going to be obliged to figure out how to deal with those problems, and we might as well start now. Mike Christie (talk - contribs - library) 10:48, 21 May 2016 (UTC)
  • Opt-in, per Giants2008 and Sarah, due to systemic Wikidata verifiability issues. Regards, James (talk/contribs) 22:15, 23 May 2016 (UTC)
  • Opt-in by default per all of Sarah's and Giants2008's arguments which are also mine. A box's parameters are often an editorial decision, both what to put in the parameters and what parameters to use. Some parameters are excluded because the "factoid" is cluttering trivia or not as straightforward as it seems and is better explained in context to avoid misleading the reader. Even when including data in a box, editors (you know, those humans who actually write Wikipedia) often have to make an editorial decision on what is the best available source to go with when different sources disagree. More importantly, there is a lot of incorrect/dubious information on Wikidata and it's sometimes buggy, and no, it is not easier to edit than the standard manual infobox in Wikitext. I tried to correct information on Wikidata Q3107911 for Giulietta Pezzi. I clicked on the sidebar link from the English Wikipedia and the whole Wikidata page (apart from the statements, I think), the directions, help links etc. were all in... er... Bengali. I see that was eventually fixed, but it is not straightforward to edit at all, even when it is in the correct language. At the very least make it incredibly easy to opt out. By the way, I have over 4000 articles on my watchlist of which well over 1000 are important to watch for changes. So no, I am not going to add Wikidata changes to my watchlist. Voceditenore (talk) 09:49, 24 May 2016 (UTC)
  • Opt-in at least on a per infobox level, with clear instructions at the infobox template for how to over ride it on a per article basis. Folks representing WIkiData in this discussion are pretty much doing and saying exactly the kinds of things that only deepen the concerns of editors concerned about verification and manipulation, which is unfortunate. In any case at this point I believe that entry of WikiData needs to be carefully controlled. It is potentially a great tool but until more of an effort is made to a) show that WikiData is well-curated and b) that an opt-out approach really will result in a big net win over the inevitable downsides, it should be opt-in. Jytdog (talk) 21:23, 24 May 2016 (UTC)
  • Opt-in: let the editor decide, as is always my position on these forced intrusions. Wikidata and infobxes can be two large allergies to me (sigh...) Fylbecatulous talk 13:31, 25 May 2016 (UTC)
  • Opt-in, but with the intent of changing this down the road. The ability to use WikiData in infoboxes is a powerful tool, but one few people on Wikipedia understand how to use. SlimVirgin's example above illustrates that: SV is a veteran editor, & when someone like SV can't figure out how a feature of Wikimedia works in a reasonable fashion, then how will the newbie editor for whom VisualEditor was targeted? Making it an opt-out -- without any documentation or explanation what will happen -- will not only frustrate veteran editors, it will discourage the newbies & make the experience worse for everyone. (And before someone says that they can modify the infobox template to provide this documentation, may I remind everyone that templates are still a ramshackle mess, which the PTB still haven't managed to tame. Many are not only undocumented, but I doubt anyone even has a handle on how many there are. I've been editing Wikipedia for longer than most of you, & I still follow the instructions slavishly when I add images to an article. Templates are that messed up.) But to repeat myself, WikiData has the potential to be a powerful tool. If its potential & use is introduced properly I can see us all in a few years wondering how we managed without it. What is needed is for its advocates to figure out a way to introduce them to the rest of the community so that we can understand how to implement its power -- not flip a switch & wish us luck. And setting this to "opt-out" is flipping a switch & watching us learn the hard way what "rm -rf *" does to a computer running Linux. -- llywrch (talk) 22:27, 25 May 2016 (UTC)
  • Neither this should rely on local consensus. The infobox editors and people close to the field know what is likely to be on wikidata and what's useful to include by default. My second preference is keep opt-out for numerous reasons above, but mostly that turning it to opt-in seems like it will make the previous consensus moot. If I have to figure out what's on wikidata and put the info in, why not just copy and paste the data already there? If we're going to use wikidata, we might as well use wikidata. Wugapodes [thɔk] [kantʃɻɪbz] 15:29, 1 June 2016 (UTC)
  • Continue Opt-out practice - The whole point of wikidata is to improve articles across all languages in this manner. Now, I'd also like to comment on people's !votes for "allow the editors to decide"... this already appears to be the case. Wikidata is only going to be automatically entered into certain templates, not every template that exists, and so editors can clearly decide whether or not wikidata should be used for any given template. I see these !votes as moot, unless you had another meaning? Fieari (talk) 03:55, 2 June 2016 (UTC)
    • @Fieari: Such !votes (and "neither" and "both" !votes) are about not forcing there to be a single way Wikidata can be used across all infobox templates – i.e. allowing individual templates, based on local consensus, to either (a) use Wikidata through an opt-in mechanism, (b) use Wikidata through an opt-out mechanism, or (c) not use Wikidata at all. As opposed to an "opt-in" or "opt-out" !vote, which would allow only (a)&(c) or (b)&(c). Also pinging @RexxS and Doc James: who !voted "Leave it up to editors to decide" - Evad37 [talk] 13:03, 2 June 2016 (UTC)
  • Opt-in by default, on a per-template basis. By this I mean that new and existing templates should not show any field from Wikidata that the template creators haven't explicitly given permission to appear on the article. I sympathize with the people who say not showing Wikidata's content by default defeats its point, and I normally would side with opt-out for that reason; but I think that Wikidata is simply not ready for such large-scale adoption, for all the reasons already stated by others, mainly that most content is unreferenced, and that even if all Wikidata was perfect, not all Wikidata fields should be shown at infoboxes anyway. Both are powerful arguments for hiding data by default and show it only after its explicit approval (either at each article or for a full template that allows it).
We need a slow and steady approach to deployment, rather than a "dump everything we got and we'll figure out how to fix it" one. When the WMF tried to force upon us the adoption of much simpler tools, the backlash was huge; why should we treat Wikidata any smoother?
We're talking about a tool that most of us don't know how to use, resembles anything like mediawiki, and which can silently push unreferenced content within articles that might not even be watchlisted by anyone. And frankly, the tool seems too immature to be comfortable for everyday use and massive adoption; every time I've tried to accomplish anything with it, trivial or not, it has been a pain in the ass. So please let's take a more conservative approach and enable it for smaller data sizes at a time.
WP:BLP alone would be a good reason to veto the opt-out behavior; I add to this that the WP:BURDEN of including content in articles falls onto those who want to include it, and there are good arguments challenging the verifiability of most content in Wikidata. I could agree to be more lenient with Wikidata content that can be shown to be referenced; I think the best way to allow it would be with some kind of "when_referenced=param1,param2..." parameter in templates that works like "fetch content from these fields for articles where its data has references, and hide it when it doesn't". I think this would grant maximum flexibility as RexxS suggested, without compromising the core WP:V policy. And incidentally, it would encourage Wikidata users to source as much data as possible, since unreferenced data would be invisible for all purposes (as it should be). Diego (talk) 10:21, 6 June 2016 (UTC)
  • Let the curators of each infobox decide. But if debates escalate, let's say we prefer opt-out (use Wikidata by default). I see the disputes above as a feature, not a problem of Wikidata - it encourages editors from different Wikimedia projects to talk to each other and agree on as much common ground as possible. But of course, sometimes common ground cannot be reached (e.g. disputed territories), and in this case the problem should be solved by article-specific overrides of entries from the infobox. Deryck C. 11:37, 10 June 2016 (UTC)
IMHO, opt-out by default is the fastest way to train readers to think "Wikidata information is garbage". If we start pushing unverifiable data into the limelight, eventually someone will be bitten by it; it just take a high profile case to spread the idea that Wikipedia infobox data can't be relied upon, and that there's no way you can check that the data is valid or not.
This problem has not been severe at data from infoboxes so far, since the same article displaying the data ideally had the references included at the end; and if it doesn't have them, at least you can see such lack of sources.
But here we're proposing to start showing everywhere the data randomly gathered from any Wikipedia, regardless of their quality standards, with no way for users to check the proces by which such data has been compiled. I'd say that no data is way better than wrong data that has been published with no validation process at all. Diego (talk) 15:29, 10 June 2016 (UTC)
  • Definitely opt-in, simply because it's more trouble than its worth and has next-to-no benefit for the English Wikipedia itself. Much of the arguments for Wikidata rests on that it helps out a) Wikidata itself and b) other, lesser-used Wikimedia projects linked to by Wikidata; but the English Wikipedia community is under no obligation to support these other projects, especially when such support is likely to undermine this very project; it's akin to shooting oneself in the foot. Much of what User:SlimVirgin said above hits the nail on the head, especially this part:
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
The English Wikipedia has several times the viewership, several times the editor base, and several times the oversight when compared to Wikidata. Thus, it's simply the safer place to store such information. It wouldn't be in our best interests to jeopardise this. Satellizer el Bridget (Talk) 02:28, 11 June 2016 (UTC)
  • Leave it up to editors on a case-by-case basis. (I was unaware there was an actual policy on how to add Wikidata access to infoboxes. Is there one?) For most less-used infoboxes (e.g. telescope, saxophone, Quidditch association, tree…) Wikidata would be easy to implement, but for heavily-used infoboxes (person, road, taxobox, book, station…) Wikidata would have to be enabled for each page individually because of the current unreliability (or, sometimes, lack) of Wikidata data. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 04:11, 12 June 2016 (UTC)
  • Opt-in Doesn't improve Wikipedia in the least. So Opt-in please. KoshVorlon 15:17, 14 June 2016 (UTC)
  • Opt-in. There are certain infoboxes where automated importing from Wikidata will be of great value, but there are far more where this will be problematic. We intentionally don't populate every field in an infobox even when we have impeccably-sourced data, to prevent foot-long boxes; just because {{infobox person}} contains a salary field, doesn't mean we necessarily want to state the person's salary if it's not relevant to the article, even though this can often be easily sourced. Opt-out would force editors to manually monitor articles and constantly prune infoboxes to prevent factoid-proliferation; as far as I can see, those supporting an opt-out position are arguing to make editing substantially more difficult for the majority of en-wikipedia editors (and by extension editors on other language wikis as well, since changes made here tend to propagate), for the purpose of making editing very marginally easier for the small minority of editors who not only consider Wikidata a worthwhile exercise, but have the time, inclination and technical ability to work on it. ‑ Iridescent 15:32, 14 June 2016 (UTC)
  • Opt-in based on local consensus at the article level. Wikidata has far too many systemic verifiability and circularisation issues. SarahSV makes some good points, as does Iridescent. - Sitush (talk) 16:30, 14 June 2016 (UTC)

Rationale (Wikidata)

  • Lots of problems:
    • Many editors leave out these fields deliberately—silently filling in these parameters overrides the decisions of potentially thosands of editors without even letting them know.
    • Many infoboxes have long lists of parameters, many of which are redundant. Keeping an infobox compact would mean loading up the source with parameter after empty parameter, cluttering up the source and making it more unfriendly to large numbers of editors, particularly new ones.
      • This is a particular problem with newly-added parameters—as most of us can't afford a crystal ball, we can't possibly predict all the parameters we should exclude.
    • To most editors, if data such as the ISBN appears in an infobox without being specified, it's not in the least obvious why it displays or how to suppress it. Most editors are unaware of the Template namespace, and even if they are aware, may not be able to guess the name of the parameter they want to suppress.
    • Many parameters may not be appropriate for infoboxes, for example ISBNs or page counts for books that have many editions, ISBNs for books first published before ISBNs were introduced in 1970, or clutter like Dewey Decimal numbers, etc.
  • In short, editors lose control over the articles they edit, without even realizing it has happened. A better option would be to make this all opt-in, specifying only the parameters to be included, via something like "|isbn=yes" or "|isbn=WikiData". for those who want complete autofillin, perhaps something like a "|WikiData=all" or "|autofill=yes"—an option that perhaps opens the door to specifying particularly common subsets, as well (for example: "|autofill=minimal" for a bare-bones box). Curly Turkey 🍁 ¡gobble! 01:05, 15 May 2016 (UTC)
  • There's no evidence that lots of editors leave out many fields deliberately. This is just anecdotal hearsay. Until we have a means of ascertaining the extent to which fields are intentionally suppressed, this issue should not become a barrier to progress. Template:Infobox telescope has many fields that automatically populate with the Wikidata values when the parameter is omitted, and I've not seen a single complaint yet that editors have lost control of their articles. it's been so successful that astronomy editors in Lithuania are adopting it for use on their wiki. I don't doubt that there are other topics where that approach won't work as well, but I'm firmly opposed to telling the editors like Mike Peel, who have worked really hard on creating that infobox template, that they can't implement their infobox that way, because this RfC - populated by editors who have never touched Template:Infobox telescope - may decide that there's only one proper end to crack a boiled egg. --RexxS (talk) 23:44, 16 May 2016 (UTC)
    • There's no evidence that lots of editors leave out many fields deliberately—there's plenty of evidence in the years-long disputes over infoboxes—there's nothing anecdotal about it. What's unenlightening is cherrypicking Template:Infobox telescope, with 184 transclusions, versus Template:Infobox book, which has 37,393, which doesn't include articles that don't even use an infobox, such as the FAs The Sun Also Rises, Mary: A Fiction, and The Monster (novella). Curly Turkey 🍁 ¡gobble! 03:40, 17 May 2016 (UTC)
      • There's no need to barrack every editor who presents a different view from yours - your motivations are transparent. Half the comments in this RfC are from you and you need to back off. There really is no evidence beyond your unsubstantiated claim, so I challenge you to give the diffs of where you can show that the "thosands [sic] of editors" intentionally left out fields from an infobox. I also don't appreciate the 'cherry-picked' ad hominem. Template:Infobox telescope is one that other editors have worked hard at, to create a working example of a wikidata-aware infobox, and you do a disservice to their efforts by belittling them. Their work is no less valuable because it's only used on a few hundred articles. --RexxS (talk) 10:28, 17 May 2016 (UTC)
        I can't provide evidence of thousands of editors, but I can certainly give you one. I've worked on a lot of magazine articles and articles about Anglo-Saxon kings. These have fields that seem logical but often need to be left out; for example, there's a "frequency" field for magazines which shouldn't be used if the magazine did not conform to a single frequency for the great majority of its existence. And take a look at Ælle of Sussex; almost nothing is known about him, and I would guess that very few of the available fields have accurate information available. People add this sort of thing to these infoboxes periodically, though; if you want I can find some examples by trawling through article histories, but please take my word for it. My concern with opt-out is that I want to know when an article I've been editing has its quality degraded so I can fix it. If watchlist mechanisms existed to alert me to this, I think that would address my objections, but as far as I can tell they don't. Mike Christie (talk - contribs - library) 10:37, 17 May 2016 (UTC)
        • @Mike Christie: I don't doSubt that there are numerous occasions where an editor has deliberately chosen to leave out an infobox parameter. I want to know if this happens most of the time, so that it makes sense for us to treat by default an omitted parameter as one that has been intentionally suppressed. I simply don't believe that is the case. If you are watching an existing article with a Wikidata-enabled infobox, then it makes sense to untick the "hide Wikidata" box in your watchlist. Any changes to that article's statements on Wikidata will then show in your watchlist. Those changes are much less frequent than changes on Wikipedia, and are clearly marked with a D. --RexxS (talk) 13:27, 17 May 2016 (UTC)*
          I've unhidden the Wikidata changes on my watchlist and will try to get a little more familiar with the way it works; if what you're saying turns out to be correct I may change my !vote, though I think somewhere above someone said that even unhiding Wikidata changes does not always show you a change that can affect an article on your watchlist. Incidentally, just as supporting evidence for my comment above, see this, from a couple of minutes ago. Mike Christie (talk - contribs - library) 17:42, 17 May 2016 (UTC)
          • Mike: In the context of this RfC, the problem may arise if a normal infobox is changed (I'd say upgraded) to a Wikidata-enabled infobox. At that point, the display in each article using the infobox has the potential to draw in additional information from Wikidata without that additional information showing on the watchlists containing those articles (subsequently, any changes to Wikidata will show on watchlists as D and will be spotted). The problem can only happen if the infobox implements a scheme where it fetches Wikidata for fields that are not already filled-in an article - the so-called "opt-out" scheme. Most of the time it is likely to be something obscure like an OCLC number that nobody will worry about, but Sarah gives an example of where she had deliberately omitted the genre field as problematic, but the Wikidata-enabled infobox re-inserted it without warning. It's a genuine concern, but banning 'opt-out' schemes wholescale in response is using a sledgehammer on a walnut. Infobox template editors will need to implement fetching Wikidata values carefully when they upgrade infoboxes. Where the number of transclusions is small, it should be sufficient to monitor the effect on the affected articles, so using an 'opt-out' template should be manageable. Where the number of transclusions is larger, I'd recommend using a more flexible implementation, for example like the demo at Template:Infobox book/Wikidata/Sandbox, which only fetches Wikidata when that is specifically enabled on an article-by-article basis by adding a |fetchwikidata= parameter. Since that also allows fetching Wikidata on a field-by-field basis, if required, it should enable editors to make use of it in their articles in the manner they choose. The bonus is that it can also suppress any field(s) with a |suppressfields=, so Sarah could explicitly ensure that 'genre' was never displayed in Night (book) by adding |suppressfields=genre. Sorry to be so lengthy, but you raise important issues that need consideration. --RexxS (talk) 18:32, 17 May 2016 (UTC)
            • RexxS, what happened at Night illustrates the problem with the current position. First the generic infobox was replaced with Infobox Book by Frietjes and Bgwhite over my objections. [1][2] Then Freitjes changed Infobox Book, without discussion, so that it fetched data from Wikidata. [3] In the meantime a Wikidata bot had fetched the genre from the Italian Wikipedia, [4][5] which calls Night a novel. (This is odd because the Italian Wikipedia is a translation of the article I wrote for the English Wikipedia, which explains that scholars can't decide on the genre and that Wiesel insists it isn't a novel.)
              So at each point of this process, people not familiar with the issues were deciding them. Everything that keeps Wikipedia safe – the watchlists, the featured-article process, the concept of stewardship, the ability to track changes by studying the history of articles – was bypassed. SarahSV (talk) 03:11, 18 May 2016 (UTC)
              • Yes, Sarah, I do understand the problems you encountered and I sympathise. What if we were to make available a scheme where generic infoboxes could be replaced with wikidata-enabled ones, but they would not fetch anything from Wikidata unless an extra parameter like |fetchwikidata=list; of; fields; to; fetch were added to each article to enable it? And if we gave editors the ability at each article to suppress one or more problematic fields in all circumstances by adding a parameter like |suppressfields=genre, so that they would never display? Do you think that would give you sufficient control at the article level to be able to steward the articles in the way you are comfortable with? If not, what else might you need to do that? I'm happy to try to find solutions if you can give me specifics. Cheers --RexxS (talk) 14:00, 18 May 2016 (UTC)
                • This looks like an eminently sensible and useful proposal. It still doesn't resolve the questions I raised below concerning how the data being imported from Wikidata is backed up by a reference from a reliable source. Is it possible to include a comment after the imported data giving the reference for that data? I took a look at the wikidata item for the Large Hadron Collider and found a number that were unsupported by any reference, a few that were imported from other (and English) Wikipedias (possible danger of circular references here), and one (discovery) supported by a link to the CERN website. If this was included in the comment, then it would be easy to check the source, and relatively easy to add a reference, and possibly include the data within the article. Robevans123 (talk) 18:05, 18 May 2016 (UTC)
                  • @Robevans123: Well, the information we get out of Wikidata is only as good as the information that's put into it, and there are about 15,000,000 items there now, most of them imported by bots from infoboxes on the various Wikipedias. Of course, infoboxes are notorious for not displaying references (it's only a summary of the already-referenced article, right?), but it does leave a huge number of statements on Wikidata unreferenced. If I were to write a demo function that fetched any references, if present, and put them inside an html comment after whatever value is retrieved from Wikidata, do you think it would be used to help populate the missing references, or just as a blunt tool to bludgeon folks out of using Wikidata at all? --RexxS (talk) 18:46, 18 May 2016 (UTC)
                    • @RexxS: Well, in suggesting it I had hoped that it would be to help populate the missing references, but I can see that it could/would be used as a bludgeon. But then that might be justified... In my (limited) experience of actually checking data in infoboxes when I've expanded articles (often using {{infobox locomotive}}) I would say that ~5% are wrong, and often that more than 50% are not supported by anything in the text or referenced directly. And I've come across some that were wrong and claimed to be supported by a reference that did not have that amount of detail...
So, there is a problem with data in infoboxes. Do we then ignore the problem and decide to make it even worse? Or do we try and fix it? BTW while I was still a bit of a newbie I added refs to each parameter, but it was suggested that a few refs might be ok, but generally it would be better to have text in the article as the purpose of an infobox is primarily to be a summary of the article. Since then, I've only added parameters to an infobox if the info is in the article.
Just had a go at adding a date of death to Charles Spagnoletti on Wikidata. It's a bit long winded - would be nice to be able to easily copy a ref and re-use it, eg for date of birth...
As things stand if anyone wants "to bludgeon folks out of using Wikidata at all", then they can remove anything from an infobox that comes from Wikidata on the basis that it is unsourced... Robevans123 (talk) 20:14, 18 May 2016 (UTC)
If anybody wants to make a start on improving referencing at Wikidata, I've made a first draft of a tool you can paste and preview into an article that will show you which Wikidata claims are referenced and to what. It's at Module:Sandbox/RexxS/WdRefs. Let me know if you find any bugs or want any improvements. --RexxS (talk) 16:02, 19 May 2016 (UTC)
RexxS, thank you for your suggestions. The problem with |suppressfields=genre is that we would need to add it for all the missing fields; otherwise we're leaving open that a Wikidata bot might grab something wrong from another wiki. Another problem is that a small group tries to force these issues, which is why Night happened, so they would go around removing |suppressfields=. I would rather see separate Wikidata-enabled boxes, then editors can use them if they choose to, along with a "first major contributor" preference in case of dispute. SarahSV (talk) 15:16, 20 May 2016 (UTC)
Sarah, You would only need to add |suppressfields=genre; date_of_pub; isbn to suppress three fields and you'd only have to do it once. Surely that conveys your intention better than the present situation where you have no means other than an html comment to inform other editors that they should not be adding those fields manually? If you have a small group going around trying to push the 'genre' parameter, then they will add it, whether it comes from Wikidata or is added manually. If we have a separate Wikidata-enabled box, you'll simply move the locus of the dispute to an edit war over which box to use. That is principally a behavioural issue and needs dispute resolution in any case. It is very harsh to preclude Wikidata awareness to try to circumvent a problem not actually caused by using Wikidata. In addition, I'd strongly recommend against arguing for any "first major contributor" preference. That was only ever meant as a tie-breaker in WP:ENGVAR to decide between two equally-valued options in the absence of any clear deciding factors. The use of that principle outside of such circumstances simply stifles innovation and improvement of the encyclopedia. I've seen it used as a justification for not upgrading bare urls to {{cite web}} on the grounds that the original author used bare urls, despite the clear superiority of the template over the raw link. No, it's far better in the case of dispute to have the debate and decide whether or not an article should be allowed to fetch information from Wikidata by examining the pros and cons, rather than having "it didn't start that way" as a trump card over all other argument. --RexxS (talk) 16:07, 20 May 2016 (UTC)
You would only need to add ...—you can only add them if you know they exist. If someone adds a new parameter to a box used in 37,000 articles, how do you ensure that the editors of all 37,000 articles know that this new parameter has been added so they can judge whether it should be excluded? Someone could add |num_of_chapters=, |page_orientation=, |page_dimensions=, |binding= ... Curly Turkey 🍁 ¡gobble! 21:37, 20 May 2016 (UTC)
You misunderstand. I was suggesting a solution for Sarah's problem, which happens whether the information comes from Wikidata or through a manual addition. Adding a known field to the |suppressfields= blacklist is the way to make sure that a field is never displayed, no matter where it comes from. If you simply want to make sure that only the fields you have audited can be fetched from Wikidata then you explicitly name them in the |fetchwikidata= whitelist in your favourite article. If a new field is added to the infobox without you knowing, it still can't show up in your article until its name is added to the whitelist in the article. And if somebody alters the article's whitelist, you'll see that on your watchlist of course. --RexxS (talk) 22:20, 20 May 2016 (UTC)
  • This entire RfC is based on the flawed premise that we have to have a rule forbidding an infobox to populate an infobox from Wikidata in a particular way. This is incorrectly presented as a binary decision and the opening statement is clearly not neutral. It has become obvious that Curley Turkey wants to force his preference for what he calls 'opt-in' on the community. His 22 comments to date show no inclination to listen to the opinions of other editors - the whole purpose of an RfC - but demonstrate a singular desire to push his POV. The falsity of his opening statement can clearly be seen by looking at Template:Infobox book/Wikidata/Sandbox, a demo infobox I knocked up yesterday evening in response to concerns expressed at Template talk:Infobox book #Wikidata. It is perfectly possible to arrange for any Wikidata-enabled infobox to choose which fields are fetched from Wikidata, or which to suppress, or which will use a local parameter value - and to do that at the individual article level. Nobody needs to be forced to implement any given infobox in any particular way, and one has to be suspicious of the motives of anyone who is trying so hard to convince the community otherwise. --RexxS (talk) 13:11, 17 May 2016 (UTC)
  • When I initially read the first paragraphs of this RfC, my kneejerk reaction was to support the author, until I saw Rexx's comment, suggesting the RfC presentation was non-neutral. As editor who has never looked too deeply into the drama around infoboxes, but is aware of the deceptive tricks of WifiOne and what happened at BP to hide bias and COI, I am suspcious of the ability of editors to change any content without notice on the watchlist. I imagine other editors will have similar kneejerk reaction. So, my inclination was and is to vote Opt-In. However, Rexx makes some strong arguments against a one-size-fits-all approach not found in the question: If there is a consensus at the article for Opt-Out, that seems okay to me. So I agree with Rexx that the presentation of the quesiton is non-neutral and will lead to Opt-In !votes from people like me if they do not see Rexx's comments. I am still on the fence. What would be helpful is actual examples of articles where Opt-Out or Opt-In has or could be a problem. That would help me make a decision. --David Tornheim (talk) 13:53, 17 May 2016 (UTC)
I think RexxS' Template:Infobox book/Wikidata/Sandbox is a practical approach.
@Curly Turkey: logic can detect the difference between an expression of a work and a work. {{Infobox book}} states that first edition of a work is preferred. So if that expression of the work did not have an ISBN, then it still will have an LCCN, etc. Moreover, viaf.org also IDs a work and the expression of the work – other institutional silos likely do too.
Wikidata should be able to assert attribution for metadata from reliable institutional databases, e.g. viaf.org or loc.org or bl.uk for published works. –BoBoMisiu (talk) 15:38, 17 May 2016 (UTC)
You're working from the assumption that we should include as many fields as possible for, say, a book or a person. That's not an assumption that has consensus. Look at Wikipedia:Village pump (policy)/Archive 126#RfC: Religion in biographical infoboxes—the consensus is to exclude religion in {{Infobox person}} by default, even when there is no doubt of the veracity of the religion. There are recent RfCs that reached the same conclusion, for example, about ethnicity. These are data that might be perfectly appropriate for Wikidata, but not for an Infobox. Curly Turkey 🍁 ¡gobble! 23:04, 17 May 2016 (UTC)
Curly Turkey raises a valid point and I agree that we mustn't assume that because data is available, we have to have it in the infobox. The problem may possibly be even worse in the case he cites. If it were simply a matter of deprecating the |religion=, then we could simply remove it from {{infobox person}}. However, that RfC specifically allowed the use of the parameter in certain cases, such as in the biography of a religious leader and in others where the subject's religion is intrinsically tied to their notability. That means we need a scheme that can cater for not having a parameter displayed by default, while allowing it under closely delineated circumstances. One thing that these discussions is crystallising for me is that we sometimes really need the ability to completely suppress the display of a particular field in a given infobox by default (with an exception to allow display on a per-article basis). I know how to do this if the infobox uses calls to a Lua module, but it may take some thought on how it could be implemented using the parser functions available in a normal template. --RexxS (talk) 00:16, 18 May 2016 (UTC)
@Curly Turkey and RexxS: no, I am assuming nothing about what should be mapped into infobox fields or how many should be presented to the reader. There are several interconnected topics being discussed, among them: the availability of wikidata, the reliability or veracity of individual wikidata properties, the attribution of wikipedia content mapped from wikidata properties (in effect also from sister projects), the mapping from wikidata properties into infobox fields, inconsistent community censorship of structured data among sister projects or languages (e.g. ethnicity, or religion, or genetic sex vs self-identified gender, or other identifiers that are rejected by some cultures but not others), data model of infoboxes, aesthetics of larger vs smaller infoboxes, and how individual editors add infobox code into articles (empty field vs removed field). Changing from opt-out to opt-in does not address those topics – opt-in acts like a v-chip preset with censorship activated instead of censorship deactivated. –BoBoMisiu (talk) 15:19, 18 May 2016 (UTC)
"Censoring" is not an apt comparison, as the information that is not added to the infobox is often in the article, where it is contextualized. |religion= is the perfect example—description of a person's religious beliefs can sometimes run to multiple paragraphs, assuming it's all consolidated in one place instead of throughout the article.
I'll give a non-controversial example (no politicians): Art Spiegelman. There is no doubt that he is a cisgendered male secular Jew. Despite the fact that his Jewishness is central to his public figure—and this is an article that averages over 400 pageviews a day—no attempt has been made to cram that into the infobox. These facts are not censored from the article by leaving them out of the infobox—if you come out of the article not knowing Spiegelman is a Jew, then an infobox is not going to help you. It's reasonable to have "male" listed in his Wikidata item, but it's harder to justify in an infobox, which is meant to summarize key facts about the subject, not bury those key facts amongst trivialities such as gender.
Other issues come into play—those in charge of the keys at {{Infobox book}} have decided that infobox will be for first editions (sans discussion) rather than general details about the book. Those of us who disagree have had the option of (a) not using an infobox at all; or (b) just leaving out the first edition-related parameters (isbn, pages, media, publisher). Now we've found out that option (b) has bitten us in the ass. If it had been opt-in, this never would have happened, and there'd be less opposition to Wikidata-aware infoboxes (I'd probably use them, in fact). The rug's been pulled out on us—trust has been betrayed. Curly Turkey 🍁 ¡gobble! 23:30, 18 May 2016 (UTC)
@Curly Turkey: nevertheless, as I wrote above, "opt-in acts like a v-chip preset with censorship activated instead of censorship deactivated" – it does not address the issues presented. The effect will be default censorship of the wikidata with optional inclusion. –BoBoMisiu (talk) 16:17, 19 May 2016 (UTC)
BoBoMisiu: No comparison—a v-chip blocks content. With opt-in, the content is most often not only still there, but often prominently so, in detail with in-depth contextualization. Curly Turkey 🍁 ¡gobble! 22:27, 19 May 2016 (UTC)
@Curly Turkey: I disagree with you, opt-in requires someone to toggle the censorship off for each instance. It is just like someone allowing a child to watch "TV-G" programs or the great firewall of China allowing its citizens to watch something about Tiananmen Square protests. It is about shutting off access to wikidata by default just like a white list firewall. It is segmentation by default. –BoBoMisiu (talk) 03:51, 20 May 2016 (UTC)
BoBoMisiu: It's like you didn't even read what I read. How could it possibly be anything like a TV-G program or the Great Firewall when the information is all right there before your eyes? Here we are watching tanks rolling over students with tickertape-like byline giving us the details while some CNN announcer is giving us a play-by-play—and you tell us there's "censorship" because there isn't a little box in the corner redundantly summing it all up (don't forget that infoboxes are meant to be redundant). Look at the Harvey Kurtzman article—is it "censored" because it doesn't mention he's a Jew in the box? Of course not—you don't even have to scroll down to see that he was born to Jewish immigrants. I'd call this hyperbole, but hyperbole requires stretching a kernel of truth—there is literally no amount of "censorship" happening with opt-in. Curly Turkey 🍁 ¡gobble! 06:02, 20 May 2016 (UTC)
@Curly Turkey: I did read this again and I still think is about shutting off access to wikidata by default. Yes or no? –BoBoMisiu (talk) 18:53, 20 May 2016 (UTC)
No. Access is still there—where do you think it'd have gone? Don't go calling the autofilling of templates "access". The indiscriminate (human) filling-in of fields has already driven enough editors from using boxes in the first place—look, there's an open FAC where the nominator has been convinced to remove one—and you'll only see more refusing to use boxes at all. This whole mess have convinced me to finally give them up, given the disregard and near-contempt shown for editorial judgement. I'm no Luddite—I make extensive use of templates and have contributed to Wikidata. Curly Turkey 🍁 ¡gobble! 21:30, 20 May 2016 (UTC)
@Curly Turkey: those are differences in editing style within individual articles – but not related to a big brother (default opt-in) controlling the relationship between the structures that contain that data and use it. The arguments use premises about individual content discrepancies to make sweeping generalisations about structural relationships. These are different types of things. An analogy is: premises about using stuff (i.e. wikipedia) found in containers (i.e. wikidata) does not lead to conclusions about who controls the relationship to the containers. Changing to opt-in will require someone to toggle that default censorship off in each instance to use the stuff found in those containers. The Zeta Jones discussion you point to is a good example of misunderstanding of what structured data is. An editor commented "everything in the current box can be found in the lede" – but content in a lede is unstructured because is outside of a data model. I think that example was more about aesthetics. –BoBoMisiu (talk) 20:59, 21 May 2016 (UTC)
You've missed the point: boxes are officially optional, and many editors are keeping them out already, so that forcing opt-out only gives people more excuses to leave the box out (and there goes all the structured data).* It's the straw that broke this camel's back, anyways—I won't use infoboxes anymore because I can't trust them to behave as expected. Infoboxes were conceived as a place to sum up the article, not a place to dump indiscriminate data.
You're still pushing the hysterical "censorship" angle with your "big brother" arguments, and it's not getting any more convincing. Literally nothing is being censored.
*(except, not really, because it's all linked to in the sidebar) Curly Turkey 🍁 ¡gobble! 21:18, 21 May 2016 (UTC)

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

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

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

"explicitly blocking"—you have a funny understanding of the word "explicitly". "Opt-in" would retain the behaviour we've come to expect while allowing full access to Wikidata. Calling it "censorship" and comparing it to "Big Brother"—yeah, that's mighty hysterical. Now you're saying opt-in is censorship, but leaving the boxes out entirely is not? You'll have to explain. Curly Turkey 🍁 ¡gobble! 21:39, 22 May 2016 (UTC)
@Curly Turkey: very well, I will explain. The current system wide setting is opt-out and does not block wikidata by default. Your proposal changes that to opt-in and does blocks wikidata by default. Blocking the flow of data between structures is censorship: your premises are "we can't possibly predict all the parameters we should exclude" and "editors lose control over the articles they edit" and "If someone adds a new parameter to a box used in 37,000 articles, how do you ensure that the editors of all 37,000 articles know that this new parameter has been added so they can judge whether it should be excluded?" from those kinds of premises your conclusion is to block all wikidata by default, i.e. place a wall between wikidata–wikipedia structures because "we can't possibly predict" everything "we should exclude". It is the comparable logic behind a v-chip and a whitelist firewall. I wrote earlier: "I still think is about shutting off access to wikidata by default. Yes or no?" The question you are asking about not including a box in an article, in contrast, does not change the relationship between wikidata–wikipedia structures. –BoBoMisiu (talk) 14:32, 23 May 2016 (UTC)
You've just restated all the same assertions I've already refuted. Luckily for us all, nobody else is picking up this absurd, hysterical, counterfactual "censorship" angle. Curly Turkey 🍁 ¡gobble! 23:05, 23 May 2016 (UTC)
@Curly Turkey: yes I restated what I think are your premises. I do not read anything that write as a refutation. I may be wrong but you do not answer that simple yes-no question I asked above that would refute me and I would concede. I asked: Is your proposal about shutting off access to wikidata by default. Yes or no?
About your example about book ISBNs in cases where works have more than one edition, a work is commonly described by its first edition. For example, Nineteen Eighty-Four uses {{Infobox book}} which has documentation that suggests "prefer ISBN of 1st edition" and "OCLC number (prefer 1st edition), use when book has no ISBN". I see that a different language first edition OCLC could become wikidata that is imported into that infobox. The problem is not about the relationship of wikidata–wikipedia structures but that wikidata:Q208460 describes the work and not the expression of the work. So when you follow the link viaf.org/viaf/175794909/ you see the work page with some expressions of the work but not all. From there if you follow the link viaf.org/viaf/95155403/ you see the author page with links to several records of works titled Nineteen eighty four. A wikidata or wikipedia contributor who adds the ISBN or OCLC of the 1st edition of the work would need to know that the 1st edition is the preferred edition to avoid the existing state in that instance of the infobox which has, for example, a 2003 edition OCLC added by a wikipedia contributor in 2009 and then imported into wikidata. It was nothing more than user error in that case. If wikidata later imports a record of the preferred 1st edition from a library catalog, the infobox will still retain the 2003 edition OCLC and 2013 ISBN instead of the preferred 1st edition OCLC without an ISBN. Again, the error was spawned was caused by human error of a wikipedia editor in 2009 and not changed by anyone since. Your proposal would not change anything in such a case. –BoBoMisiu (talk) 02:40, 24 May 2016 (UTC)
I answered your loaded question. Access would not be "shut off"—the indiscriminate loading of data would simply not be automatic. As it has always been—the auto-importing of this data is new behaviour and overrides the assumptions of the editors. Opt-in respects the decisions editors have made over the years while still enabling infoboxes to import all of this data. Regardless, all the data is but a click in the sidebar away.
Re: ISBN—I'm one of the many editors who doesn't agree with this "prefer first edition" schtick—the box should contain general information about the book, and thus not an ISBN, OCLC, page count, media type, etc etc etc. Whether the data is correct or in error is irrelevant—it doesn't belong in the infobox. Infoboxes were not conceived as an indiscriminate data dumping ground. Curly Turkey 🍁 ¡gobble! 03:14, 24 May 2016 (UTC)
@Curly Turkey: great sidestep on ISBNs and OCLCs by avoiding the standard way works are described, i.e. "prefer first edition". ISBN and OCLC are general information about books in the 21st century – the connection to authority records provides readers with structured data that libraries use to describe a work in standardized ways.
Your reply avoided the term by default and used indiscriminate instead. You still avoided the question – and I still see opt-in as blocking wikidata contributions by default, i.e. censoring.
Yes, opt-in "respects the decisions editors have made over the years" and opt-in rejects the contributions other editors have made over the years until someone else decides to permit those contributions – in other words it creates classes of contributions based not on the merit of the contribution but on the method or channel of contribution. Moreover, is irrelevant since every editor can make changes that in turn can be rejected. The real reason is that wikidata is disruptive innovation (what you call new behaviour) that confuses some people about their premises of control, you wrote: "we can't possibly predict all the parameters we should exclude" and "editors lose control over the articles they edit". The internet is arguably the most disruptive innovation ever that is why totalitarian governments block access to it because they "can't possibly predict". Likewise, from your similar premises you conclude blocking all wikidata by default, i.e. creating structural barriers between wikidata–wikipedia structures because "we can't possibly predict" everything "we should exclude". Technology is and will continue to change: the internet of things will become commonplace and the relationship between identifiable objects and their descriptions in wikipedia will evolve. Structured data in wikidata is the machine readable interface. Importing data from authoritative sources into Wikidata will eventually correct human editor contributions like the Nineteen Eighty-Four example above. To say that "all the data is but a click in the sidebar away" seems not to be open to the possibilities of innovation. There is a whole world of reliable meta-data out there but opt-in isolates wikipedia by default. –BoBoMisiu (talk) 14:57, 24 May 2016 (UTC)

Discussion (Wikidata)

  • Does anyone have an update on the phases and rollout, etc.? Is the plan to turn on Wikidata access by default for all infoboxes, or is this a case by case implementation? If the latter, where are the directions that an editor can bring to an infobox talk page for consideration and implementation? czar 05:28, 16 May 2016 (UTC)
    • It depends on who takes initiative. As far as {{Infobox road}}, it's our eventual plan to turn it on for more fields, but we're waiting for some stuff to be done on the Wikidata dev side (Capiunto, I think it's called) to make life easier. --Rschen7754 05:43, 16 May 2016 (UTC)
  • I wonder if this discussion is too soon. Before any progression goes too far I would like to see wikidata work with existing templates commonly used in infoboxes e.g. {{death date and age}} The use of wikidata in templates like {{Infobox person/Wikidata}} means that age now has to be calculated and added manually. I'd also likethe ability to watch the wikidata page for a page I watch here on my wikipedia watchlist before I would be more happy about the source being split between two stores. I think the basic premise is good but there need to be more tools available for monitoring and checking first. Nthep (talk) 07:49, 16 May 2016 (UTC)
    There is an option in your preferences to add Wikidata changes to your watchlist (exception: not an "enhanced" recent changes/watchlist--this is phab:T46874). --Izno (talk) 12:09, 16 May 2016 (UTC)
  • Template:Infobox person/Wikidata was only intended as a test-bed to try out methods of data-awareness. Nevertheless setting |birth_date={{death date and age|yyyy|mm|dd|yyyy|mm|dd}} in an article will allow you to use local values there, exactly as you would with Template:Infobox person, because any local parameter overrides the value fetched from Wikidata. --RexxS (talk) 23:32, 16 May 2016 (UTC)
    Thank you RexxS for the additional info. To me these seems like an easy way to implement wikidata. If you are happy with the Wikidata content then let the infobox fetch it. if not, override it with a local value or set it to empty. Then my concern is about the quality of data in Wikidata, too much seems to say "imported from Wikipedia" without the RS we insist on here having been carried over. That's not just a problem with Wikidata but for all of us and I suspect for many who have contributed to this RFC a fairly major stumbling block to opt-in. The mechanics are acceptable but the quality control is lacking. Nthep (talk) 11:29, 21 May 2016 (UTC)
I like the idea of "isbn=WikiData". It makes it clear to an editor where the data is coming from, plus it gives them control over whether they want it. Without this, data will be appearing out of nowhere, and editors will have no idea how it got there. 217.44.215.253 (talk) 11:50, 16 May 2016 (UTC)


  • User:CFCF can you please explain how opt-in would prevent people from doing what was with the infobox at Gout? Jytdog (talk) 18:26, 16 May 2016 (UTC)
  • While I'm not averse to using Wikidata within Wikipedia articles - I do wonder about verifiability. The purpose of an infobox is to summarise key information from the article. The infobox guidelines at MoS state that the information should be already in the article (and cited) or referenced in the infobox (unless "obvious"). It is unclear to me whether the proposed mechanism:
    • checks whether the data has a reference on Wikidata?
    • checks whether the reference meets the requirements of a reliable source?
    • inserts a suitable reference into the article?
Difficult to decide on opt-in or opt-out options without knowing the answers... Robevans123 (talk) 20:15, 16 May 2016 (UTC)
I agree with that Robevans123. Wikidata is cool in theory but the devil is in the details. Jytdog (talk) 20:24, 16 May 2016 (UTC)
Damn, it's not working as it should be (still beta, now borked) - but what it should do is simply pull a number of parameters from Wikidata. These are from a number of high quality sources that include this data in a structured format. Ideally the template would only pull the data if sources exist, this is being worked on.
As for the questions by Robevans123, I had not seen them before now and I agree that they are very important. Maybe Daniel Mietchen may have an answer? Carl Fredik 💌 📧 14:34, 17 May 2016 (UTC)
  • The code to check for references is written and is used in Module:Sandbox/RexxS/WdRefs as a demo.
  • I know of no way of automating the process of deciding whether a reference meets the requirements of a reliable source. If it were possible, we could do away with WP:RSN. But I don't see that happening any time soon.
  • As I don't know any way of automating the process of deciding what format of references is currently in use in an article, I don't think we can insert a "suitable reference" without violating WP:RETAIN.
You can use Module:Sandbox/RexxS/WdRefs to see which Wikidata items have associated references and make decisions as an editor, but I don't see any way of sensibly delegating such decisions to an algorithm. --RexxS (talk) 19:08, 14 June 2016 (UTC)

Implementation vs existence

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

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

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

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

I'm all for empowering editors to make editorial decisions, but I don't agree that the [edit on wikidata] link isn't informative to an editor - a reader, maybe. Surely an invitation to edit the corresponding article on Wikidata is informative of what that link does?
I'd be quite happy to implement a longer notice saying "This information is partially sourced from Wikidata" as a test in any wikidata-aware infobox you'd like (but it can't be <small>...</small> as that would be below the 85% minimum text limit agreed for readability). However, I can't guess what "the most useful Help: resources" are that you have in mind, nor do you indicate which part of the notice you want linked to them and which part you want linked to the Wikidata item. If you can give me some specifics, I can make a trial for you. --RexxS (talk) 15:03, 20 May 2016 (UTC)
Not sure if this is a good idea or not, but perhaps what Fred Gandt's suggested can be combined with something RexxS was/is working on, Wikipedia_talk:Wikidata#Wikidata_references, so the line This information is partially sourced from Wikidata becomes the heading of a collapsed element containing references from Wikidata (for fields using wikidata) – i.e. as a very rough visual mockup:
Example
FooBar
BazQux
This information is partially sourced from Wikidata
  • Foo (P123): Bar – SomeReference
  • Baz (P789): Qux[reference needed]
with appropriate links to be added in appropriate places. - Evad37 [talk] 04:23, 21 May 2016 (UTC)
@RexxS: What I meant by not very informative, is that it doesn't indicate which magic values are affected or how to do anything about it locally. That's where the suggestion to link to help pages comes in, although the help needed may not currently exist and would thus need to be created. This is merely suggesting a place to start on a possible course of action. Evad37 has shown exactly the kind of initiative I hoped to encourage.
@Evad37: Great idea Fred Gandt · talk · contribs 06:27, 21 May 2016 (UTC)
This idea/possible implementation is looking very good. If the collapsed section also included a link to the Wikidata source such as Source: Ffynnon Gwenfai - Statutory List of Buildings (here's one I made earlier), then an editor would have access to the details to create a reference in the article (not quite as good as creating a reference automatically, but a good start). Robevans123 (talk) 09:48, 21 May 2016 (UTC)

Setting precedence

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

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

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

I still don't understand what you did at Gout. Are fields there being automatically populated somehow? Jytdog (talk) 14:14, 17 May 2016 (UTC)
Yes, check out the Template:Infobox medical condition(new), which pulls a number of properties from WikiData. It is so far still only a beta-version, but it show useful and more importantly human-readable information (unlike the old infobox did). (BTW, not my work) Carl Fredik 💌 📧 14:26, 17 May 2016 (UTC)
So what actually happens when I remove Field = Rheumatology by editing the Gout article in the template section on wikipedia - because I have left it blank, the infobox pulls the 'Specialty' from Gout at wikidata and populates it accordingly. You can see from the switch from Rheumatology to rheumatology. However Gout's specialty field at wikidata is sourced to wikipedia, and the wikipedia article does not actually state in the article that Gout is in the Rheumatology field. Except in the infobox. Which is unsourced. (it probably doesnt need to be as its a sky is blue issue - for doctors anyway). In this case not an issue, but it clearly demonstrates the problem with the process. Only in death does duty end (talk) 15:05, 17 May 2016 (UTC)
The specialties are typically based on the ICD10 which groups diseases by them. Doc James (talk · contribs · email) 16:26, 17 May 2016 (UTC)
Except in this case, its not. Its clear circular (un)referencing and from the stats shown at signpost, this is the *norm* not the exception for data hosted at wikidata. Granted the medical wikidata appears to be better than other areas, but wikipedia is bigger than just the medical section. This was an example CFCF chose of it working well/correctly - and it shows the glaring shortcomings of an opt-out approach that could have quite serious consequences. Only in death does duty end (talk) 16:35, 17 May 2016 (UTC)
Then something has gone awry, because the data is imported from the ICD-numbers, we did that at Wikimania 2015. Carl Fredik 💌 📧 18:31, 17 May 2016 (UTC)
  • Wikipedia's sourcing requirements for medical info are in some ways just as restrictive as our BLP requirements. As far as I can see Wikidata does not have those same restrictions for medical (or any other info.) I (and I suspect many others) are unlikely to ever want "symptoms, differential diagnoses, treatment options" automatically filled in on infoboxs from wikidata without a manual check that the information included abides by our sourcing requirements. I have yet to see an argument that explains how this would be prevented that doesnt include more work under opt-out, than under opt-in. Only in death does duty end (talk) 14:18, 17 May 2016 (UTC)
Sourcing requirements for medical info are far stricter than those for BLP, and only reliable data should be imported to WikiData at all. The whole point of Wikidata is to automatically import reliable information (and not just any crap), and any manual control at all makes the task exponentially more time-consuming. Carl Fredik 💌 📧 14:26, 17 May 2016 (UTC)
Well quite, but this clearly indicates maybe only a quarter of wikidata's data is referenced to a source independant of wikipedia. And thats only indicating they have a reference, its no indication they are 'reliably sourced' and compliant with our policies here. There is no indication that the unreferenced material on wikidata will be excluded from the automatic importation (which it really should be). The whole point of wikipedia is to present information that is verifiable and has been reliably sourced. Currently Wikidata does not do that. Only in death does duty end (talk) 14:31, 17 May 2016 (UTC)
A solution that the Swedish Wikipedia employs is to bring along all references on Wikidata (sv:Modul:Wikidata/sv:Mall:Wikidata, example [[]], can't find any example) and in such a manner also only accept sourced Wikidata entries. But at the same time, we use data on Wikipedia in almost all infoboxes that is unreferenced, and any Wikidata reference is better than having no reference on Wikipedia.
Another solution is something like what exists on Template:Infobox drug, with a verification button (in that case poorly implemented and confusing, but existing). Carl Fredik 💌 📧 14:40, 17 May 2016 (UTC)
"we use data on Wikipedia in almost all infoboxes that is unreferenced, and any Wikidata reference is better than having no reference on Wikipedia." The problem with that is circular - Wikidata imports data directly from multiple wiki-projects (including directly from infoboxs) and the reference is the projects article - so any 'filter out unreferenced' import to wikipedia is still going to have issues when a huge amount of the actually referenced data is unreliably sourced. There are issues with "any Wikidata reference is better than having no reference" when functionally data in an infobox on wikipedia does not have to be referenced directly when it has been referenced in the prose. However data that isnt in the prose and has been imported from wikidata is currently likely to be either unreferenced or badly/unreliably referenced. The general consensus on wikipedia is that information should not be included. Opt-out would actively cause more checking required on the wikipedia end for very little payoff. Only in death does duty end (talk) 14:53, 17 May 2016 (UTC)
Now you missed the point. I would not consider Wikipedia a reference on Wikidata, I don't even know that it is? Carl Fredik 💌 📧 15:11, 17 May 2016 (UTC)
See my above comment RE Gout. Only in death does duty end (talk) 15:13, 17 May 2016 (UTC)
User:CFCF - how does that work? Cuz...
I'm wondering why the Template:Infobox drug box at Fluoxetine doesn't display the wikidata for price but does (if I'm not mistaken) (I don't think it uses wikidata for the chemical formula because "|C= 17 |H= 18 |F= 3 |N= 1 |O= 1" overrides anyway, I guess. (I wonder how to make it display both/if it's yet appropriate to delete the "|C= 17 |H= 18 |F= 3 |N= 1 |O= 1" and let wikidata take over.) I don't see anything like {{#property:P274}}, {{#property:P2284}} or {{#property:P<anything>}} in the source of the infobox template. --Elvey(t•c) 07:29, 1 June 2016 (UTC)
Template:Infobox drug is not Wikidata enabled. Infoboxes that fetch information from Wikidata generally use calls to Module:Wikidata, which provides more flexibility than #property (e.g. automatic links to existing articles and disambiguation). --RexxS (talk) 18:52, 14 June 2016 (UTC)

ArticlePlaceholder

Magic Unicorn, said to present Wikidata information on Wikipedias

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

See live examples as follows -

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

ArticlePlaceholder doesn't use infoboxes, and it only appears when there is no local article on the subject. If you want to see what can happen with infoboxes, then look at w:es:Jimmy Wales. The large infobox in that bio requires a single line of wikitext and zero parameters. WhatamIdoing (talk) 03:29, 22 May 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Closing

The 30-day period runs at 5pm Eastern US time today. I feel pretty comfortable with this one, and I plan to start work on the close at that time. (As always, please tell me if you have any objections.) I'll go post at WP:AN now, and if others want to join me in closing, that's fine. Between then and now ... if anyone wants to suggest how to go about closing this, this is a tough one, and I think some discussion about how to close it would be helpful. - Dank (push to talk) 13:37, 14 June 2016 (UTC)

We don't all live in the eastern US. The 30-day period expires at 20:59, 14 June 2016 (UTC). --Redrose64 (talk) 13:42, 14 June 2016 (UTC)

Thanks. The thirty-day period has run. Any RfC close can be challenged at any time, so the closers (just me for now) have to write up something that works as a neutral and complete summary of the RfC, and I've made a stab at that. But I also have to write up something that is actually going to work ... that is, it has to reflect a broad consensus, otherwise the people who are supposed to be putting your recommendations into practice will run into problems, if for instance they don't understand or don't agree. I think it would be safer to get broader feedback than we got here before I post a closing statement. I'm asking for recommendations on: 1. where we might post neutral invitations to comment 2. whether we ask people to post their comments here, or to discuss wherever they usually discuss things ... for instance, on wikiproject talk pages or over at Wikidata, and 3. whether we should simply ask people to read and comment on what they see in the RfC, or whether we should try to put together a shorter, easier-to-understand summary of the positions to present to them. Again ... I've already got the outline of a closing statement, and I intend for that statement to work on both levels ... as something that reflects only what was said during the 30 days, and also works when we take further comments into account. Thoughts? - Dank (push to talk) 21:17, 14 June 2016 (UTC)

I forgot to add: normally at this point I would be praising your work here, and there's plenty to praise. But I'm hoping to get more feedback, and until I present a summary, I can't say anything about which way I'm leaning. - Dank (push to talk) 22:29, 14 June 2016 (UTC)
Update: I'm working on a closing statement, hopefully out in a few days, possibly in a week. - Dank (push to talk) 19:38, 15 June 2016 (UTC) P.S. All the above still holds. 03:15, 16 June 2016 (UTC)
Already not going anywhere. --Izno (talk) 13:30, 16 June 2016 (UTC)
  • I think this is an unambiguous "opt in by default" outcome. I think two points need to be clear in the close, though.
    1. If editors choose to go with "opt out" with local consensus at a given template, that should be fine. There is substantial support here for deferring to local consensus on this issue, since the quality of Wikidata information varies by topic area and attribute.
    2. If a technical change is made to the Wikimedia software to include changes to Wikidata in the watchlist, this consensus should be reassessed. That is a significant part of the rationale for going with "opt in", as editors on Wikipedia can't keep track of all changes at Wikidata. ~ RobTalk 00:05, 15 June 2016 (UTC)
Well, I wasn't expecting to re-litigate the entire debate again, but if you insist:
  1. I don't see either a clear consensus for "opt-in" or "opt-out", or even an agreement that we should be making such a binary decision.
  2. As I have consistently pointed out throughout this debate, the RfC was founded on an untrue premise and with little understanding of the ways in which infoboxes are coded to import from Wikidata.
  3. I have demonstrated beyond dispute ways in which we can devolve to the individual article editors the decision to import from Wikidata or exclude any given field. There is simply no point in trying to create a general "rule" that infoboxes must be "opt-in" or "opt-out", because we have moved well part that point some time ago, and any attempt to impose such rules will rightfully be met with contempt by the designers.
Feel free to add your own summary. --RexxS (talk) 16:23, 15 June 2016 (UTC)
Based on Rexx's and CFCF's explanations above I ran a test to see if the behaviour I expected and worried about (namely unreliable wikidata would be imported without checks into wikipedia articles). I removed a field from a template that had been enabled to import data from wikidata. Lo and behold, the template automatically populated the infobox with the relevant info from wikidata which was circularly sourced to the wikipedia article I had just removed it from (which incidentally was only located in the infobox anyway!). So the end result was the template was populating itself with infomation that was completely unreferenced to a reliable source. Not a huge issue given what I was doing, a much bigger problem in *any* BLP or seriously contentious area. Absent a quick and *easy* way to opt-out/exclude wikidata, wikidata itself currently fails verification and reliable source policy requirements. The % of information stored there that is un/badly referenced is far too high for automatic/opt-out inclusion. Only in death does duty end (talk) 16:44, 15 June 2016 (UTC)
The plural of "anecdote" is not data. Feel free to preview the demo templates {{Sandbox/Infobox biosphere reserve}} or {{Infobox book/Wikidata/Sandbox}} in any article and see what Wikidata is returned automatically. The answer is 'none', unless the editor specifically enables it in that article. It simply depends on how the infobox designer has arranged to get information from Wikidata. Editors of some topics want auto-populating infoboxes, like {{Infobox telescope}}; other editors want infoboxes that only populate from Wikidata when they allow them to, like {{Infobox book}}. Why is this insistence that "one size fits all" is even a remotely sensible stance to take?
If you think Wikidata is insufficiently referenced to be usable in Wikipedia, then you need a different RfC; we've not been debating whether we use Wikidata but only how. --RexxS (talk) 20:03, 15 June 2016 (UTC)
And the how would be 'explicit opt in'. Only in death does duty end (talk) 21:32, 15 June 2016 (UTC)
No, the how would be 'leave it the editors to decide'. We don't need any more petty wikicops who never designed a thing in their lives telling the editors how they are 'allowed' to use Wikidata. --RexxS (talk) 23:00, 15 June 2016 (UTC)
Actually a number of polices dictate how wikidata can be used on wikipedia. Chiefly WP:V. You have yet to make a convincing argument that the status quo should be that wikipedia imports masses of unverified and unreliable information without explicit checking before it hits a live article. Only in death does duty end (talk) 23:08, 15 June 2016 (UTC)
the how would be 'leave it the editors to decide'—Except you people are not leaving it to editors to decide—you're forcing it all on us silently, as was the case with {{Infobox book}} and the mysterious ISBNs, implemented without discussion, changing the established, expected behaviour in thousands of infoboxes. That's why we're here—because you people can't be trusted.
If you think Wikidata is insufficiently referenced to be usable in Wikipedia, then you need a different RfC—we do need one. This RfC has opened my eyes to how serious the problem is, and now I see it all over the place—like the "death date" I found for Adachi Ginkō that was "Imported from Japanese Wikipedia", where the death date was tagged {{citation needed}}. How does something like that get imported in the first place?! Curly Turkey 🍁 ¡gobble! 23:19, 15 June 2016 (UTC)
@Only in death: I make no such argument, and I have no intention of convincing you of it. But that's not what this RfC is asking. Feel free to start a new RfC on the question of whether Wikidata should be used in Wikipedia. I have no problems in advocating for WP:Verifiability, but it's not a guarantee for avoiding "masses of unverified and unreliable information without explicit checking before it hits a live article" - that's also a description of many edits made to articles directly. If you don't like masses of unverified and unreliable information, there's plenty of work to be done right here. Wikipedia's full of it (and that's why it gets into Wikidata of course). Have you tried {{Infobox book/Wikidata/Sandbox}} yet? Want to share that result with us?
@Curly Turkey: But you people aren't interested in sharing the knowledge in English Wikipedia with the other projects: as far as I can see, you just want the ability to tell other editors that they can't create infoboxes like {{Infobox telescope}}. I solved every single complaint you had about making {{Infobox book}} Wikidata-aware, so you started this RfC to get your wish. That's not working so you've changed your tune and now have decided you need to forbid Wikidata altogether so you can play wikicop. Have you tried {{Infobox book/Wikidata/Sandbox}} yet? Want to share that result with us? --RexxS (talk) 00:12, 16 June 2016 (UTC)
But you people aren't interested in sharing the knowledge in English Wikipedia with the other projects—nothing anyone has said here could possibly be interpreted in such a horseshit manner. Why would anyone take your comments seriously when you choose to just make things up like this? Curly Turkey 🍁 ¡gobble! 01:14, 16 June 2016 (UTC)
And the same applies to your Except you people are not leaving it to editors to decide—you're forcing it all on us silently bullcrap. That's the very opposite of what is being done. Do you really expect to fool the closer by simply insulting their intelligence? Have you tried {{Infobox book/Wikidata/Sandbox}} yet? Want to try it and then let the closer know how it turned out? --RexxS (talk) 12:17, 16 June 2016 (UTC)
Yeah—doesn't work, it spits out "unknown parameter" error messages. Not that that's the issue, so you can stop redirecting the discussion away from the issues. The problem is you people implemented this shit without discussion, resisted objections to it on the talk page afterwards, and only caved in on the one single template after being dragged kicking and screaming to do it. And there's the crux of the problem—the utter contempt you people show for the content editors affected by your unilateral decisions. This is why we need opt-in—so you can't force this stuff on us unknowingly. Why? Because you can't be trusted, and we don't all have the energy to hunt up and fight your every unilateral decision.
That's the very opposite of what is being done—it's amazing you can bullshit like this with a straight face. This is almost as bad as you people aren't interested in sharing the knowledge in English Wikipedia with the other projects—based on no evidence.
I used to be a vociferous proponent of infoboxes. Now I feel that I can't use them (have stopped entirely) because I can't trust them—or, rather, I can't trust the people who have the keys. Curly Turkey 🍁 ¡gobble! 13:15, 16 June 2016 (UTC)
  • Above, RexxS states: "...we've not been debating whether we use Wikidata but only how."
I respectfully submit that this is the problem. This RFC put the cart before the horse... We are not going to be able to reach consensus how to use Wikidata unless we have consensus on whether we should be using it in the first place. From what I read above, there are some very serious concerns about Wikidata's reliability.
Thus, I propose that we put this RFC on hold... and actually have an RFC on the more basic question of whether Wikidata is reliable enough to be used in the first place (If the answer to that is "yes", then we can return to discussing how to use it... and, if the answer to that question is "no", I think it would be helpful to follow up with some discussion on steps Wikidata needs to take to become reliable enough.) Blueboar (talk) 13:31, 16 June 2016 (UTC)
What would it mean to say "Wikidata should not be used"? Do you mean no user would be permitted to use it, and links to it would be forbidden? If you don't mean that, isn't the discussion in fact about how, not whether, to use it? Mike Christie (talk - contribs - library) 13:46, 16 June 2016 (UTC)
I'm listening. - Dank (push to talk) 13:51, 16 June 2016 (UTC)
Such an RFC would be seeking to overturn Wikipedia:Requests for comment/Wikidata Phase 2? --Izno (talk) 14:03, 16 June 2016 (UTC)
(edit conflict)I feel its' prudent to mention Wikipedia:Requests for comment/Wikidata Phase 2 answered (in my view) the "whether", and it was essentially "yes, in infoboxes, with local override and consensus". That's a very terse summation of the closing comment but.... -- ferret (talk) 14:05, 16 June 2016 (UTC)
I'm concerned that the heated discussions both during and after the RfC are going to make it harder to arrive at an eventual solution (possibly after many RfCs) that everyone can live with. Some questions are more pointed than others ... "Is Wikidata too crappy to use at all" would be one of the more pointed questions. Blueboar, I've respected your work for a long time, and I get where you're going with this, but I'm concerned that that's how some will read the comment. What I'm looking for here is a way to turn down the heat and get people to work on the big, tough questions ... vetting, gaining an understanding of the different goals of different people, and if all else fails, a kind of negotiation. How do we do that? Actually, the biggest question for me is: what kind of close would at least accomplish the minimal goal of keeping things from continuing to slide downhill? - Dank (push to talk) 14:14, 16 June 2016 (UTC)
Apologies for a quick answer, but I think a strong reiteration that Wikidata should be used in Infoboxes for fields that have consensus (Or a lack of opposition at least) to do so is the best course. If, for example, the inclusion of certain fields in Infobox Book is causing issues, then that infobox field should cease using it as a result of discussion within that project area, or switch implementations to opt-in.... It seems like there are 2-3 particular Infoboxes that have been used as examples repeatedly, and deal with BLP style issues, that are struggling with how Wikidata is edited or included. The RFC seeks to provide a remedy for those, but by enforcing a change against ALL infoboxes. I don't believe this is necessary. If Infobox book would be better served with an "opt in" style, then do it. If other areas function perfectly fine with an "opt out" manner... continue to allow it. If it is believed that the original RFC for phase 2 is specifically restricting infobox implementations to a "silent inclusion" model as the ONLY ALLOWED option, then I think the result of this RFC should be to allow for opt-in. But this RFC should not declare that all infoboxes are restricted from using the current "silent inclusion" model described by Phase 2 RFC and must adopt "opt in". That's my 2 cents. Hopefully I didn't ramble too badly. :) -- ferret (talk) 14:47, 16 June 2016 (UTC)
I've reviewed my !vote at the phase 2 RFC and I find myself agreeing with myself therein. The original options (and the consensus option) failed to capture that we should be willing to set opt-in/opt-out of Wikidata at a variable level, depending on the field, infobox, domain, and the specific article in question. (And am somewhat regretful for some of my earlier argumentation in this RFC.) This RFC, had it not been started so quickly (and with the associated level of (mis)understanding), might have nicely helped to refine the prior RFC. --Izno (talk) 15:03, 16 June 2016 (UTC)
I hate to say it, but... essentially, I am asking: "Is Wikidata too crappy to use at all?". (I would not phrase it that way... but it is what I am asking). This is one of those big tough fundamental questions that we need to at least ask. It has been two years since Wikipedia:Requests for comment/Wikidata Phase 2... we have now seen Wikidata in action, and can see its flaws. It's time go back and ask if the flaws are considered serious enough for us to rethink our prior consensus. It may be a harsh question, but we have to at least ask it (we can't move on and negotiate compromises until we do). Blueboar (talk) 15:53, 16 June 2016 (UTC)
I disagree pretty severely with this comment, or at least we have now seen Wikidata in action, and can see its flaws. I won't get into why at risk of re-arguing many of the RFC's premises and subsequent discussion, and even the section above I collapsed. --Izno (talk) 16:03, 16 June 2016 (UTC)
Let me put it this way: do I personally think Wikidata is "too crappy" to use at all? ... my honest answer is: I don't know. However, as I read the RFC I became increasingly concerned that it is. I would like an RFC to address that concern. Blueboar (talk) 17:14, 16 June 2016 (UTC)
Whatever is done next, I think an immediate move to another RfC would be a bad idea (Blueboar, I know you said nothing about making it immediate). I changed my position on this RfC, largely because Izno took the time to answer my questions; I was underinformed when I first !voted, though I didn't realize it. I suspect I'm still underinformed; and I wonder if some other participants here are too. I'd prefer to see some discussion between people on both sides of this about what the problems are and what sorts of approaches might address them, in a forum that is explicitly not targeted at making a final decision. I think we need more clarity before we start asking for solutions. Mike Christie (talk - contribs - library) 17:20, 16 June 2016 (UTC)
A non-RFC preliminary discussion would be acceptable. I am not trying to force any outcome here... I am expressing concern and asking questions. Blueboar (talk) 17:48, 16 June 2016 (UTC)
For the moment, my top goal is to stay out of the way of you guys while you work. I'm open to the argument that the best way to do that is to close this RfC as inconclusive and let you guys get to work on discussing and planning a new RfC ... OTOH, I've put in a lot of time and I'm willing to put in a lot more time on this one, if that will serve a purpose. Thoughts? - Dank (push to talk) 17:59, 16 June 2016 (UTC)
I wouldn't delay writing the closing; I think you should write it as if the proposed discussion may not happen, since it may not. Mike Christie (talk - contribs - library) 18:04, 16 June 2016 (UTC)
I think that this proposed RFC by blueboar is actually very likely to be the way to go - this RFC muddied the waters a lot, and it is going to be hard to find a solid consensus. However, if we just ask the correct question from the get-go, we can have a much clearer picture of what the community actually wants. Tazerdadog (talk) 01:11, 17 June 2016 (UTC)
SEE DISCUSSION at WP:VPP#Discussion re Verifiability issues with Wikidata (below) Blueboar (talk) 12:07, 17 June 2016 (UTC)

Articles on horrible crimes and their perpetrators

There is now a lengthy voting record on whether the article on Omar Mateen should be merged with the article on the Orlando shooting incident. Similar discussions have taken place concerning the Sandy Hook Elementary School shooting and whether its perpetrator should have his own article. In both cases, Omar Mateen and Adam Lanza, the respective perpetrators, appear to satisfy "notability" - to an extent, which is to say only insofar as their crimes gave them notability. The Omar Mateen editors seem to be slanting towards having the separate article on the perpetrator, while the Sandy Hook shooting editors have kept a section on the perpetrator in the main article; discussions are on going. This issue is plain - does a single horrible crime entitle the perpetrator to his own wikipedia page as a normal biographical page? I post this here to suggest that there should be a general Wikipedia policy regarding incidents like these. There will sadly be more of them. I tend to object to the separate biographical page for perpetrators like this - they are not otherwise notable, it gives notability/immortality for a single horrible act, and separate articles tend to attract material that deviates from the crime for which the perpetrator is notable (e.g., do we need to know that Omar Mateen was a member of the Democratic party?). People like this are not in the same category as, e.g., Nobel prize winners, where the course of their lives are of general interest. Events in their lives apart from the crime are not notable, for example. Bdushaw (talk) 12:12, 16 June 2016 (UTC)

WP:BLP1E? Lectonar (talk) 12:21, 16 June 2016 (UTC)
A well cited policy...yet with still ongoing discussions. Perhaps that policy is all we need. I returned here to note the examples of Columbine High School massacre and its perpetrators Eric Harris and Dylan Klebold.
Simply spoken: I think the problem is that most people would like to have articles about the perpetrators (deep down, in a way, we are all voyeurs...more or less), while knowing rationally that this is colliding with existing Wikipedia-policy. But I really think that BLP1E in these cases trumps the rest, after all. Lectonar (talk) 12:31, 16 June 2016 (UTC)
BLP1E only applies if the person is living, in most cases the killer or killers take their own lives. In the cases when they don't then WP:WELLKNOWN has to be considered given the WP:LASTING coverage. - Knowledgekid87 (talk) 14:38, 16 June 2016 (UTC)
BLP1E is generally irrelevant here; try WP:BIO1E. עוד מישהו Od Mishehu 14:50, 16 June 2016 (UTC)
Yes :)....meant that :) Lectonar (talk) 14:52, 16 June 2016 (UTC)
The same would apply, it is a case by case basis. Right now there is an ongoing investigation into links to terrorism, links to family members, in a nutshell this is branching out. Compare this to Adam Lanza who had no criminal record or investigations on him, and was found to be mentally unstable. Now if Adam had some lasting effects such as a notable research study done in regards to him then maybe but sadly nothing has come of it. - Knowledgekid87 (talk) 15:09, 16 June 2016 (UTC)
The thing about Lanza is that Lanza killed the family-member he was living with (so no more details forthcoming there - unlike Mateen with father, ex-wife & wife), Lanza also had no employment history (therefore no statements from present or past employers, no interviews with co-workers) and he was a loner (so no interviews with people who had seen him out and about, no friends, no neighbors). There aren't really people around to interview about the details of his daily life beyond his horrific crime - he is known for one thing and one thing only. Plus the consensus at the Sandy Hook article so far has been against a separate article. Shearonink (talk) 15:56, 16 June 2016 (UTC)
Part of my concern/question, was that I was suspecting that in cases like this "the details of their daily life" should not be included in their biographies, if they are to have biographies, just those facts pertinent to the crime (including how they came to violence). Perhaps a little fuzzy in distinction - are all biographies equal? Bdushaw (talk) 16:05, 16 June 2016 (UTC)
I don't think they are all equal, in some cases you aren't going to get detailed information. People like Lincoln for example have been studied by historians for decades so a-lot of information has been gathered and used when writing about his life. I would include as much as we can in a biography as it gives readers insight into the person beyond just being known for x. - Knowledgekid87 (talk) 16:16, 16 June 2016 (UTC)
WP:BIO1E is not a policy, it is an ambiguous guideline within a policy that requires that we use common sense. The good news is, we do, all the time, which is why articles about people such as Ted Bundy, Timothy McVeigh, and John Wayne Gacy are retained. In the case of Mateen, he is now a notorious historical figure whose life leading up the the massacre is a matter of interest to readers of an encyclopedia.- MrX 16:29, 16 June 2016 (UTC)
I just noted WP:PERPETRATOR - the criteria for a separate article for a perpetrator would seem to be dependent on the notability of the crime. Orlando, Sandy Hook, and Columbine incidents certainly all fit that criteria. Bdushaw (talk) 18:43, 16 June 2016 (UTC)

I think there are two seperate questions here, though I have no idea how they could be resolved as policy. In the immediate aftermath of an incident such as 'Orlando', there is a huge amount of low-grade info available about the perp, a class-mate from 20 years ago says the perp bullied her and other girls, this gets reported with maximum 'boost' and no context as whether this bullying was any more significant than normal 9 year old behaviour. It ends up in our article. Later perhaps more careful assessment of the perp's past behaviour emerges. There is little doubt that Mateen's past life is going to be of interest and that it is going to be looked at in detail over coming weeks/months. In the meantime what do we have? Pincrete (talk) 10:51, 21 June 2016 (UTC)

Please comment on sourcing examples in "in popular culture" articles and sections. BrightRoundCircle (talk) 19:33, 21 June 2016 (UTC)

Academic works translation needed before Wikimania

Hi,

I've finished a French academic work named Ethical drift with in Wikimedia movement and I will finish soon a other one named For a better economic justice with in the Wikimedia movement. I would like to translate this two works in English before Wikimania for sharing the contain with the whole community and maybe inspire discussion during the week. I didn't have time and competence to do it my self before Wikimania. Is that in this forum any person who can help me, starting translation or pointing a place where I can found this kind of help ? Thanks in advance Lionel Scheepmans ✉ Contact (French native speaker) 15:19, 21 June 2016 (UTC)

Ok, never mine. I've found a trick system to present my works in english thanks to google : For a Fair Economy in the Wikimedia movement and Ethical Drifts in the Wikimedia movement. A nice day for every one. Lionel Scheepmans ✉ Contact (French native speaker) 21:13, 21 June 2016 (UTC)

The slowness of Wikipedia:Move review

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

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

Review of RfC implementation requested

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

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

Deprod by nominator

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

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

Notice about potential overhaul to MOS:TV

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

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

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

MOS:TITLE: Classical Music: Minor/Major Works

Hi all, please can you take a look at Talk:Wedding Day at Troldhaugen#Major Work? and give your thoughts if you get a chance. Thanks. :) ‑‑YodinT 16:01, 4 July 2016 (UTC)

Wikipedia:Request for comment/Extended confirmed protection policy

Please see Wikipedia:Request for comment/Extended confirmed protection policy for an RFC concerning the use of 'Extended confirmed protection'. –xenotalk 20:14, 4 July 2016 (UTC)

Notification of RFC for Korean MOS in regard to romanization

Should we use McCune-Reischauer or Revised for topics relating to pre-1945 Korea? Those inclined, please contribute here. Hijiri 88 (聖やや) 06:19, 6 July 2016 (UTC)

There don't seem to be specific guidelines about whether it is recommended to treat links to Commons the same way that other-language links are treated (and another editor has called me out for what I was doing). Wikipedia:Wikidata#Migration_of_interlanguage_links states that "In general, it is best to remove interwiki links in Wikipedia articles once they are associated with Wikidata." However, as the page name indicates, that recommendation is about interlanguage links only. There are already a lot of Wikidata entries that connect EN Wikipedia to Commons. Question is, is that yet the new, proven method? Is it recommended to make those Wikidata entries and remove the templates that link to Commons when they exactly reproduce a link that is in Wikidata? Sminthopsis84 (talk) 13:13, 3 July 2016 (UTC)

I would say not to remove links to Commons categories or galleries as there is not always a 1:1 link between an article subject and those pages on Commons, and a box highlighting the presence of additional media about a subject with a direct link is a conceptually (to me at least) different thing to an indirect link via a page full of dry facts and metadata about the subject where the link to Commons is neither prominent nor consistently located (and I say this as a Wikidatan). Unless and until the Commons templates can be and are generated from Wikidata (with a many-many relationship) then imo there is still a need for the local manually added templates. Thryduulf (talk) 21:50, 3 July 2016 (UTC)
Thank you, I'm convinced. Sminthopsis84 (talk) 13:24, 5 July 2016 (UTC)
What's more, a {{commonscat}} or a {{commonscat-inline}} placed in its normal spot is much more prominently located than a sidebar link; editors and other frequent readers are conditioned to expect a Commons box at bottom right, and its absence tends to indicate that there isn't a relevant Commons page, so treating a link to Commons like a link to Wikidata would be confusing. Moreover, Commons boxes/inline links should be treated like boxes/inline links for other projects; I doubt that we'll be sending Wikinews reports, Wikispecies documentation, etc. to the sidebar. Nyttend (talk) 13:43, 6 July 2016 (UTC)

Requesting comments on requested move: ESports

FYI
 – Pointer to discussion elsewhere.

The present name of the article (on a general topic, professional video-gaming competition) coincides with a commercial trademark (in that market sector).

Over the last year, there have been 6 or so requested moves and other renaming discussions at what is presently Talk:ESports, most of them poorly attended, with mostly WP:ILIKEIT votes, mis-citations of policy where any was mentioned at all, and closure reasoning problems (while only one was an admin close), resulting in the name flipping around all over the place.

I've opened a multi-option, RfC-style requested move at:
     Talk:ESports#Broadly-announced and policy-grounded rename discussion

It presents four potential names, all with some rationale outlines provided.

Input is sought from the community to help arrive at a long-term stable name for this article, based on actual policy and guideline wording, and on treatment in reliable and independent sources (i.e. not blogs or "eSports" marketing).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  15:38, 6 July 2016 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(policy)/Archive_128&oldid=1167394356"