Wikipedia talk:Wikidata/2017 State of affairs/Archive 9

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

←

Archive 7

→

The phab thread where the Wikidata description was pushed to the apps

Thanks to DJ for posting links to the usages of the description field, and the link to Apps short descriptions which in turn contains a link to this phab. That thread is infuriating. Not a thought to consult with the communities where the description field would land but hand-wringing about vandalism to Wikidata. That is one big blow off, of the fundamental deal among the communities. Jytdog (talk) 20:26, 25 September 2017 (UTC)

Small correction, that's the thread where the descriptions for mobile web were pushed to production. They had already been in Beta a bit longer (may 2015?) and were already in the app since I think either late 2014 or early 2015, not entirely sure. —TheDJ (talk • contribs) 21:07, 25 September 2017 (UTC)

Wikidata article descriptions

OVasileva (WMF), in your edit to the wikidata article descriptions RFC you said we have decided to turn the wikidata descriptions feature off for enwiki for the time being. The RFC was withdrawn on the basis of your statement. I didn't participate at the time, and It's still trying to get up to speed on the situation. However if I understand the situation correctly the only place wikidata descriptions were turned off was for browser-based mobile users.[1][2] There's clearly no meaningful difference between having it on browser-mobile, app-mobile, or wherever else.

While I understand how these descriptions can be useful, I share the other editor's concerns that it's remote content and we can't control it. Having editors place a pull of content from wikidata to an article is controversial as it is, having the WMF push bulk content from wikidata to wikipedia is rather more problematical. In addition to concerns previously raised by others, I'll like to add additional points really nail down the 'remote content' detail:

I presume it bypasses our page protections.
It's not subject to BLP and other policies. If someone is putting a problem across many articles, we can't block them from hitting endless more articles. If fact if we try to revert the wikidata edits we can get hit with the block!

I was considering reopening the RFC, but maybe you can just follow up on your statement to turn wikidata descriptions off? Alsee (talk) 08:14, 10 September 2017 (UTC)

I agree that we should either re-open the RFC or get WMF to turn the description off on all views, rather than (as they seem to have done) tendentiously interpreted the RFC to apply to as restricted a subset of those views as they could. The clear sense of the RFC (as it was going at the time) was that Wikidata descriptions should never be shown as part of a Wikipedia article. WMF's failure to disable this on Android, and their stealth measure to push it farther into the Android app (by integrating it with the editor there) are not compatible with this outcome. —David Eppstein (talk) 20:21, 10 September 2017 (UTC)

I think that RfC was pretty clear, and I do not see why we should repeat it. A broader scope RfC would probably not harm, but in order to be useful it must be prepared properly.--Ymblanter (talk) 20:42, 10 September 2017 (UTC)

I think it was clear, too, but given that WMF is still acting against what I think was its clear consensus, how do you propose to stop them? —David Eppstein (talk) 20:56, 10 September 2017 (UTC)

"Stopping them" would mean in any case citing an RfC, and the past one should be good enough to cite.--Ymblanter (talk) 05:46, 11 September 2017 (UTC)

Hello, Thank you for pinging me. First, I would like to apologize for the obvious misunderstanding on the original RfC. The original RfC referred to the "mobile views of en-WP pages". My team understood this to mean the (actual) mobile view, not the individual Wikipedia apps for Android and iOS. We weren’t trying to mislead anyone with our statements. We simply didn’t even consider that the conversation could also pertain to the apps, which are not what we call "the mobile view" and where descriptions have been a part of the feature set for more than two years.

The RfC stemmed from a conversation around potential vandalism on the mobile website, a couple of months after this feature was enabled for the mobile view. Similarly, in our original reply to this conversation, we only considered and addressed the behavior of the mobile website, as seen to our references to the state of the mobile website at the time - positioning of the infobox, tests performed solely on the mobile website, etc.

The Readers team (not just web) are thinking about this very seriously right now and appreciate your concerns. I wanted to address the nature of the misunderstanding while we brainstorm next steps for the future of the feature on the different platforms. We will be posting more updates soon. OVasileva (WMF) (talk) 18:05, 11 September 2017 (UTC)

OVasileva (WMF), Thanks for the reply. There may be a bit of grumbling and roaring from the community side, but it will calm down pretty quick if there's a positive followup. All of the issues involved apply equally wherever the content appears, so people are pretty surprised by the situation.

On a side note, this really emphasizes the extremely low visibility mobile-only content to the core community. We can't even attempt to patrol it when so many of us never even saw that it was still being served. The only time I see anything mobile is when I view a mobile URL via desktop for some rare reason. Alsee (talk) 03:05, 12 September 2017 (UTC)

OVasileva (WMF), a hasty followup would be helpful. The roaring here escalated faster than I anticipated. Alsee (talk) 04:59, 12 September 2017 (UTC)

Hi Olga, just wanted to apologise. I predicted a different interpretation would be made by WMF and I failed to explicitly point out this different interpretation to you and other WMF'ers as the RFC closed, which indirectly is causing further grievance and stress to all. —TheDJ (talk • contribs) 14:17, 12 September 2017 (UTC)

Meanwhile... here we are, over two weeks since this we clarified that yes, we did indeed mean descriptions in google and android mobile views, and not just the app ... and the Wikidata descriptions are STILL THERE. Did the WMF think we wouldn't want follow up on this? Blueboar (talk) 12:30, 26 September 2017 (UTC)

Wikidata and the English Wikipedia's stylistic integrity

A sizeable number of en.WP editors have put considerable time and effort into harmonising the site's formatting and linguistic style. These are set out in WP:MOS, and of particular relevance to Wikidata, WP:MOSNUM and WP:MOSLINK. These guidelines (there are many) have evolved through discussion and debate on the associated talkpages, such as WT:MOS, WT:MOSNUM, and WT:MOSLINK.

en.WP stylistic expectations differ significantly from those of other language-WPs, which (tell me if I'm wrong) are considerably less cohesive in these respects. There are several historical and practical reasons that consistency of style and formatting are taken so seriously on this site. From what I know, Wikidata is being generated by developers and programmers somewhere in the German chapter's Berlin offices. There is utterly no communication by its creators with the en.WP community on matters of style and formatting.

I do not believe any Wikidata outputs should go live without such communication. This is particularly urgent because Wikidata outputs will not, presumably, be editable by the community. We will be stuck with what is cooked up in a Berlin basement by a largely German-speaking crowd that has no specific engagement with our community. Tony (talk) 09:58, 24 September 2017 (UTC)

Wikidata is a wiki. Its code is being generated by developers and programmers, just like Wikipedia's is. We can format content we import from Wikidata any way we want. If you have a point, please make it. What you said seems completely irrelevant to me. —Kusma (t·c) 10:16, 24 September 2017 (UTC)

That doesn't seem like a satisfactory answer. Wikidata is being developed quite separately, in another language space, without regard to the integrity of the formatting and style that has developed over the past 14 years in this English-language environment. What we need is a guarantee that we will be able to edit Wikidata's displays on en.WP so that they harmonise with our established norms. I see no protocol for this. There will be no warnings, and no integrated technical–style system. Like the unfortunate history of innovations by WMF techs, I can see this leading to degredation and friction. It should be managed properly. Tony (talk) 10:22, 24 September 2017 (UTC)

@Tony1: It's a wiki. There's an edit button. The content isn't developed by the developers in Berlin, but by the community worldwide.

As for the look and feel of the mobile app, that is with the Reading team working out of San Francisco, in the same way that they manage the various officially-supported skins for desktop Wikipedia. Jheald (talk) 12:00, 24 September 2017 (UTC)

Among the most-discussed items on this whole talk page are description fields, which are natural language (like some other but not most data in WikiData). It's an obvious concern and a real problem that this material can be written in a non-encyclopedic tone, using incorrect punctuation, a mish-mash of North American and Commonwealth English, style markup that makes no sense, markup that introduces accessibility problems, the use of CSS classes that don't even exist on this site, and insert 50 more similar issues – and that any attempt to make it conform to en.wikipedia standards can just be reverted because our standards are not required at WD. The only way around this I can think of right now is that it isn't going to be good enough to have this data just be keyed by language. It's going to have to be keyed by project. I.e. en isn't good enough; there's going to have to be en.wikipedia, simple.wikipedia, etc., with each different variant of a datum subject to the policies and guidelines of the site to which it pertains. Once you have that, it's unclear what the benefit could be of using WikiData. WD may really be more suited to specific purposes that are mostly tabular data that don't vary by language, like dates of issue of films or automobile models. Even then, it's only going to be useful for the Wikipedias if the sourcing standards of the most stringent one (probably en.wikipedia, though I'm not certain of that) apply to the data. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 11:38, 24 September 2017 (UTC)

PS: One potential way to address this would be a Data: namespace on each project (its name translated as needed) in which the data really lives, subject to that site's policies, including access level that prevent noobs and anons from vandalizing it. WikiData would then import this data and make it available. This would be like a distributed version control system like Git. A user with sufficient access at, say, nl.wikipedia could decide that the en.wikipedia version of a datum is properly sourced per nl's policies, import the en version, translate it (if necessary – it might just be numeric data) and enrich the database with a new nl entry in the same table. No one at WikiData, or any other project, would be able to change the nl.wikipedia data (except maybe a WD admin, to, e.g., fix a coding error or some other technical problem). A site like simple.wikipedia could even have a blanket rule to mirror all en.wikipedia entries with an option to selectively override them locally. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 11:48, 24 September 2017 (UTC)

@SMcCandlish: To clarify on one of your points: what is held in the description field is pure text. There is no mark-up, no CSS. There is rarely punctuation. Choice of spellings or vocabulary, per WP:ENGVAR, could conceivably be an issue; though it is technically possible to hold variant descriptions for different varieties of English (eg en-gb). Jheald (talk) 12:07, 24 September 2017 (UTC)

That still won't address many en.wikipedia MOS concerns like MOS:TONE, MOS:WTW, MOS:NUM formatting considerations (it's "3 cm" not "3cm"), etc. The very fact that it doesn't support markup may itself be problematic and illustrative of the problem (e.g. binomials like Homo sapiens and book titles like War and Peace always go in italics, and so on). — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 12:52, 24 September 2017 (UTC)

The inability to provide markup in names and descriptions is definitely a problem for technical subjects such as mathematics where some objects cannot be correctly named without markup. —David Eppstein (talk) 19:30, 27 September 2017 (UTC)

I concur with SMcCandlish and others that have previously mentioned it: It is very difficult to see a way out of this, since when you push to the Wikidata side, you end up with Wikidata doing the Wikipedias work, without a proper physical support, nor the accumulated knowledge, competences and capabilities of the various Wikipedia communities. If you push to the opposite side, you end up with some aberration where the Wikipedias extend into Wikidata, forcing part of their work to be done there, without any gain at all. And anything in the between is an undesirable chimera - nor meat, nor fish - with the worst of both worlds. It seems that what is being proposed here, with the "descriptions" issue, but also with infoboxes, lists and other information being generated straight from Wikidata, and appearing and being presented in a way supposedly "finished for consumption", is indeed a corruption of what Wikidata apparently should be, a raw data source. I believe it's time to stop all those experiments that exceed Wikidata capabilities, and concentrate on what it could be really useful for - See SMcCandlish above, statistical data importation by bots from the original sources (but blocking IP and newbie editorial access to them), and such kind of things which could turn Wikidata into a truly and indisputably useful project, instead of being perceived as an invading pest, as they are now.--DarwIn (talk) 12:23, 24 September 2017 (UTC)

At one of the wiki conferences I went to, there was a presentation on the use of WD for statistical data (e.g. sports stats), and I was excited by the possibility of taking all the data on thousands of breeds of domestic animals and what their points of conformation are according to (sometimes conflicting) breed registries, and putting that in a WD database (though with markup being possible; if something should be italicized or superscripted or whatever [in English] then it should be regardless where the data "lives"). Even that kind of raw-data use raises some sourcing issues, but they seem surmountable. We already have templates here, today, pulling similar data down for sports and other topics. That seems like what WD would, could, should be used for, not natural-language summaries/descriptions of topics. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 12:57, 24 September 2017 (UTC)

I have said this before, but it is worth repeating... There is a fundamental disconnect here. The good folks at Wikidata are thinking of all this in terms of editing code and manipulating data... while those of us here at Wikipedia are thinking of all this in terms of editing text and presenting information. While these two things interact (you can't edit text without the coding to make it all work) we are fundamentally approaching the issue from different viewpoints. We are talking about different things. Blueboar (talk) 13:08, 24 September 2017 (UTC)
Yarp. Another way of looking at this is that just because a tool exists and might do some good doesn't mean either that it's useful for everything someone might think of ("don't try to drive a screw with a hammer"), nor that it will be used everywhere it could be helpful, or even be deployed at all. As for the last point, anyone familiar with the resistance met by Nikola Tesla, Preston Tucker, and R. Buckminster Fuller understands this and that it's largely a socio-political matter not a technical one. Politics applies at all levels of human interaction, and is readily apparent in projects like this. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 15:20, 24 September 2017 (UTC)

I want to second Tony1's call for establishing a space of communication on these issues. I suggesting making it as Wikipedia:Wikiproject Wikidata. Think of it as an embassy for Wikidata material to make sure it's properly sourced and expressed when placed on Wikipedia. And to put RfC before replacing major bits of Wikipedia functionality with Wikidata-sourced variants. There are a lot of benefits for some of this data, but also a lot of valid concerns. Approaches need to be worked out that are understandable and editable from the Wikipedia side. Be bold / Move fast and break things isn't the right approach here.--Carwil (talk) 16:00, 24 September 2017 (UTC)

I'd say that when a project is more than 5 years old and when wikidata descriptions have been in use for almost 2 years in various different forms that this hardly fits the description of "Move fast and break things". —TheDJ (talk • contribs) 12:47, 25 September 2017 (UTC)

User:Carwil, yes. I wonder why we find out about things post hoc—why there isn't a centralised noticeboard, a point of contact with those who run Wikidata, where are scrutiny in advance is invited. Tony (talk) 13:59, 27 September 2017 (UTC)

Do you mean something other than Wikidata:Project chat? If you want to talk to Wikidata folks, the best place to go is where they are at. Same could be said if one is trying to talk to English Wikipedians. :) I like the embassy/ambassador approach and agree some outreach is needed. Not sure if Yet Another Talk Page is a discoverable solution. CKoerner (WMF) (talk) 15:25, 27 September 2017 (UTC)

Yes, I mean something about the use of Wikidata on Wikipedia. It would actually be nice to see what Wikidata uses are being done, and done well. It would be a place to hold the RfC's that multiple people are suggesting in this conversation. And it would be a place to centralize discussions about conceptual issues with major projects, e.g., WikiCite. Maybe d:WikiProject Source MetaData is supposed to play the latter role, but right now, far more detailed conversation is happening at Wikipedia:Templates_for_discussion/Log/2017_September_15#Template:Cite_Q with many concerns and constructive criticisms being made, all of which will disappears from WikiCite project folks as soon as the discussion is resolved.--Carwil (talk) 17:06, 27 September 2017 (UTC)

WP:VPT? --Francis Schonken (talk) 17:14, 27 September 2017 (UTC)

That's a suggestion, but, in my humble opinion, the clutter level is even worse there, and it doesn't get these discussions onto the watchlists of people working to build Wikidata functionality on en.wikipedia. Now if Village Pump discussions had project tags or "follow this topic"/"follow this thread" functionality, it would be another story.

Diplomatically, I'm talking about creating some common ground for discussion. Its clear from discussions at wikidata:Wikidata:Project_chat and the Wikidata Community Facebook page that the prevailing feeling from that community is that spaces like this page are simply too hostile to be worth engaging, and yet the need for dialogue and for workshopping new templates/data uses continues.--Carwil (talk) 17:35, 27 September 2017 (UTC)

Carwil, embarrassingly I didn't notice your redlink above. Wikipedia:WikiProject_Wikidata exists! :) CKoerner (WMF) (talk) 18:01, 27 September 2017 (UTC)

As a WikiProject it could only generate "local" consensuses (see the WP:CONLEVEL policy: "... unless they can convince the broader community that such action is right, participants in a WikiProject cannot decide that some generally accepted policy or guideline does not apply to articles within its scope. WikiProject advice pages, information pages and template documentation pages have not formally been approved by the community through the policy and guideline proposal process, thus have no more status than an essay"). WP:RfCs on this project's talk page could up the consensus level sufficiently, but still seems less desirable than WP:VPT. --Francis Schonken (talk) 18:18, 27 September 2017 (UTC)

Looks like a valid point. However, wherever the matter is discussed, it will be missed by some people, as there is too much going on to follow everything, even if one wanted to. WP:VPT also may not be the ideal place as this goes way beyond technical. Maybe a WP:Village Pump (InterWiki Cooperation) would be appropriate? · · · Peter (Southwood) ^(talk): 06:36, 30 September 2017 (UTC)

An alternative, possibly even a solution.

WMF stops / removes all imposed Wikidata descriptions from English Wikipedia displays and adds a maintenance template requesting a short description on those articles where one is needed. (request a bot run through the proper channels for this, and include a link to the specifications for a short description in the template)
Wikipedians work their way through the backlog and add a suitable short description to the template which will display on both mobile and desktop, will show up on watchlists, and can be bot harvested to Wikidata if they want them.

Result:

Wikipedians retain control of Wikipedia content. → Wikipedians are happy
WMF get to display the short descriptions → WMF is happy
Wikidata gets more useful data if they want it, and can use it how they want. → Wikidatans are happy
Data is moving in the right direction → from people who will curate it, to a database where anyone who wants to use it has access
Nobody is treading on anyone else's turf → no turf wars, we can get back to our usual internal strife/creative productivity/whatever we usually do to build the encyclopaedia/database/software systems
Probably some Wikignomes will find this a great way to spend their time.
There may be live eyes on some seldom seen articles which get other problems tagged during this process.
I for one would make sure that all the tagged articles in my primary projects get a decent short description. This may happen for other editors on other WikiProjects too.

What have I missed? · · · Peter (Southwood) ^(talk): 14:42, 29 September 2017 (UTC)

Wikipedia articles massively spammed with the request editors should do something they are, more often than not, not interested in → Wikipedians not happy (there have been examples of sizeable portions of the Wikipedia community massively protesting against spammings that weren't even half as bad). In sum, the bot operation you propose would never get approval. --Francis Schonken (talk) 15:30, 29 September 2017 (UTC)

The tag does not have to display obtrusively. It would be requesting a non-urgent fix. It would not have to display at all except in edit mode and as a maintenance category at the bottom of the article. But you are right, it may well be rejected out of hand. Perhaps there will be a better suggestion, which also does not throw the baby out with the bathwater. · · · Peter (Southwood) ^(talk): 18:42, 29 September 2017 (UTC)

I have difficulties understanding: Is this the same solution I proposed above, and if not what are the differences?--Ymblanter (talk) 18:47, 29 September 2017 (UTC)

Ymblanter, It could be, it is becoming difficult to keep track of what solutions have been proposed as this discussion is developing rapidly. If it is, then read the above as support for your proposed solution, possibly with a few additional suggestions. After all it is sufficiently simple and obvious for more than one person to have come up with independently. Cheers, · · · Peter (Southwood) ^(talk): 06:14, 30 September 2017 (UTC)

I actually pulled up the Wikipedia iOS app and did a couple searches to see for myself these descriptions in action. One thing I noticed is that sometimes "Wikipedia disambiguation page" is a helpful description: Sun Sheng is a dab page without "(disambiguation)" in the title, so the description is useful there. So too for Richard Spencer. I saw a number of pages where the description was "Redirected from: (some redirect)", which is singularly unhelpful and undermines WP:PRIMARYTOPIC. Personally I was pleased to see that Jared Taylor's description read in full "American white supremacist", but I have to wonder what the lag time would have been in changing the description had this discussion closed differently (or this one or several others in a similar vein). A few years ago we decided to downcase "Dynasty" in Chinese dynasty names ("Han Dynasty", "Qing Dynasty", &c.) to "dynasty", but I saw more descriptions using the old uppercased term than the current downcased one, which leads me to believe the descriptions are seldom updated. My iOS device is rather an old one, with a smallish screen, and if there was an image displayed in the search result, the description was truncated to roundabouts 35 characters, which indicates we're going to have to do a lot of work bot-editing our lead sentences down to a usable size if that's the route we end up going with these descriptions. Apologies if this comment is in the wrong section: not sure where to post it since it seems there are four or five ongoing discussions. Any editor is free to move it. Snuge purveyor (talk) 09:33, 30 September 2017 (UTC)

Wikidata descriptions of Wikipedia pages: How much work to improve them?

So, as a test, I chose 30 pages from early on in my watchlist and looked at their Wikidata descriptions:

13 were blank (no description), so I added them to Wikidata
6 had perfectly adequate descriptions that I couldn't improve
7 had adequate descriptions that I did improve
1 lacked a description but mapped to a Wikidata item with a (correct but) different title than the Wikipedia article, thereby explaining it a bit
2 had descriptions that mirror the title, and therefore should have the description made null on Wikipedia
1 was incorrectly described (as a Wikimedia list article, for no clear reason)

Here's the list:

Sample Wikipedia page descriptions
Wikipedia Article	Wikidata Description	Changed to…
0.999...	Yreal number that can be shown to be the number one
1033 Fez massacre	—	massacre of Jews by the Banu Ifran tribe
1660 destruction of Safed	—	reported destruction of a Jewish town
1948 Palestinian exodus	—	mass departure of refugees from Palestine
1968 Polish political crisis	—	dissident political mobilization, state repression, and anti-Jewish campaign
1971 May Day Protests	—	mass civil disobedience protest against the Vietnam War in Washington, DC
1982 Hama massacre	NWikimedia list article [inaccurate]	repression of protest movement by the Syrian government
1st Plurinational Legislative Assembly of Bolivia	—	term of Bolivia's legislature, 2010 to 2015
2002 Venezuelan coup d'état attempt	Venezuelan coup attempt of 2002 [redundant, should be null on en.wiki]	unsuccessful military coup attempt in Venezuela
2003 invasion of Iraq	start of the conflict known as the Iraq War [could be improved]	military invasion led by the United States
2006 Lebanon War	Ymilitary conflict between Hezbollah and Israeli forces
2006 Oaxaca protests	protest [could be improved]	political mobilization demanding the resignation of Oaxaca Governor Ulises Ruíz Ortíz
2006 youth protests in France	—	protest movement opposing changes to labor law
2008 unrest in Bolivia	—	political crisis between departments demanding autonomy and national government
2011 Bolivian protests	—	protest mobilization defending the Isiboro-Sécure National Park and Indigenous Territory
2014 Israel–Gaza conflict	YWar fought between the Israel Defense Forces and the Hamas-governed Gaza Strip during 2014
2017	Yyear
2017 Aleppo suicide car bombing	—
2017 Women's March	Yworldwide political rallies for women's rights
2017 Nangarhar airstrike	on 13 April 2017, a GBU-43/B Massive Ordnance Air Blast bomb was dropped by the United States in the Nangarhar Province of eastern Afghanistan to destroy tunnel complexes used by ISIS [sentence fragment from enwiki lead sentence]	United States attack on tunnel complex with massive bomb
20 March 2003 anti-war protest	—	coordinated international protests against the US-led Iraq War
21st century	Ycentury [redundant, should be null on en.wiki]
Administrative divisions of Bolivia	[none, but maps to Wikidata item "administrative territorial entity of Bolivia"] [should be null on en.wiki]
Adolfo Chávez	Bolivian politician [could be improved]	Bolivian politician and indigenous leader
African Americans	ethnic group of Americans [could be improved]	racial or ethnic group in the United States with African ancestry
Agency for the Development of Macroregions and Border Zones	—	Bolivian governmental agency
Akha people	ethnic group [could be improved]	ethnic group in southeast Asia
Al-Bireh	city in the West Bank [could be improved]	Palestinian city in the West Bank
Alain Chartier	French poet [could be improved]	French poet and political writer
Alaska National Interest Lands Conservation Act		United States law establishing protected areas in Alaska

None of the descriptions, even the incorrect one, caused any policy-based problems or were the result of vandalism or mischief. Changing the Wikidata descriptions was minimal hassle (although a tool to accomplish this in batch for my watchlist would be great). Cases where a complete description is the same as the title could be rare. So could cases where Wikidata's needs are at variance with the Wikipedia description could be rare as well ("administrative divisions" / "territorial entity" case was the only example here).

Unlike some people who just don't like Wikidata, I'm happy to have my improved descriptions appear on Wikidata. And I think having these descriptions there improves Wikidata (see my comments about being neighborly above), so I hope that whatever solution we come up with enables this kind of editing.--Carwil (talk) 17:50, 2 October 2017 (UTC)

Pointlessly and disruptively removing infobox content from pages

See this example diff where Mike Peel removed all of the infobox content from the page. Not only was there exactly zero benefit in the edit, it trashed the ref in the reflist, it replaced a good recent lead image with an older image partly obscured by banners, and it replaced a useful map with an essentially useless map. Note that trying to view the old version of the page no longer shows most of the damage, because with Wikidata you can't see what was on the page at the time. Changes made at wikidata silently rewrite the history-view of the article here.

The fundamental problem is the pointless and disruptive removal of the infobox content from the page. The fact that the edit did multiple-damage to the article just highlights the blind and disruptive crusade here. The edit didn't even attempt to improve the article, other than the tunnel-vision goal of pushing Wikidata itself. Alsee (talk) 18:57, 29 September 2017 (UTC)

You do realize that by writing the second paragraph you fail to assume good faith, right?--Ymblanter (talk) 19:09, 29 September 2017 (UTC)

The differences between your version and Mike Peel's most recent version seem to be (at this moment in time):

In your version the images are smaller
In your version, the page number for the numbers of visitors reference is given
In Mike Peel's version, the user can switch between two different maps (or both)
Mike's version includes the explanation "Brazilian Portuguese" for the original name
Mike's version contains the fairly useless "Type: art museum".

You seem to be complaining about him first trying a Wikidata infobox while Wikidata's data was inferior to what we had here, then fixing that after you reverted his infobox conversion. It does look like constructive editing to me, not harming Wikipedia while improving Wikidata. Mike politely asked for feedback on the talk page and you shot him down. I can only assume that your anti-Wikidata crusade is clouding your judgment here. Please stop assuming bad faith in this way, it is disruptive. —Kusma (t·c) 19:28, 29 September 2017 (UTC)

I appreciate the feedback on the template (which is a new one, this was partly a test of how well it works). I made a mistake in not developing the template more before using it in the article, and I apologise for that. Improvements can continue to be made to it. Let's continue discussing this instance on the talk page of the article. Thanks. Mike Peel (talk) 21:16, 29 September 2017 (UTC)

Ymblanter and Kusma, I am unsure whether I wrote unclearly, or whether you misread what I wrote, or whether you both misunderstand AGF. Something can be simultaneously 'good faith' and harmful. I said The fact that the edit did multiple-damage to the article just highlights the blind and disruptive crusade here. The edit didn't even attempt to improve the article, other than the tunnel-vision goal of pushing Wikidata itself. Calling it a crusade almost per-se asserts it was 'good faith'. Mike believes converting Wikipedia to Wikidata is good. In tunnel-vision pursuit of that goal, the edit caused multiple downgrades to the article while providing zero benefit. However the downgrades to the article are incidental. The real disruption was stripping out all of the infobox contents. Alsee (talk) 16:22, 3 October 2017 (UTC)

"Pointless and disruptive removal" does not really sound like assuming good faith.--Ymblanter (talk) 16:29, 3 October 2017 (UTC)

I hope you don't apply that view to the block button. Just because someone has a bad idea does not make them malicious. Alsee (talk) 18:27, 3 October 2017 (UTC)

I am not talking about Mike's first edit where he introduces the Wikidata template, but about the entire interaction. At this moment in time, it can be argued that Mike's infobox is superior. The summary of your complaint is: Mike tried something out, then listened to feedback and fixed what mistakes he made, and actually improved things. All of these are good things (especially in the combination), and I find it difficult to understand how you can call this whole thing "pointless and disruptive". WP:BRD is how we do things around here, and this seems like a good example. —Kusma (t·c) 19:26, 3 October 2017 (UTC)

Kusma, your "summary" of my words was inaccurate. As I said twice above, my complaint was the intentional stripping of infobox contents out of the article. As I said twice above, the accidental downgrades were "incidental" and "just highlight" the disruption of pointlessly stripping the contents out of the article.

There's not a lot of space in an editsummary box, so after my first edit I can understand how Mike could focus on the accidental issues and then repeat the objectionable edit. However now I see Mike has been running around a lot of articles making a lot of edits that have no purpose other than to strip infobox contents out of articles. I think we're going to need an RFC:

Is it appropriate to strip infobox content, if the result is to display roughly equivalent Wikidata results? (What Mike has been doing.)
Is it appropriate to fill or restore infobox contents, if the result is to display roughly equivalent local results? (What I haven't done yet, but I am considering.)
If someone wants to improve an article, and they find the local content has been stripped, and they find it harder/more_confusing to edit wikidata, or if they simply dislike/decline to edit wikidata: can they be forced to make their positive contribution via Wikidata? Or can they restore the local content so they can make the improvement locally? (What I did.)

Regarding #3, I doubt there's going to be much sympathy for the idea that people can be forced to make their improvement via Wikidata. Given the faint line between a "neutral edit" and an "improvement edit" I don't see much chance we are going to ban #2. And we pretty much need to rule out either #1 or #2 to prevent pointless cycling back and forth. Alsee (talk) 21:35, 3 October 2017 (UTC)

Infobox content is article content, and as such must be controlled by English Wikipedia guidelines and policies. Moving it to Wikidata removes that control. So when there is a dispute over where the content should be, the resolution to the dispute must always be to keep it on the Wikipedia side. —David Eppstein (talk) 21:39, 3 October 2017 (UTC)

@Alsee: All of the Wikidata infoboxes I've been working on still work exactly the same way as they did before for local parameters - you can define the local parameter as normal, and it will be shown in preference to the Wikidata one. I haven't 'just' been moving content over, I've also been checking/formatting/expanding it, the same way you might copyedit and work on an article. I personally can't see the point of defining the content both here and on Wikidata, though, as if you're going to improve one copy then why not improve both, and the info on Wikidata can be improved in any language. And @David Eppstein: when did enwp become so controlling, will we be like Brittanica soon and need only expert editors? I agree that a new RfC will be needed at some point soon, though (the earlier one was before we had any examples of this actually working in practice). Thanks. Mike Peel (talk) 21:45, 3 October 2017 (UTC)

Truly? "All of the Wikidata infoboxes I've been working on still work exactly the same way as they did before for local parameters"So, at the World Heritage Site infobox, if I use local parameter "Session" and leave it blank, I used to get the pointless "( Session)" link before you started tinkering with the template? And "| Type = Cultural", which now gives no result in the infobox, never did? Or did this only stop working after you started working on the template? Let's see, the "Name" local parameter currently has no effect whatsoever on the infobox. Was this the case before you started "improving" it? The "website" parameter no longer worked with local values until I remarked this last week. If you want to defend yourself here, it would help if you gave correct information and not some self-serving distorted version of the facts. Fram (talk) 07:16, 4 October 2017 (UTC)

Perhaps I should have caveated that with "bugs aside". I fixed the website parameter as quickly as I could after you pointed it out (and thank you for doing so). The "Name" and "Session" parameters worked fine, but I've added support for the lower case versions now too. I've also fixed the Type parameter. All you had to do was to point out the problems, the snide comments aren't necessary. Mike Peel (talk) 23:06, 4 October 2017 (UTC)

@David Eppstein: Wikidata is not something alien, it is an integral part of the whole just like the Commons is. We can help shape Wikidata's policies if we like, just like we can participate in debates in Commons. Just because something has a different URL doesn't mean it has to be "us versus them". On a personal note, I currently live in a country that is trying to "take back control" (which is stupid) and I very much hope we don't fall to the same "borders are good, we can't trust those foreigners with any of our data" nonsense in this virtual space. —Kusma (t·c) 08:32, 4 October 2017 (UTC)

Kusma, you might look at exchanges like this or this, and many other similar examples. Nikkimaria (talk) 14:36, 4 October 2017 (UTC)

I am not sure why you cited me in this respect. Do you support canvassing? I hope not.--Ymblanter (talk) 14:41, 4 October 2017 (UTC)

@Alsee: (ec) I think I finally understand your point. By "the article" you appear to mean "the source wikitext of the article in the edit window". I mean "the displayed article that our readers see", and fail to see how the removal of one page number qualifies as "intentional stripping of infobox contents out of the article". I believe that Mike's experimenting with this is a good idea, and I can't see how yet another RFC could improve things at this point. —Kusma (t·c) 21:51, 3 October 2017 (UTC)

Kusma the point of the RFC would be either to prevent people from running around removing infobox contents from the wikitext, or to prevent people from running around restoring infobox contents to the wikitext. It's doubly-wasted work if people run around just nullifying each other. Alsee (talk) 00:01, 4 October 2017 (UTC)

Such an RfC has already been run on de.wikipedia: Wikipedia:Meinungsbilder/Nutzung von Daten aus Wikidata im ANR. According to this removal of local content is admissible. You can only use wikidata content with external references and only via templates (such as infoboxes). --HHill (talk) 12:31, 4 October 2017 (UTC)

Interesting. Do you speak German? Could you keep us abreast of the outlines of what's happening there? Tony (talk) 13:35, 4 October 2017 (UTC)

It's my native language. I don't keep an eye on current wikidata usage on dewiki. There is a dedicated Wikiproject: de:Wikipedia Diskussion:WikiProjekt Wikidata in Wikipedia. Most in depth discussions are a few years old. --HHill (talk) 14:02, 4 October 2017 (UTC)

My read of that (in bad German on my part) is that for example, to use a wikidata-drawn item in an infobox, you would need to also provide a reliable source (by DEWP's policies) onwiki - you could not use wikidata info with a source provided at wikidata correct? Only in death does duty end (talk) 14:15, 4 October 2017 (UTC)

Actually, it seems like that RfC does allow for sources on Wikidata. Unsourced Wikidata data and Wikidata data sourced to other projects aren't enough. That's going by the sections that begin with Bedingung B: Das Einbinden von Wikidata-Daten ist nur zulässig, wenn dazu ein externer Beleg vorhanden ist and Belege. deWiki also have in that "Belege" section a module that appears to transclude the Wikidata citation to dewiki, seems like. Jo-Jo Eumerus (talk, contributions) 14:50, 4 October 2017 (UTC)

Ah, so as long as the source on wikidata is compliant with DE policy, it can be transcluded from Wikidata? That was the bit that was eluding me. It does look like though DE has had almost the exact same issues with wikidata sourcing that EN has. Only in death does duty end (talk) 15:06, 4 October 2017 (UTC)

Aye (paragraph break because of the excessively wide indentation), although they seem to state that some types of vandalism are easier to catch on Wikidata than enwiki. But yeah, reliability concerns are widespread even in that RfC. Jo-Jo Eumerus (talk, contributions) 15:21, 4 October 2017 (UTC)

WP:Use of Wikidata in Wikipedia

I think we need to start drafting a guideline. I am going to start doing that over the next week or so (my plate is really full now). It will start as essay; after we get something reasonable we can hold an RfC to have it promoted to a guideline. This will be hard work but we need to establish some principles that can gain wide enough consensus (which will definitely not be unanimous) to hold.

This is much more general than the backward looking stuff about the WMF's overstepping with the description field and should help alleviate surprises and clashes in the future.....

If anybody is aware of an essay that has already been started on this, please point to it....Jytdog (talk) 19:42, 27 September 2017 (UTC)

Good idea. And we need a simple but extended how-to page that inter alia explains how Wikidata actually works in terms of the process underlying displays on en.WP. The usual reponse from en.WP editors when Wikidata is mentioned is: "I still don't know what it does or how it works. No idea." And we need a centralised noticeboard to (i) communicate with Wikidata developers/techs; (ii) communicate among ourselves on Wikidata matters; and (iii) receive advance notice of additions, functionalities, proposed roll-outs, etc. Tony (talk) 05:49, 30 September 2017 (UTC)

Also a good idea. · · · Peter (Southwood) ^(talk): 06:22, 30 September 2017 (UTC)

We desperately need a page to address new software being developed or rolled out by the WMF, and related issues. The WMF occasionally posts notices to Pump:Technical. In my opinion that is a difficult page to watchlist, and it's a lousy place for the related discussions. I am also one of the few community members actively tracking what's going on over at the WMF, and I really need a place to post discussions short of a VP:Proposal. In fact I already drafted a new Village Pump page for this purpose, and I received some minor but positive support for the idea. However my initial page-name was Village Pump WMF, and the WMF was very reasonably concerned that the title had the appearance that the page was connected to the WMF-itself. The intended purpose was "community page to discuss this topic". I had trouble coming up with a better title for the Pump page, and I let the idea slide due to the low active-support I got from others. I am more than happy to install a new Village Pump page myself, if I get some vocal support and we come up with a good title for it. I know the intended scope for the page, it's just tricky naming that scope. Alsee (talk) 03:27, 1 October 2017 (UTC)

Here's my draft from March 2016‎: User:Alsee/Village_pump_(WMF). It would only take a page move and a few minor edits to install it as new Pump page. Alsee (talk) 04:43, 1 October 2017 (UTC)

Is the proposed Pump page only for matters of WMF involvement in WP, or should it be for any external involvement? · · · Peter (Southwood) ^(talk): 05:59, 1 October 2017 (UTC)

My primary motivation was to discuss new projects being developed by the WMF, but I think the proper scope for the page is to deal with any issue which is not local to EnWiki. That would cover any non-trivial interaction with the WMF, as well as engagement with other wikis. Note that I see significant synergy between those two things. On one hand the other communities deserve a voice in what gets built for us all, and on the other hand the WMF has a bad habit of fixing something for EnWiki-and-only-EnWiki when other communities would surely want the same fix we got. Just look at this Wikidata-descriptions issue - the WMF knows there's a problem here but they just push out what they want to other wikis, because the other wikis haven't spoken up. The WMF is also in the middle of silently deploying VE as default for new users - but they set wikitext default on EnWiki-only after we wrote a javascript hack that would override it. We need more cross-community communication. Other wikis have no idea that VE is being silently imposed as default for new users. They don't know they have a choice. Alsee (talk) 12:36, 1 October 2017 (UTC)

How about Village pump (interwiki) or Village pump (external affairs)? · · · Peter (Southwood) ^(talk): 06:56, 10 October 2017 (UTC)

Draft RfC for Wikidata in infoboxes

Given the increasingly heated recent discussions about Wikidata infoboxes, I think that we need to have an RfC on this topic sooner rather than later. So, taking the plunge, I've started a page at Wikipedia:Wikidata/2017 RfC draft to draft an RfC specifically on Wikidata usage in infoboxes. It will not cover Wikidata descriptions, or other uses of Wikidata info outside of infoboxes (those would need a separate RfC). I've styled it on Wikipedia:Requests for comment/Wikidata Phase 2, as I think that format (particularly with background info and suggested options) yielded a clear consensus. I suggest that we collaboratively work on this draft for a while before we start the RfC (at least a fortnight, maybe a month or so). ~~To keep the discussion together, I've redirected the talk page here.~~ So, please be bold, but also be neutral, and help draft this. Thanks. Mike Peel (talk) 00:36, 5 October 2017 (UTC)

I don't see a clear option for requiring any addition of Wikidata to an article's infobox to be manual (with preview) rather than automated. I also don't see an option for treating BLPs differently than other infoboxes. My main concern here, by the way, is not so much quality of data or vandalism (although those are concerns) but rather Wikidata's lax sourcing standards compared to here. So it is also a concern that options 2 and 3 don't have the alternative sourcing requirements that option 4 does. —David Eppstein (talk) 01:06, 5 October 2017 (UTC)

It might be better to freeze this before it starts and reword option 2. My understanding of what it intends is that, for example, an infobox might allow entry of |area=12.3 ha. In that case, the value entered is what would be used. For some infoboxes, however, if the area value is empty or missing, the value from Wikidata would be used, if available. The key point is that data entered at enwiki would override Wikidata. Another consideration is that an infobox should limit what it displays. For example, there have been many heated discussions about whether a religion should be displayed in a person's infobox—I believe the current consensus is that such labels should not be displayed but instead should be discussed in the article when appropriate because that would allow clarification of the meaning and significance of the religion for that person. The current wording of option 2 would allow editors to add anything which exists in Wikidata, including religion. Johnuniq (talk) 01:03, 5 October 2017 (UTC)

@David Eppstein and Johnuniq: Can you add drafts of options that would cover your points, please? Thanks. Mike Peel (talk) 01:26, 5 October 2017 (UTC)

Option 3 seems to be orthogonal to the others, and could be an option for either (with the obvious exception of #1). --Magnus Manske (talk) 07:25, 5 October 2017 (UTC)

At present, an editor creating a Wikidata-aware infobox has the following options available to them as documented in Module:WikidataIB:

A locally supplied value overrides the data fetched from Wikidata by default (although it is possible to switch this off, it's not recommended).
Each field is only supplied from Wikidata when that field is specifically enabled in each article – the default – ("opt-in"), or the field is automatically enabled ("opt-out"). There is a simple option to enable all of the fields in an infobox on a per article basis, rather than having to make a list of available fields ("whitelist").
Any field may be completely suppressed from display – even the local value if desired – on a per article basis ("blacklist").
A value for a field is only supplied from Wikidata when that value is sourced, and sourced to something better than "Imported from Xyz Wikipedia" – the default – or all available values may be displayed.
A linked edit icon ("Edit this at Wikidata) may be displayed after each field where data has been retrieved from Wikidata, or the infobox may contain a single [Edit at Wikidata] link at the bottom (or neither or both).
Where multiple values are returned, they may be displayed as a comma-separated list (default), a horizontal list (MOS:HLIST), or an unbulleted list (MOS:VLIST).

Other options are available using other Lua modules, for example Module:Wd enables the retrieval of the raw references from Wikidata. Work is in progress (e.g. {{Cite Q}}) to consolidate the format of references with the CS1/2 styles of citation templates.

I think that commentators ought to be aware of what is possible now, and cognisant of the improvements made to meet users' wishes since the last RfC in 2013. I see no value in re-hashing old chestnuts like "... permit Wikidata inclusion only when there is no existing English Wikipedia data for a specific field in the infobox" because that's nonsensical in absolute terms. The infobox designer doesn't know what fields have existing data in them in different articles. The proper formulation is "... permit Wikidata inclusion in each field of an article's infobox unless that field has locally supplied data", and that's not even debatable. Everybody agrees with that, so why waste electrons on discussing it further? Pretty much the same goes for unreferenced information. Unless it's "sky is blue" obvious, (or self-referential like ICD), nobody is going to be asking infobox designers to display unsourced information in infoboxes. Why do we need to discuss that? Take it as a given, and keep the RfC simple and up-to-date: something along the lines of "Should infoboxes be permitted to import data from Wikidata, as long as local values override Wikidata values and all non-obvious values are sourced?" --RexxS (talk) 15:35, 6 October 2017 (UTC)

@RexxS: Would you support converting all current Wikidata-enabled infoboxes to onlysourced=yes as a default? Not all of them currently have that behaviour, not sure if all of them support that parameter. Nikkimaria (talk) 02:23, 7 October 2017 (UTC)

I set the default for onlysourced to "yes", so if it's not specifically set to "no", then it will filter out unsourced info by default. Generally, I agree with you completely, but there are a few fields where we wouldn't expect sourcing, like an ICD code or a commons category which are effectively self-referencing. But apart from those, I think that every Wikidata-aware infobox should support the onlysourced parameter, and have it default to yes. For infoboxes using Module:WikidataIB it's usually as simple (!) as adding |onlysourced={{{onlysourced|}}} to each appropriate field in the infobox design. That will give an editor who is keen on this sort of work a chance to preview an infobox with onlysourced=no to see what fields in Wikidata need sourcing, and hopefully go a little way to improve the lamentable state of sourcing in Wikidata. As an aside, when I want a reality check, I sometimes paste {{#invoke:Sandbox/RexxS/WdRefs|seeRefs}} into an article and preview the result. It's inevitably depressing. But it can only get better. --RexxS (talk) 10:47, 7 October 2017 (UTC)

Please wait until we have asked the question in the RfC before making this change! Thanks. Mike Peel (talk) 14:41, 7 October 2017 (UTC)

I'm not sure it's a good idea to wait on making improvements to templates until an RfC has been posed. What do we gain by waiting? --RexxS (talk) 15:12, 7 October 2017 (UTC)

I'm not convinced it's an improvement right now. For telescopes for example, there is quite a bit of unreferenced, uncontroversial values that are used in infoboxes - changing to onlysourced now removes those. I can add references to them, but that will take me some time, so at least a bit of breathing space would be nice. Thanks. Mike Peel (talk) 15:24, 7 October 2017 (UTC)

Of course, Mike. I'm not saying we shouldn't give editors as much time as they need to improve the referencing on Wikidata where necessary. Those improvements at Wikidata are a real bonus we get from trialling the sort of upgrades you've been working on. But I think we'd all agree that we want to get to a position where Wikidata is providing only good quality, sourced data for infoboxes here – that's the improvement I want to be working toward, and I believe that enabling 'onlysourced' as widely as possible is a step in that direction. --RexxS (talk) 19:45, 7 October 2017 (UTC)

It will remain badly sourced until Wikidata starts having a culture of only allowing content with valid external (non-Wikipedia) sources, not true now. I've just been going through a collection of Wikidata records on academics with missing English articles, for instance, and a large fraction of their nationalities are either simply wrong, or too complicated for Wikidata to handle correctly (it only contains claims like "American", not "born and educated in Algeria, came to the US as a graduate student and has remained there ever since, current citizenship unknown". That's why infoboxes should only summarize article text, not be brought in from other places; in an article, we can get into the details of the nationality and summarize it in an infobox. But the summary alone is not an accurate picture, and if we get things that look like summaries from sites like Wikidata that don't even try to describe and source what they're summarizing, we're bound to get it wrong. —David Eppstein (talk) 20:04, 7 October 2017 (UTC)

@David Eppstein: To be fair, all of those facts could be coded on Wikidata, using properties like place of birth (P19), educated at (P69), work location (P937), and then setting country of citizenship (P27) = 'some_value'. There may even be rules that could be made as to how one might distill such facts to best fit into a ~36 character short description. Magnus's long description tool might already generate a sentence quite similar to the one you just gave. (cf [3])

One admitted current difficulty however is that, despite its primary label, Wikidata doesn't just use country of citizenship (P27) for "country of citizenship". At the moment it may e.g. also be the only bet for describing somebody as "Scottish" (i.e. a more detailed identity), or "Flemish" (an identity from before the current nation states)... This probably does need more thought at the Wikidata end. Jheald (talk) 21:09, 7 October 2017 (UTC)

@David Eppstein and Jheald: I think that the shift in Wikidata culture towards a harder attitude to unsourced information will happen as more English Wikipedia editors engage with the current community, driving the model away from favouring ease of input towards ease of use outside of Wikidata. Not only that, but we've had the debates about "citizenship", "nationality" and "ethnicity" here already, and we're keenly aware of the differences. That puts the onus on us to help our fellow Wikimedians make such distinctions, which eventually then become built-in to the data supplied back to us.

Of course, whenever any infobox field is too complex or nuanced to be summarised in a word or two in an article, it becomes unsuitable for inclusion in that article's infobox, which is why I've coded the ability to suppress any given field on a per-article basis. Also, when needed, with Wikidata-driven infoboxes, the choice of supplying a local value for a field will always override anything from Wikidata. --RexxS (talk) 23:01, 7 October 2017 (UTC)

Let us hope that this is the case. It's a sine qua non, in my view. Tony (talk) 08:30, 8 October 2017 (UTC)

I made a major revision of the table Options for using Wikidata in infoboxes. Here's a permalink to my proposed version of the table for examination, in case anyone reverts or revises it. I believe issues such as sourcing would have to be addressed independently of that list. Alsee (talk) 17:57, 6 October 2017 (UTC)

Note that discussion seems to be happening on the RfC page, so I've moved it to Wikipedia talk:Wikidata/2017 RfC draft (which no longer redirects here). I suggest anyone interested in discussing this topic also follows the draft page. Thanks. Mike Peel (talk) 21:44, 8 October 2017 (UTC)

- - Ummm...you might want to hold off for a bit; there's what appears to be a rather large systems issue for projects that use a lot of wikidata: Phabricator ticket. Given that the issue is so severe that it has resulted in Wikidata changes being removed (until resolution) from the watchlists of some projects that are comparatively heavy users of Wikidata - one of the big selling features of linking to Wikidata - this needs to be fixed before Enwiki can logically proceed. Risker (talk) 02:29, 10 October 2017 (UTC)
    - @Risker: Thanks for the link. As far as I can see, this doesn't affect enwp at the moment, as we aren't as heavy users of Wikidata as elsewhere, and Wikidata still appears in watchlists here. So I don't think it changes things for the current Wikidata uses here. However, it is a big concern for the future if we have a lot more articles using Wikidata. Thanks. Mike Peel (talk) 10:22, 10 October 2017 (UTC)
      I actually do see some Wikidata items on my watchlist here. How should I interpret this?--Ymblanter (talk) 11:19, 10 October 2017 (UTC)
      - It is removed from some large projects, including Commons, already, and is announced to happen on all projects. Fram (talk) 11:29, 10 October 2017 (UTC)
        
        @Fram: "is announced to happen on all projects" - where do you see that? Mike Peel (talk) 12:39, 10 October 2017 (UTC)
        
        jcrespo added a project: User-notice. "Notification for users: We are going to disable wikidata recentchanges (meaning, changes on pages on other wikis coming from changes done on wikidata; the recentchanges at wikidata is not a problem) due to performance concerns. Once those have been fixed, the functionality could be enabled again." Mon, Oct 9, 8:24 AM Fram (talk) 12:57, 10 October 2017 (UTC)
        
        Two days before, they said "The introduction of wikidata events on recentchanges has converted the "light" recentchanges table into a monolithical 500GB table:" [...] "Given all of the above, I administratively will take the emergency decision (because "things are broken)" of finding out which functionality created this issue- revert it on code and purge all new rows created." Fram (talk) 12:59, 10 October 2017 (UTC)
        @Fram: Ah, that's before they identified commons and ruwp as the main causes, it seems that they are waiting to see whether disabling it only on those projects resolves things for now. Mike Peel (talk) 13:03, 10 October 2017 (UTC)
        You seem to be confusing "causes" and "victims". There have been complaints from itwiki and dawiki as well, perhaps others I'm not aware of. Fram (talk) 13:09, 10 October 2017 (UTC)
        No, I'm seeing triage - by disabling it on the two biggest users of the feature, performance should improve for the other users. Let's see what happens, but please try to avoid jumping to a "we're doomed" conclusion. Mike Peel (talk) 13:12, 10 October 2017 (UTC)
        We aren't, you are ;-) The text of breaking Wikipedia didn't come from me but from a database administrator, the text about reverting this addition wholesale also didn't come from me. The disabling at these two is a first-step emergency measure, but I doubt that they will let a "feature" which causes this kind of problems when it gets used, active for much longer. And no, performance will probably not improve for other users, this is from my reading of that ticket on the one hand filling up the general servers, but on the other hand severely slowing down individual queries (e.g. for long watchlists and for recent changes on languages which use Wikidata extensively), and is also dependent on what is exactly changed at Wikidata (someone gave the example of their watchlist freezing when someone changed something at the item "human" on Wikidata). While they may need some time to fully investigate this, I wouldn't be too optimistic that it is solved and finished with disabling it at commons and ruwiki. Fram (talk) 13:18, 10 October 2017 (UTC)