Misplaced Pages

talk:Wikidata/2017 State of affairs - Misplaced Pages

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
< Misplaced Pages talk:Wikidata

This is an old revision of this page, as edited by DannyH (WMF) (talk | contribs) at 16:30, 2 October 2017 (→Proposal from WMF: reply to Alsee). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Revision as of 16:30, 2 October 2017 by DannyH (WMF) (talk | contribs) (→Proposal from WMF: reply to Alsee)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)


Archives
Archive 1Archive 2Archive 3
Archive 4Archive 5Archive 6
Archive 7Archive 8Archive 9
Archive 10Archive 11Archive 12
Archive 13Archive 14

This page has archives. Sections older than 14 days may be automatically archived by Lowercase sigmabot III when more than 3 sections are present.

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. 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 Misplaced Pages 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 Misplaced Pages 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)

UNREADABLE WIKIDATA REFS

There are currently 225 transclusions of Template:Cite_Q. In the article-read view it looks like a standard detailed ref. However if you try to search for the ref-text in the wikitext, you can't find it. In the wikitext it looks like this: 

{{cite Q|Q29581755}}

which renders as: 

Lois Reynolds; Tilli Tansey, eds. (2008). Superbugs and Superdrugs: A History of MRSA. Wellcome Witnesses to Contemporary Medicine. History of Modern Biomedicine Research Group. ISBN 978-0-85484-114-1. OL 23194335M. Wikidata Q29581755.

A relatively new user would have no clue what the frick is going on. And as an experienced editor with some wikidata experience, I still had no frinkin clue what was going on when I couldn't find the ref in the wikitext. I eventually found the cite Q at the ref location.

How many people even know this was going on???

My first thought was to nominate it for deletion discussion. Then I figured it probably warranted a Pump discussion. Which brings me back here, and the messy question of whether to run a narrow RFC on this wikidata issue or whether to wait for a comprehensive wikidata RFC. Alsee (talk) 05:39, 12 September 2017 (UTC)

I do not have a strong opinion either way - it could be all moved to Wikitext, or it could be left like this so that other WMF projects can use it in the same way - since this ref is unlikely to change, there is probably not much added value in sharing it between the projects. I must note however that in complex templates which we have plenty it is very often also impossible to understand where different features come from, and even going to the template code does not help. Several times I wanted to correct info (most often in articles related to railway stations) and I had to give up since I could not figure out how info could have been modified. This is approximately as usable as the Wikidata code.--Ymblanter (talk) 05:54, 12 September 2017 (UTC)
@Mike Peel: who is I believe responsible for creation of most of these citations (they are apparently coming from moving Infoboxes to Wikidata).--Ymblanter (talk) 05:59, 12 September 2017 (UTC)
I happen to think that it is a great idea to consolidate citation metadata on Wikidata, rather than copying it separately into each individual Misplaced Pages article that cites something. That way, errors, partial information, or new information in a citation would only need to be corrected once, rather than tracking down all the different copies of a citation and correcting each one separately. For instance, when I create biographies on academics it typically takes me some time to find all of the citations of the subject's works on different Misplaced Pages articles and add authorlinks for them; reducing this to once per publication rather than once per citation of a publication would be a great help. So I would be strongly opposed to ripping all this out and going back to the bad old way of doing things. On the other hand, if we could make these easier to find in some way, that could be helpful. Right now you have to notice the Wikidata Q-number at the end of the citation in the article view. But really, is that so different from the things like <ref name=":-0"/> with cryptic ref-names that we also have scattered throughout our articles?
I do have a technical question about the implementation of these citations, that I couldn't figure out looking at some of these in Wikidata. Are publication authors stored only as Q-numbers for the author identity, or are they also stored as strings describing how the author's name was written on that specific publication? For instance, The example you give has authors "Lois Reynolds; Tilli Tansey, eds." but actually if you look at the publication it refers to they are listed there as "L A Reynolds and E M Tansey". In this case the changed author spelling is relatively harmless but in some other cases where people have made more significant changes to their names (for instance, by marriage), using only the Q-number could lead to significant mangling of citations. I also wonder why the volume in the series isn't included in the article view but that's a minor and probably easily fixable bug; it's there in the wikidata. —David Eppstein (talk) 06:30, 12 September 2017 (UTC)
@David Eppstein:, I do not know the answer to your question (I rarely work with citations on Wikidata), but I am sure the answer is known. Do you want me to ask on Wikidata?--Ymblanter (talk) 10:32, 12 September 2017 (UTC)

Please nominate it for deletion and get rid of it completely. Hardly anyone is watching whether Wikidata info used in our articles gets changed at Wikidata, meaning that this is yet another inroad for unwatched changes. Basically, we are more and more becoming a mirror of Wikidata, but with a disconnect between the mirror (which is what 99% of the readers see and where 99% of the editors are) and the source (where a few people are getting their data from, but where hardly anyone watches for vandalism or other unhelpful changes).

I see that this is for example used on Template:Infobox World Heritage Site, where it creates things like Regensburg: area: . Yep, really helpful! The template has an "edit on Wikidata", but apart from the indication that yes, this is a World Heritage Site, it is not clear at all where this should be edited, or where the source (the is a source) comes from. This is extremely un-editorfriendly and no improvement at all. (In other cases, the "area" is simply the area of the whole city, not of the world heritage site, but this uses Wikidata, not a cite Q template, so is not directly relevant here, except as an indication that relying on Wikidata agian creates errors).

Another example: Povl Riis. The Q citation is for "Lois Reynolds; Tilli Tansey, eds. (2007), Medical Ethics Education in Britain, 1963–1993, Wellcome Witnesses to Contemporary Medicine, History of Modern Biomedicine Research Group, ISBN 978-0-85484-113-4, Wikidata Q29581753" but this is incorrect, the right citation is here. E.g. instead of "Wellcome Witnesses to Contemporary Medicine" it should be "Wellcome Witnesses to Twentieth Century Medicine". Normally, this is five seconds work. Now, I need to go to Wikidata, find the right item, change it: oops, I can't just change it, I need to find the right Wikidata item for "Wellcome Witnesses to Twentieth Century Medicine". It doesn't exist, so I need to create a new item. Or no, I should not do this, as apparently this is the older name for this Qitem. But how can I make it display the older name? As far as I can see, I can't. So I have no idea at all how to solve this, bar going back to a standard citation instead of this Q thing.

Probably these things can be fixed by Wikidata-gurus, but the aim was to make things easier to edit, more accessible, not that we need to rely on a few experts to change these things. Fram (talk) 07:54, 12 September 2017 (UTC)

Clearly the main thing Wikidata needs at the. moment is more documentation and improved user interfaces. Is anybody working on these or at least trying to recruit volunteers for these tasks? —Kusma (t·c) 08:42, 12 September 2017 (UTC)
How would we know, and why would we care? You can ask at Wikidata, or you can ask the 5 or so editors here who have done 99% of the intrusion of Wikidata into enwiki. Fram (talk) 08:50, 12 September 2017 (UTC)

The correct place to raise this discussion is on the talk page of the template, not here (particularly when the main editor of that template has said "I'm done here" just above this). The way it works is quite straightforward: the line being used in the infobox has a reference on Wikidata of the type stated in (P248), which points towards the Wikidata entry for the entity being referenced (e.g. a book). Cite Q then fetches the reference information from the entry for the reference on Wikidata. If you want to edit which reference to use, then you use the Wikidata links in the infobox. If you want to edit the reference, you use the link in the reference - in the example at the top of this discussion, the link is at the end, as "Wikidata Q29581755". Thanks. Mike Peel (talk) 12:01, 12 September 2017 (UTC)

In this particular case it does not work however, and I raised the question at the Wikidata Project Chat.--Ymblanter (talk) 12:06, 12 September 2017 (UTC)
The correct place to raise this discussion is at a village pump, not at some hardly known template. Asking the template editors whether they want the template or see a use for it is hardly helpful, getting outside opinions is what is needed. As for this being "quite straightforward"; as shown above, not really. "If you want to edit which reference to use, then you use the Wikidata links in the infobox." If the reference doesn't exist on Wikidata, it is much easier to simply add it here than on Wikidata. I gave an example of an actual use of this template, where I want to change the name of the journal. However, the journal already has an item on Wikidata, but this is for both the old and new name of it. I shouldn't create another item (assuming I know how) for the same subject, but I can't use the alternative name either. There probably is some solution, but if this had been a regular cite template, it would have been straightforward and easy, instead of this. I have now replaced the source at my example with something useable. Fram (talk) 12:26, 12 September 2017 (UTC)
  • Comment Meta data for refs need to go in articles. We could have a bot replace the "cite Q" with a fleshed out ref. A WD link can be added to cite journal if people want. Doc James (talk · contribs · email) 01:13, 15 September 2017 (UTC)
    • Why? That's certainly not the way I'm used to doing it in academic publishing (where the metadata goes in a separate bibliographic database from the main article text). Putting it in the article means that editors need to find another copy of it and copy it (propagating errors) or format it themselves (usually badly). Keeping it in Wikidata means that there is a single unified copy that can be cleaned up when it needs cleaning up. —David Eppstein (talk) 01:16, 15 September 2017 (UTC)
  • The problem is ease of actual editing. When using this template, what we see in edit mode is a string of meaningless numbers like "Q123456", but what we expect to see (so we can edit) is the actual text... the name of the author, the book title, etc.
Perhaps the disconnect here is that those who work at wikidata think of citations as bits of data... which can be stored anywhere and retrieved when needed. Meanwhile those who work at Misplaced Pages think of citations as text... which needs to be located on the page, and visible in edit mode in order to edit it. Blueboar (talk) 00:18, 16 September 2017 (UTC)
But as I argued repeatedly elsewhere, we have the same problem for complex templates in Misplaced Pages, which sometimes make it more difficult to correct the data even than if the data is stored on Wikidata which is one click away from every page. This was like that already when I started, I have not seen any complaints, and nobody nominates these templates for deletion because of these usability issues.--Ymblanter (talk) 08:23, 16 September 2017 (UTC)

Mainspace use: subst?

Seems very well possible to use the template in mainspace with a subst:, thus: 

{{subst:cite Q|Q29581755}}

Resulting in (without the TfD tag): 

Lois Reynolds; Tilli Tansey, eds. (2008). Superbugs and Superdrugs: A History of MRSA. Wellcome Witnesses to Contemporary Medicine. History of Modern Biomedicine Research Group. ISBN 978-0-85484-114-1. OL 23194335M. Wikidata Q29581755., Wikidata Q29581755

The generated code is a bit unsightly (could be smartened up I suppose):

Collapsed 91 line wikitext expansion of {{subst:cite Q|Q29581755}} 
{{#invoke:citeq|cite_q
|qid=Q29581755
<!-- Simple parameters from Wikidata -->
| publisher   = {{#invoke:WikidataIB |getValue |qid=Q29581755 |P123 |fetchwikidata=ALL |onlysourced=no |noicon=true}}
| oclc        = {{#invoke:wd|property|Q29581755|P243}}
| place       = {{ #property:P291  |from=Q29581755 }}
| doi         = {{ #property:P356  |from=Q29581755 }}
| issue       = {{ #property:P433  |from=Q29581755 }}
| volume      = {{ #property:P478  |from=Q29581755 }}
| pmid        = {{ #property:P698  |from=Q29581755 }}
| ol          = {{#invoke:String|replace|{{#invoke:wd|property|Q29581755|P648}}|^OL(.+)$|%1|plain=false}}
| arxiv       = {{ #property:P818  |from=Q29581755 }}
| bibcode     = {{ #property:P819  |from=Q29581755 }}
| jstor       = {{ #property:P888  |from=Q29581755 }}
| mr          = {{ #property:P889  |from=Q29581755 }}
| ssrn        = {{ #property:P893  |from=Q29581755 }}
| pmc         = {{ #property:P932  |from=Q29581755 }}
| lccn        = {{ #property:P1144 |from=Q29581755 }}
| hdl         = {{ #property:P1184 |from=Q29581755 }}
| ismn        = {{ #property:P1208 |from=Q29581755 }}
| journal     = {{ #property:P1433 |from=Q29581755 }}
| citeseerx   = {{ #property:P3784 |from=Q29581755 }}
| osti        = {{ #property:P3894 |from=Q29581755 }}
| biorxiv     = {{ #property:P3951 |from=Q29581755 }}
<!-- Special handling of Wikidata parameters -->
| isbn        = {{#if: {{ #property:P212 |from=Q29581755 }}   <!-- if ISBN 13 -->
                       | {{ #property:P212 |from=Q29581755 }} <!-- use ISBN 13 -->
                       | {{ #property:P957 |from=Q29581755 }} <!-- else use ISBN 10 -->
                 }}
| others      = {{#if: {{ #property:P110 |from=Q29581755 }}                <!-- is there an illustrator? -->
                       |Illustrator: {{ #property:P110 |from=Q29581755 }}  <!-- use illustrator -->
                       |                                                 <!-- else do nothing -->
                 }}
<!-- Optionally-local parameters -->
| chapter     = {{#if:                        <!-- is chapter specified? -->
                       | {{{chapter}}}                      <!-- use locally-specified value -->
                       | {{ #property:P792 |from=Q29581755 }} <!-- else fetch from Wikidata -->
                }}
| date        = {{#if:                            <!-- is date specified? -->
                       | {{{date}}}                          <!-- use date -->
                       | {{ #property:P577  |from=Q29581755 }} <!-- else use date from Wikidata -->
                }}
| series      = {{#if:                          <!-- is series specified? -->
                       | {{{series}}}                        <!-- use series -->
                       | {{ #property:P179  |from=Q29581755 }} <!-- else use series from Wikidata -->
                }}
| title       = {{#if: {{ #property:P1476 |from=Q29581755 }}      <!-- is there a title -->
                       | {{ #property:P1476 |from=Q29581755 }}    <!-- use title -->
                       | {{#if:{{ #property:P856  |from=Q29581755 }}
                               |{{#invoke:WikidataIB |getLabel   | Q29581755 }}   <!-- don't mix |url= and a wikilinked |title= -->
                               |{{#invoke:WikidataIB |getLink | Q29581755 }} <!-- else use label from Wikidata -->
                         }}
                }}
| url         = {{#if:                             <!-- is url specified? -->
                       | {{{url}}}                           <!-- use url -->
                       | {{ #property:P856  |from=Q29581755 }} <!-- else use url from Wikidata -->
                }}
<!-- Non- Wikidata parameters -->
| accessdate  = 
| author-mask     = 
| df          =  <!-- this should eventually be superseded by a user preference setting -->
| display-authors =  <!-- redundant until multiple-author issue is resolved -->
| embargo     =  <!-- for PMC -->
| id          = 
| mode        =  <!-- this should eventually be superseded by a user preference setting -->
| page        = 
| pages       = 
| quote       = 
}}{{#ifeq:{{{mode}}}|cs1||,}} ] ]

--Francis Schonken (talk) 12:37, 19 September 2017 (UTC)

;-) Have you actually looked at the resulting code, or only at the screen output? I don't think many people will agree that the result you produce is any better, it seems to combine the worst of both worlds. Fram (talk) 12:42, 19 September 2017 (UTC)
Previous had an edit conflict, you obviously looked at the resulting code since :-) Still, the remainder of my reply stands. Fram (talk) 12:44, 19 September 2017 (UTC)
"a bit" unsightly was of course an understatement... Newbie user-friendlyness plummeting to a new unknown depth... Yeah, its current code output should not be invoked in mainspace by a subst:... --Francis Schonken (talk) 12:53, 19 September 2017 (UTC)
Holy crap. A proposal to BAN that would pass with SNOW consensus in a few hours. We would need a method that actually resolves all of the parser function calls like #if and #invoke and #property. Alsee (talk) 22:34, 21 September 2017 (UTC)

Response by Jon Katz, Wikimedia Foundation, to recent Wikidata concerns

Hello All,

Sorry it took so long for a real response. There is a lot to unpack from the conversations taking place on-wiki and multiple stakeholders within the organization to consult. I really want to make sure we are speaking carefully and thoroughly enough to avoid a misunderstanding like the one that arose out of the recent withdrawn Wikidata description RFC. As evidence of that intent I will try to clarify a few things from the perspective of the team and ask for your insights in coming to a better shared understanding.

Looking things over there appears to be a few major threads of discussion.

  1. Why weren’t Wikidata descriptions turned off everywhere in connection with English Misplaced Pages in the context of the recent RfC?
  2. What are the Wikimedia Foundation’s plans for Wikidata here on English Misplaced Pages?
  3. What are the unaddressed concerns about Wikidata content appearing next to English Misplaced Pages content?
  4. Now that we know community members did not want Wikidata descriptions to appear in any reader interface for English Misplaced Pages articles, what should we do about it?

1. Why weren’t Wikidata descriptions turned off everywhere for English Misplaced Pages in the context of the recent RfC?

For this concern, see this reply. It was a misunderstanding.

We realize now that we've gone down a path that some may find confusing. Wikidata descriptions first appeared on visual editor, then mobile apps, and then the web. Along the way the use has always been seen as a navigational aid to readers to help them understand where they are quicker and with more confidence, not as integral part of Misplaced Pages articles.. It was not our intent to encroach into governance of the content. That being said, it is clear others see this differently. I don’t think the answer is definitive one way or the other.

2. What are the Wikimedia Foundation’s plans for Wikidata here on English Misplaced Pages?

Currently, experiments and plans for further Wikidata integration into Misplaced Pages projects exist, mostly driven by the Wikidata community and Wikimedia Deutschland, not the Foundation. I honestly don’t know much of the specifics of these, but one example mentioned was a Wikimania presentation by Wikimedia Deutschland about the historical success of Wikidata and where it could potentially go in the future. For example, in the linked presentation there’s a rather interesting prototype of what editing of Wikidata’s data directly from Misplaced Pages could look like - as requested by many editors on several Wikimedia projects using Wikidata’s data. The whole presentation provides a substantial insight into the work of the Wikidata community.

In addition to Wikidata descriptions, there are currently several instances where information from Wikidata appears alongside English Misplaced Pages content. For instance:

As many of you may be aware, the Foundation also supports efforts (like Structured Data on Commons) that leverages Wikidata to benefit the entire Wikimedia movement - beyond individual projects and their language variants.

While the Wikimedia Foundation has no concrete plans for integrating other data from Wikidata with Misplaced Pages, teams at the Wikimedia Foundation have been looking into ways to meaningfully integrate Wikidata for quite some time. This is because we believe structured data provided by Wikidata is strategically important and complementary to the content provided on Misplaced Pages. As other folks have mentioned, at this point, the Wikimedia Foundation has no specific plans in place for further integration of Wikidata into Misplaced Pages. If interested, you can read the Readers teams’ annual plan programs and goals to enable those plans for the coming quarter (the three-month period starting in October). That being said, the Wikimedia Foundation is supportive of the general idea of greater integration, and are eager to address potential concerns.

I believe that the benefits of using Wikidata as a separate repository, in the way the wikis currently use Commons, will eventually outweigh the drawbacks, but acknowledge we’re not there in many places. Any effort to further integrate Wikidata would have to address some of the serious concerns mentioned around control and quality.

3. What are the unaddressed concerns about Wikidata content appearing on English Misplaced Pages?

I will describe our understanding based on the above and other conversations and we are interested to learn and understand more.

We understand there are concerns over control, vandalism and the quality of content. We know that control by way of visibility and easier means to moderate, in particular, are legitimate issues that need to be addressed.

Significant additional work has already happened to address issues of quality. If you are interested in learning about the work that has happened and is taking place, please let us know and we can take the time to accurately document some of the most important items

Additionally, there are some relevant projects underway to improve the control and quality of Wikidata-related contributions. Some of these are organized by Wikimedia Deutschland, some assisted by Wikimedia Foundation efforts, and all developed via some form of community involvement.

We want to talk with you about which of these would help to address the concerns that you have. These projects are in varying stages of progress and represent varying degrees of effort.

Here are some steps particularly around the area of vandalism:

  • ORES (which was first made available on Wikidata in 2015, and since saw several Wikidata-specific improvements to its vandalism detection algorithm and better integration into the RC interface) helps patrollers to do their work much more efficiently.
  • Introduction of anti-vandalism bots making automated reverts of edits that are very likely to be vandalism
  • The Wikidata team recently supported a scientific competition to improve for anti-vandalism detection (similar to those that have been held for Misplaced Pages before)
  • Allowing institutions to cryptographically sign data that comes from them so it is easy to verify and spot when that data has been changed
  • Checks of Wikidata’s data against other databases to highlight differing data and spot mistakes

Are these the right sort of things for us to be working on? Admittedly progress has been slow, but knowing specifically what is most important will help us prioritize it.

Regardless of our progress, independent research is also beginning to provide us with a more thorough understanding of vandalism on Wikidata. A new study found that vandalism rates on Wikidata have decreased significantly in recent years (from 2013 to 2016) and are quite low: ”... -lately- only between 0.1% and 0.2% of are malicious”.

There are also concerns around understanding the policies on Wikidata and English Misplaced Pages and how they work together. Policies for important topics like notability and verifiability exist on both projects. Regarding BLP policy, Wikidata currently operates under the same resolution from the Wikimedia board as all Wikimedia projects. Wikidata also has a draft policy on living people. Respecting the governance of the projects, we’d like to ask the projects to continue working together to further clarify how these policies interact.

Lastly, I heard the concern that by showing Wikidata content on Misplaced Pages and calling the site Misplaced Pages, we were misrepresenting the content. Presumably the same concern applies to Commons images and I don't have any constructive ideas for how to address this concern, if others share it. Open to suggestions.

4. Now that we know community members did not want Wikidata descriptions to appear in any reader interface for English Misplaced Pages articles, what should we do about it?

As you may know Wikidata appears in other places on Misplaced Pages. Wikidata descriptions appear not only below the title on mobile web in all languages except English and Russian, but in the following places:

  • Apps under the title
  • Visual editor (desktop and mobile)
  • Portal search (www.wikipedia.org)
  • Mobile web and mobile app search
  • Related pages (bottom of mobile web and app pages)
  • iOS widgets
  • App maps feature
  • Apps feed feature

In almost all cases, these have been integrated for more than a year, sometimes two years. I personally think that it would be very hard to justify removing all elements of a reader experience that have been in place for this long on the basis of the concerns raised. Pulling the descriptions would be difficult for a number of reasons, including user interfaces that rely on Wikidata descriptions (redesign needed), removing expected and relevant information for our hundreds of millions of readers, and the technical cost of removal. In the apps in particular, it is unfeasible to consider the impact of pulling Wikidata descriptions from so many places. It would force us to reconsider the information architecture of the applications from the ground up. I think it would be much more productive to figure out how to give Misplaced Pages editors more control and otherwise take steps to reduce vandalism than to remove pieces of our readers' experience that are so deeply integrated.

Conclusion and Next steps

Hopefully, the above gives some insight into how we at the Wikimedia Foundation are thinking about this (at least, as relayed via a single employee). We want to figure out next steps together.

I feel that an RfC is not the best way forward in this discussion, as it creates a black/white dichotomy and decreases our ability to have an in-depth, nuanced conversation about a complex matter. The foundation has a responsibility to not only the folks who are able to be present here, but the contributors across projects currently uninvolved and those that use our knowledge across projects and platforms.

The Readers teams at the Wikimedia Foundation are working under the premise that if Wikidata integration is to be successful, the following are of highest importance to the English Misplaced Pages community members interested in this aspect of the project.

  • Be able to patrol/review Wikidata changes that appear in English Misplaced Pages articles.
  • Be able to edit these changes on-Misplaced Pages, without having to go to Wikidata.
  • Evidence the Wikidata community takes quality as seriously as English Misplaced Pages

These same items are listed above with links to the relevant work we have planned for them. I hope the explanation provided shows that we are working toward addressing these concerns. But are those, in fact, the primary needs?

What do you think? Jkatz (WMF) (talk) 02:48, 14 September 2017 (UTC)

responses

Thanks for the detailed reply. I think a key point in your comments is the integration of thr wikidata description into multiple locations, from which I think it is clear that those features have been designed with the assumption that Wikidata should be treated like Commons. That might have been a reasonable assumption to start with but as you can see from the conversations above can't be assumed now. En-wiki editors treat Commons as a reliable partner. I think ongoing design work should incorporate an understanding that this is not yet the case for Wikidata. Are there any Wikidata elements other than the short description that show up in any view of WP content? To your point about the difficulty of removing existing Wikidata description integration, I think it's going to depend on whether there's a better answer - if editors here can keep that data reliable, via watchlist integration, or better participation at Wikidata, that's fine, but we'd need consensus that that was the case. Mike Christie (talk - contribs - library) 04:24, 14 September 2017 (UTC)


I read what you wrote twice, and I find myself asking. Why in the world are you, speaking as the WMF person in charge of the reading team, here advocating for Wikidata?
There is more I would have to say, but i am stuck right there. Baffling. Jytdog (talk) 04:51, 14 September 2017 (UTC)
Hello,@Jytdog:. So I'm not Jon, but here's a thought I had reading your confusion. It's not that baffling that someone from the WMF would be advocating for Wikimedia projects. It's kind of a "see the forest for the trees" thing. Folks at the foundation, including myself, see our work through the lens of not a single project, but of many diverse projects with numerous interdependencies. From MediaWiki (the wiki software itself!), to Commons, to server infrastructure, to Wikidata, to all the non-Misplaced Pages projects - all these things are considered when working for the movement. So yeah, I'd advocate Wikidata, and Wikivoyage, and new projects in the incubator, and more. English Misplaced Pages is large, it's raucous :), but it's not alone in our thoughts. CKoerner (WMF) (talk) 12:24, 14 September 2017 (UTC)
When developing Mediawiki, you need to take the needs of all projects that use the software into account, obviously. That's why we asked e.g. to disable Flow here, but don't push for you to disable it everywhere. But what you are doing here is different, here you are pushing for the use of one project on another, whether they want it or not. Just like we saw with e.g. the search results from "sister" projects. Wikivoyage is not a sister project I want to see pushed here in any way, it is fundamentally different to our principles (while e.g. Wiktionary is a logical sister project). Wikidata is something that on the one hand may use our data as much as they like, and on the other hand could be a "here we are, how can we help you" thing which we may use (for interwikilinks) or not use (for most other things), not something that the WMF should insert into our content without some serious communication and agreement upfront (just like the idea to generate articles directly from Wikidata would need a very good consensus on enwiki before it should be attempted here). And I guess that Jytdog is also baffled that someone from the Reading team would promote something that is so utterly ill-suited to reading as Wikidata. Fram (talk) 12:49, 14 September 2017 (UTC)
Thanks for the thoughts Fram. It seems to me there's some confusion over where navigation ends and where content begins. CKoerner (WMF) (talk) 13:18, 14 September 2017 (UTC)
Chris, ARGH. I was too terse and you definitely took advantage of that. Of course it is fine to advocate for projects. Fatuously obvious. (You have responded glibly to me like this before, and i have pushed back on that before)
What is baffling is that somebody from the WMF is here in Misplaced Pages with a very strong stance on a matter that involves en-WP content and governance, advocating that Misplaced Pages should allow Wikidata integration.. With no self-awareness of how overstepping that is. This is how far gone things are. It is much worse than I thought.
I just quoted this at Jimbo's talk page yesterday - I will do it again here. Terms of Use:
These Terms of Use tell you about our public services at the Wikimedia Foundation, our relationship to you as a user, and the rights and responsibilities that guide us both. We want you to know that we host an incredible quantity of educational and informational content, all of which is contributed and made possible by users like yourself. Generally we do not contribute, monitor, or delete content (with the rare exception of policies like these Terms of Use or legal compliance for DMCA notices). This means that editorial control is in the hands of you and your fellow users who create and manage the content. We merely host this content.
And later: The Wikimedia community and its members may also take action when so allowed by the community or Foundation policies applicable to the specific Project edition, including but not limited to warning, investigating, blocking, or banning users who violate those policies. You agree to comply with the final decisions of dispute resolution bodies that are established by the community for the specific Project editions (such as arbitration committees); these decisions may include sanctions as set out by the policy of the specific Project edition.
That is the fundamental deal here. The various projects each generate content, have policies that govern content and behavior, and have governance that enforces those policies. Within each project. Wikidata is different from en-WP. And it is not the WMF's role to get involved in intra=project content and governance. It is "We merely host this content". It is not - "we make editorial decisions about content"
There are differences in policy and governance between Wikidata and en-WP. These are serious when you get down to actually working.
It is really easy to see. Imagine the world where there is integration of live Wikidata in Misplaced Pages.
a) Somebody adds content to Wikidata that violates en-WP BLP's policy.
b) That change appears in en-WP
c) I change that here, as soon as I see it
d) that change appears in Wikidata
e) person who added that in Wikidata, changes it right back.
f) the BLP violation re-appears in en-WP.
g) Welcome to hell. Separate projects, with separate policies and governance. Not resolveable. There are very practical content and governance issues, of which you and Jon appear oblivious.
h) On top of that:
1) I don't care about Wikidata content. I don't want it to die, and I wish that project well, but I don't care, and I don't want to volunteer there.
2) I have no desire to try to change Wikidata policies and governance
3) I have no desire to try to enforce en-WP policy inside Wikidata. To me that would be as stupid as me buying a house in the UK, and expecting US law to govern there. I try not to want stupid things. Seeing them as stupid helps me not want them. (And I can only imagine that for somebody who edits mostly Wikidata, having some fuckwit from Misplaced Pages showing up and demanding that Misplaced Pages policy should govern there, would be insulting and a huge waste of their time.)
4) And if there is somebody who persistently adds content to Wikidata that consistently violates en-WP policy, what I am supposed to do about that? really - it takes an understanding of policy and "what works" to have a problematic editor's behavior effectively addressed by the community. And it takes time and effort to present a "case" of a problematic editor to the community, so that others can see it, and decide what to do about it. I know how to do that here, to help with en-WP governance. I have no idea "what works" in the Wikidata community or even what kind of behavior would be seen as worthy of that community's time. And I don't really want to take the time to learn. I don't believe that either you or Jon even understand what I am talking about in this point #4, but it is how community governance actually works.
5) to underline this, I don't volunteer my time for Wikidata. I volunteer my time at Misplaced Pages. Because this is what I want. There is nothing stupid about that. This integration kind of forces me to edit Wikidata - if I see a BLP violation, I really should fix that, right? And if some Wikidata editor is persistently adding content that violates en-WP BLP policy, I really should do something about that, that works in the Wikidata community, right? So this integration is really exploitation. (that is sometimes explicitly said but in a way that is fake and nice ("Oh, it would be great to have the more active and bigger Misplaced Pages community work on Wikidata". It is actually distraction, exploitation, and setting up arguments that cannot be resolved or can be only be resolved with a serious time commitment)
Summarizing, there are issues of the WMF
A) overstepping into community content and governance (the whole advocating "response" post, is overstepping)
B) ignorance of the differences in each project's governance that have very practical consequences
C) trying to create a situation that is harmful to both communities of editors (out of ignorance of B, surely. but "the road to hell is paved with good intentions")
Again, the whole post is baffling to me. Things are very far gone, in a bad direction.
And I ask myself, why is this even happening to a level where I have spent all this time (my volunteer time) addressing this? How did things get so fucked up at the WMF?
Bottom line - The WMF has power as the publisher. It is arrogantly overstepping its role and this is seen as entirely normal and OK within the WMF to the point where a product manager comes here and writes a long post from that stance. The WMF doesn't understand the problems it would create. Jytdog (talk) 14:29, 14 September 2017 (UTC)
Sorry about the confusion there. As you said it seemed rather obvious to me as well, so I was baffled as to why you'd be making that argument. I misunderstood. CKoerner (WMF) (talk) 14:47, 14 September 2017 (UTC)
I will also say "hell no" to what you say about Wikidata in Wikpedia. It is deeply wrong headed. But I will talk more about that later. I am just too baffled on the fundamental stance you have taken to write more. Jytdog (talk) 04:54, 14 September 2017 (UTC)


I hesitate to say what the community wants without a broader community discussion, but my impression is that experience with the wikidata experiment has been shifting consensus against it. Wikidata isn't like Commons. I think most people who are unhappy with wikidata won't much care about the improvements you've suggested. Wikidata worked fine for its original purpose, interlanguage links. Having articles pull content from wikidata has been controversial, and we've got consensus against the wikidata-descriptions push content. Alsee (talk) 06:07, 14 September 2017 (UTC)
Hey @Alsee:, what do you mean by "original purpose"? I'm under the impression that Wikidata was presented back in 2012 as being exactly like Commons. "It will provide data in all the languages of the Wikimedia projects, and allow for the central access to data in a similar vein as Wikimedia Commons does for multimedia files." I don't think I'm the only one operating under this assumption and would appreciate any clarifying sources if you have them. CKoerner (WMF) (talk) 12:07, 14 September 2017 (UTC)
Yes and no. That was the intent, however the differences have cropped up subsequently to that. Commons has fairly restrictive policies regarding its content which are compatible with ENWP/Wikipedia. ENWP chooses what we want from Commons to display on a relevant Misplaced Pages article. Because of Commons policies we can trust the content we *choose* to use is valid and not problematic. Wikidata has no compatible content policies and is effectively (in the case of descriptions) forcing its unverified and potentially legally problematic content onto Misplaced Pages articles. If Wikidata had compatible policies (as commons does) this would not be a problem. However it currently does not, and is unlikely to do so anytime soon. Which is why ENWP *requires* no wikidata pushed-content (descriptions, infoboxs are a different issue) is visible when people visit a Misplaced Pages article on *any* platform - or at least the option to manually turn it off from the ENWP end. Only in death does duty end (talk) 12:16, 14 September 2017 (UTC)
I didn't pay a lot of attention at the time Wikidata was launched but interwiki links were widely discussed as an obvious use case, so that might be what Alsee is referring to. Yes, I think the original idea was that it would be treated just like Commons. Fram's point below is the key issue in the current discussion -- the description is not visible to or controllable by a Misplaced Pages editor. That is quite unlike Commons. Other issues that have been raised with Wikidata here relate to whether we should consciously choose to use it for citations, or filling infoboxes; generally those effects result from a choice by an editor here, and we still haven't come to consensus on which of those uses should be allowed. For the descriptions, it's quite different: it's invisible and uncontrollable from en-wp. That's what needs to be fixed. Mike Christie (talk - contribs - library) 12:15, 14 September 2017 (UTC)
CKoerner (WMF), I am not deeply familiar with the founding wikidata so I apologize for any imprecision in my comment. As I understand it, linking equivilent articles across languages was the initial use of wikidata on wikipedia. As I understand it, the interinterlanguage link mess alone was enough to justify that a solution be built. Whatever concepts were pulled together at wikidata's founding, I have the impression that interlanguage links could reasonably be credited as a primary factor moving the project from concept to reality. Alsee (talk) 17:30, 14 September 2017 (UTC)
My understanding of what the original intentions for Wikidata were, matches the text at Wikidata:Notability: "Wikidata in its first phases has two main goals: to centralize interlanguage links across Wikimedia projects and to serve as a general knowledge base for the world at large." What is not said there is "to serve as a data source for Misplaced Pages" or something similar. Fram (talk) 09:51, 15 September 2017 (UTC)
Then that's an incomplete understanding. See e.g. : "Wikidata will support the more than 280 language editions of Misplaced Pages with one common source of structured data that can be used in all articles ". Regards, Tbayer (WMF) (talk) 13:42, 15 September 2017 (UTC)
Mine is from a current policy page, yours comes from a blog. I never read that blog, I am not a fan of the WMF good news show. Posts from the same year include things like this on AFT and all kind of glowing articles on VisualEditor (the default editor in 2013, as it was so good by then of course). I've made a comment about a typical WMF announcement earlier today at WP:VPT. It's impossible to get a complete and accurate understanding about most WMF projects from WMF communications, and reading that blog will hardly be a help in that regard. Fram (talk) 14:27, 15 September 2017 (UTC)
Can be used in all articles is not the same as will be inserted into articles in other projects by outsiders without consultation and without editorial control from the afflicted projects. Can be used in all articles is fine, as it implies the option not to do so if the editors of any particular article choose not to do so. Wikidata is welcome to use material from Misplaced Pages, provided they comply with the conditions of use. Misplaced Pages is welcome to use material from Wikidata, under similar conditions. Neither project is welcome to insert their content into the other in a manner which is not editable from within the recipient project. If WMF as the host find it necessary to arbitrarily insert content from one project into the displayed page for another article they should clearly label it as content from another project, and be aware that some of us will consider it to be spamming. · · · Peter (Southwood) : 21:35, 17 September 2017 (UTC)
Pbsouthwood, I was making a factual correction to mistaken claims above about what the original intentions for Wikidata were, not describing an interpretation of it by WMF or others.
Regarding your remarks on labeling, FWIW: The app's new description editing function (which, as mentioned in the recent announcement that triggered the current debates, has been live on all Wikipedias except English already, but can be tested for English in the not yet released alpha version of the app) also adds the following explainer text, reachable by tapping on an info link: "Descriptions are stored and maintained on Wikidata, a project of the Wikimedia Foundation that provides a free, collaborative, multilingual, secondary database supporting Misplaced Pages and other projects".
Regards, Tbayer (WMF) (talk) 08:07, 18 September 2017 (UTC)
I did not presume to judge your intention by quoting the blog. I pointed out that the purpose stated in the quote differs substantially from what appears to be the current reality, and not in a good way. It goes further than loose interpretation. I will not presume to judge whether it was intentional misinterpretation, or accidental, or even some other possibility that does not immediately come to mind. The resulting implementation puts the cart before the horse. Instead of supporting the Wikipedias with a source of data that all can use, it is becoming a source of data of dubious provenence that is being imposed upon the Wikipedias in a currently unacceptable way. It will be interesting to see who gets the blame if/when WMF is sued for defamation or libel or whatever when some litigious person or organisation sees this as an opportunity to curtail a competitor or even just sues out of spite against the principle of free information. I would like to see an unambiguous statement from legal that there is no risk to the Wikipedias from this. Can you assure us that this has been fully cleared by legal? · · · Peter (Southwood) : 12:17, 18 September 2017 (UTC)
@Pbsouthwood: So long as the site is simply relaying user-provided content (whether provided here or at Wikidata), WMF is covered by Section 230. That's not an argument not to try our very hardest to get things right and to eradicate error -- above all, there's our reputation to protect. But it does mean that overwhelming legal peril for WMF is not such a concern, so long as they act quickly to fix any individual cases they are made aware of. Jheald (talk) 12:40, 18 September 2017 (UTC)
I will take your word about the app, as I do not use it, and it is likely that someone else will do the checking anyway, However I will ask how obvious that link is to the casual user, and how obvious it is that the link will explain where the information is sourced, and that it does not come from Misplaced Pages, which may be the obvious expectation. · · · Peter (Southwood) : 12:17, 18 September 2017 (UTC)
@Jkatz (WMF):, theer are many things I could say, but I'll stick for now with one major thing which you seem to have overlooked in your response. When you are comparing the descriptions with things like Commons or the use of Wikidata elsewhere on enwiki, there is one truly fundamental difference: when we display e.g. a Commons image, we explicitly link to it from the article. When we display other Wikidata content, we explicitly link to it from the article or from an enwiki template. With the descriptions, in every example you mention, this is pushed by the WMF, not requested by enwiki, and not something we can disable even on an article-by-article basis.
For that reason (plus some other reasons which also apply), please disable Wikidata descriptions everywhere on enwiki, except where it is explicitly asked by an article or enwiki template in some way. Fram (talk) 11:49, 14 September 2017 (UTC)
@Fram:, So if Wikidata descriptions could be 1) disabled on an article-by-article basis and 2) were hyperlinks to the Wikidata entry (like Commons images), then things would be better. Is that what I understand? That's a new twist on the subject. One I have not heard proposed thus far. I also understand your desire to remove completely, I'm not trying to be obtuse. I guess what I'm trying to say (haven't had coffee yet this morning) is that if we could snap our fingers and have these things you'd be a smidgen happier? CKoerner (WMF) (talk) 12:14, 14 September 2017 (UTC)
Those things would help; I think if we could also see the changes in watchlists in a comprehensible way, and if it were easy to fix problems or vandalism spotted via the watchlist, that would go a long way to resolving the issue. Mike Christie (talk - contribs - library) 12:17, 14 September 2017 (UTC)
@CKoerner (WMF):. No, if Wikidata descriptions were something we (enwiki) requested, in an article or by using a template, then things would be better. Changing the text (description) to a hyperlink to Wikidata wouldn't be better, it would be even worse. "Things that get disabled on an article by article basis" are things which get, by us, pulled from Wikidata through a template, but which we, at enwiki, can even then decide not to use in one article or another. The main concern is that we, the enwiki community, can implement where we want to display what Wikidata info, and can again disable it if we don't want it, on an article or in general. Fram (talk) 12:42, 14 September 2017 (UTC)
@Fram: I hate to ignore a direct ping, but the cold I had the last couple days took over last night, my brain is mush, and I realize I need to take a break. I'm taking a day or two to recuperate and then will get back on here. Jkatz (WMF) (talk) 15:37, 14 September 2017 (UTC)
I agree with Fram here - there seems to be a fundamental error in the idea that Wikidata is like Commons. No, its not when there is an effort to push content onto en-Misplaced Pages from Wikidata without en-Misplaced Pages's control. Commons doesn't push information/images onto en-Misplaced Pages, so en-Misplaced Pages has control over what information/images is used and what isn't. Currently, Wikidata isn't in that situation and given our sourcing and BLP policies here, its a huge concern that Wikidata information is being pushed onto en-Misplaced Pages without the ability of en-Misplaced Pages to control that. Until that fundamental misunderstanding is cleared up, much of what was written above is really just hot air, to be blunt. Ealdgyth - Talk 11:58, 14 September 2017 (UTC)
Mike says it would help and you say No. What am I suppose to do with that!? :p Seriously though, and I'm just talking shop here, this is one of the difficulties I have in understanding the needs of our communities, but I appreciate the considerations. CKoerner (WMF) (talk) 13:21, 14 September 2017 (UTC)
There's certainly some disagreement here about the best answer, but I'd add that I didn't say it would resolve it. My answer was in the spirit of "more tools would help". I don't think it would be enough. Even with the extra tools I suggested, it's debatable if it would resolve the problems we're discussing. Mike Christie (talk - contribs - library) 13:35, 14 September 2017 (UTC)
User:CKoerner (WMF), what you and the WMF should do, is stay the hell out of it. It is not the WMF's role to make these decisions. Unilaterally changing Misplaced Pages content is completely outside of the WMF's role. Creating tools that allow integration of Wikidata content in WP is one thing, but whether the en-WP community decides to use them is entirely different. That is an internal en-WP editing community decision. Baking integration tools into the Wikimedia software and driving Wikidata content into en-WP would be... extremely controversial. We are talking Flow-level controversial, if not worse, because this would be a content thing. More than anything, WMF needs to be neutral player, and not advocating for X or Y when it comes to content and governance. Jytdog (talk) 14:52, 14 September 2017 (UTC)
Sure Commons pushes information in. Imagine I add a portrait image of a person to an article and then someone on Commons replaces it with an image of a penis, and suddenty we have an image of a penis like it is a portait and nothing shows up in the watchlist. It just fortunately does not happen very often.--Ymblanter (talk) 12:17, 14 September 2017 (UTC)
The key difference as has been pointed out multiple times is that a)commons has policies against this, b)commons has enough editors that people will SEE this, c)Misplaced Pages editors will see this looking at the article and report it promptly. Wikidata has no equivalent to WP:V or WP:BLP to restrict what content is hosted on wikidata. Wikidata does not have enough editors to spot and handle deliberate vandalism. Wikidata changes do not necessarily show up when even looking at the article on Misplaced Pages as in the case of descriptions, its being pushed to mobile/app devices where users are unlikely to report the issue, or even attempt to fix it. The comparison's to commons need to stop because Wikidata is currently nothing like commons, either in its function, its management, or at a basic policy level. Only in death does duty end (talk) 12:24, 14 September 2017 (UTC)
What's more, if Commons ceased to reliably patrol for this sort of vandalism, the result would almost certainly be that en-wiki would be less and less willing to use it. En-wiki editors don't get exhorted to go and edit on Commons and help keep things clean there; they have an active editing community that we rely on; if they didn't we wouldn't rely on them. Mike Christie (talk - contribs - library) 13:38, 14 September 2017 (UTC)
Of course Wikidata has content policies and guidelines that disallow the equivalent of penis picture vandalism; it's quite absurd to imply otherwise. At least it seems you did not look at the one concerning descriptions before posting these far-reaching claims. Regards, Tbayer (WMF) (talk) 14:16, 14 September 2017 (UTC)
Please provide a link to the relevant policy page on Wikidata that complies with ENWP's WP:V and WP:BLP policies. Only in death does duty end (talk) 15:27, 14 September 2017 (UTC)
Note btw that whereas reupload vandalism is relatively uncommon and typically get detected and reverted on Commons quickly, changing descriptions which goes contrary to the English Misplaced Pages NPOV policies is relatively common, and the descriptions stay on Commons sometimes for years - and are actually shown on the English Misplaced Pages - this is what one gets if one clicks here on a file.--Ymblanter (talk) 07:42, 22 September 2017 (UTC)
I have always thought of Wikidata being exactly like Commons -- a common storage for data that does not have a natural home in a single Wikimedia project. I don't understand where the idea that Wikidata is something alien really comes from. It might require improvement, but avoiding its use is making sure it will never be improved (remember Wikinews and other projects that died?) —Kusma (t·c) 12:25, 14 September 2017 (UTC)
Can we have an option to show the Wikidata "short description" on every article page, so we can easily check whether it is ok or not? —Kusma (t·c) 12:25, 14 September 2017 (UTC)
Imagine that the WMF would start every article with an image, taken from Commons, which they think is best suited for the article. This is basically what they do now with the descriptions. With commons, we can remove all images from an article, we can host the image locally, ... E.g. for our featured article on the main page, all images get fully protected, just like all templates and so on. However, the short descriptions, shown to many people, is not fully protected. This is, as far as I am aware, the only part of the TFA that doesn't get protected (and probably doesn't get checked by TFA promotors either). It's just an example, but it's an indication of how this use of Wikidata is not like Commons. Fram (talk) 12:42, 14 September 2017 (UTC)
The FA itself usually isn't protected, only the bits that go on the Main Page are. Any Wikidata items used on the Main Page need to be checked for their vandalism potential and technical solutions for protection should be found. Why do you make this fundamentally different than the Commons? —Kusma (t·c) 12:55, 14 September 2017 (UTC)
Because the short descriptions are not hosted on ENWP, nor visible when checking through a standard browser. They are not part of the article in any way, nor part of the review. Any wikidata items transcluded through a template would be checked, anything inserted after the fact by an outside source would not be. Only in death does duty end (talk) 12:59, 14 September 2017 (UTC)
Thanks, I sould have checked that before posting my reply. My point remains (pushing unrequested data which is not visible to most editors and which we can't avoid by removing the link or (as with commons) adding a local version instead, is totally different to how we use Commons: the comparison with Commons is fair in that ragard for many other uses of Wikidata on enwiki, but not for this one), but my example was wrong. Fram (talk) 13:11, 14 September 2017 (UTC)
No, your analogy is deeply flawed in other ways too: The description is not selected by WMF, as you imply ("WMF would start every article with an image, taken from Commons, which they think is best suited for the article"), but by editors - there is only one for that article, selected by editors, and if an editor thinks a different wording is better suited, they can edit it. And yes, editors will see a different Wikimedia domain appearing in their browser's address bar when they do that, instead of en.wikipedia.org, but that's also been the case with Commons since 2004. Regards, Tbayer (WMF) (talk) 14:16, 14 September 2017 (UTC)
The WMF has decided that the Wikidata description is the right thing to show on top of enwiki content. The WMF thinks this info, inserted outside enwiki, is best suited for enwiki articles and should be the first thing mobile readers (and so on) see. The description is written by editors, but is selected by the WMF as the thing to display here. Nothing "deeply flawed" there. " if an editor thinks a different wording is better suited, they can edit it. And yes, editors will see a different Wikimedia domain appearing in their browser's address bar when they do that, instead of en.wikipedia.org, but that's also been the case with Commons since 2004". First of all, until very recently (and still for most cases), a reader wouldn't know where the info came from, and choosing "edit" wouldn't bring him to the right place. So no, in reality, a normal reader or editor can not edit it. Furthermore, don't like an image? You can edit it in the article, there is no need at all to go to Commons and you will not, contrary to what you claim, "see a different Wikimedia domain appearing in their browser's address bar". Fram (talk) 14:52, 14 September 2017 (UTC)
The WMF team and only the WMF, made the editorial decision to take the description field from Wikidata and insert it into en-WP articles on mobile and the apps. That is a sole WMF decision. And it is about content. Do not misrepresent what was done. You are making things worse, not better, by obfuscating what was done and who did it. Jytdog (talk) 14:55, 14 September 2017 (UTC)
(I'm probably not helping here) There's a bit of code you can add to your common.js to do just this. CKoerner (WMF) (talk) 13:04, 14 September 2017 (UTC)
Thank you. I guess you mean Special:Mypage/common.js ? —Kusma (t·c) 13:06, 14 September 2017 (UTC)
I have installed it, it seems to do exactly what I was looking for. —Kusma (t·c) 13:08, 14 September 2017 (UTC)
Also, there is always the "Wikidata item" link in the left sidebar, which leads one to the description (if it exists) with one click. Regards, Tbayer (WMF) (talk) 14:16, 14 September 2017 (UTC)
I tried this to see what it does; for others reading this, if you install the script, the Wikidata description will appear at the top of the page, which at least makes vandalism easy to spot on the page you're reading. A good next step (assuming these descriptions don't disappear as a result of this or other conversations) would be to make it equally visible in the watchlist. Mike Christie (talk - contribs - library) 02:05, 15 September 2017 (UTC)
Wikidata description: "Template:Wikidata description"
  • No big deal It's interesting that Mr Katz's constituency is the people who read Misplaced Pages. I'm not sure that he's come to the right place to get the views of the general readership but, as it happens, I dip into the iOS app on most days. The one line summaries in question are quite inconspicuous in my experience and so there isn't a significant issue or problem. I reckon that the images we take from Commons have much more potential to cause trouble. For example, consider an image which is currently on the main page (right). This purports to be Halimah Yacob and I have no reason to doubt this. But the provenance of this image seems weak as it just seems to have been scraped and cropped from Flickr. In Misplaced Pages terms, this image fails both WP:OR and WP:RS because it's original work and self-published. And it's much harder for people to challenge and change such an image because most readers won't have an alternative readily available. But we're used to such images and are comfortable with the risks as, in practice, they seem to be low. The risks of using WikiData descriptions seem quite small too and so we shouldn't worry too much about them. Andrew D. (talk) 21:45, 14 September 2017 (UTC)
    Absolutely. And of course Commons does not have anything remotely close to WP:V. Most of the Wikidata info cones from databases, which we call reliable; most of the Commons info has doubtful provenance.--Ymblanter (talk) 06:48, 15 September 2017 (UTC)
    This shows the breakdown of how many statements on Wikidata are unsourced, sourced to Wikipedias, or sourced to other references. Note also that not all "other" references are reliable. Nikkimaria (talk) 13:17, 15 September 2017 (UTC)
Sure. None of the files on Commons are sources, most are junk, but the English Misplaced Pages continues to accept them no problem.--Ymblanter (talk) 13:53, 15 September 2017 (UTC)
"None of the files on Commons are sources": yes, files are not allowed to be used as sources. "Most are junk"? And we can remove any from enwiki we consider to be junk. We accept the images we want to, and reject the ones we want to. How is any of this relevant to the use of Wikidata as a source of information we can't refuse and which isn't sourced. "Most of the Wikidata info cones from databases": the identifiers come from databases and vastly distort the percentage of "sourced information". The actual information on Wikidata is usually either unsourced or Misplaced Pages-sourced. Only for a few select types of items has there been an effort to actually source it. Fram (talk) 09:12, 18 September 2017 (UTC)
Unfortunately I have to repeat my point for the third time bacause somehow people do not want to listen. If the file from Commons is chosen to illustrate a statement X, there typically is no source in terms of WP:RS which states that the file illustrates X. As it was noted in this discussion, many Commons files have unclear provenance (e.g. taken over from Flickr) so that we have to rely on unsourced statements of people who are not even Misplaced Pages users and are not notable in any way. This is potentially problematic and can lead to libel court cases. However, it is not perceived by the local community as problematic. In contrast, Wikidata has sources to most of the statements, these sources are reliable by Misplaced Pages standards, and the share of these sourced statements increases.--Ymblanter (talk) 13:04, 18 September 2017 (UTC)
Well, you said "none of the files on Commons are sources" which is true but irrelevant, as images are not allowed to be used as sources on enwiki. Now you go back to another issue, that many files on Commons are poorly sourced, which is a completely different and unrelated point. "In contrast, Wikidata has sources to most of the statements, these sources are reliable by Misplaced Pages standards, and the share of these sourced statements increases." That's what they want us to believe at least. Have you used the "random item" on Wikidata and actually checked the sources? I'll start a new section below about this. Fram (talk) 13:12, 18 September 2017 (UTC)
If you read the whole thread starting from the message of Andrew Davidson this is exactly what he was stating, and I agreed with him. I am not sure why other people continued throwing around irrelevant arguments, but when I see a wrong or irrelevant statement formulated as an attempt to refute what I am saying I usually try to respond, because people nowadays usually do not read the whole argument and only stick to the last statement.--Ymblanter (talk) 14:20, 18 September 2017 (UTC)
[ec}I am surprised by your claim that most Wikidata statements are reliably sourced by Misplaced Pages standards. This is not the impression I get from most of the discussion here. Can you direct me to the statistics on what number/percentage of Wikidata statements are sourced, and the analysis of the reliability of the sources? It would also be useful to know how one can tell the difference between a reliably sourced item and one without a reliable source.
I agree that the provenance of some images at Commons is dubious, but at least if we don't like them they are really easy for us to to delete from an article. Some editorial judgement is required, and can be applied. Cheers, · · · Peter (Southwood) : 13:37, 18 September 2017 (UTC)
Answered in the topic below.--Ymblanter (talk) 14:20, 18 September 2017 (UTC)
  • User:Jkatz (WMF) how far out is the "only show relevant item" ability? I see that as the biggest blocker to using WD more on EN WP. We have had significant vandalism to a WD description appear at the top of one of our most read medical articles for nearly 6 months / one million page views nearly two month and half a million page veiws. This is a serious problem. Doc James (talk · contribs · email) 01:38, 15 September 2017 (UTC)
The undisputed usefulness of this proposed feature notwithstanding, Doc James has since clarified on Facebook that this example (pneumonia, Q12192) did actually not involve a vandalized Wikidata description. Instead, I understand these nearly 6 months / one million page views concerned the use of Wikidata information in the article's infobox (which was an editor decision and entirely separate from the app use of descriptions) and a dispute about data added by ProteinBoxBot. Of course there are incidents of vandalism too, as discussed below, but the open question is how likely they are to affect the reader overall (the quoted result from the paper by Crescenzi et al. indicates that the likelihood may not be very high). Regards, Tbayer (WMF) (talk) 10:51, 15 September 2017 (UTC)
Thks User:Tbayer (WMF) yes am mistaken on the specifics of that one which was a different WD issue. But between Sept 24th 2016 until Nov 14th 2016 this article had vandalism in the description. during which time it received about 400,000 views.. This is one of our most viewed medical articles. Doc James (talk · contribs · email) 12:15, 15 September 2017 (UTC)
But the vandalized description did not affect the vast majority of these 400,000 views (the descriptions were not being shown on either desktop or mobile web back then, and the app share is a rather tiny portion). And regarding app users, I would think it may have gotten corrected much sooner if the description had been editable for them - that's exactly the shortcoming which is now being fixed, per the recent announcement that triggered all the current debates. Regards, Tbayer (WMF) (talk) 13:42, 15 September 2017 (UTC)
Thanks User:Tbayer (WMF). I was under the impression that this was used on all mobile. Eran tells me that the improved watchlists for WD within Misplaced Pages is almost done. So hopefully all will be better soon. Doc James (talk · contribs · email) 01:19, 16 September 2017 (UTC)
The article "Q5506618"? Yep, undisputed usefulness
The article "Q5506618"? Yep, undisputed usefulness
"::The undisputed usefulness of this proposed feature notwithstanding," I certainly dispute its usefulness, as it gives a false sense of security and doesn't tackle the actual problem. I also hope it is in reality a lot better than what the WMF shows in their help pages. "And regarding app users, I would think it may have gotten corrected much sooner if the description had been editable for them - that's exactly the shortcoming which is now being fixed, per the recent announcement that triggered all the current debates." It wouldn't need to be corrected if the WMF did what was asked in the first place, and did what was normal (i.e. not pushing outside content to the top of enwiki pages) in the first place. You are defending a poor band-aid solution instead of implementing the real solution, and act hurt when people don't fall over backwards in gratitude. Fram (talk) 09:12, 18 September 2017 (UTC)

Arbitrary break

I'm a long-time editor who has spent some time introducing students to editing wikipedia, before and after the advent of the VisualEditor. They and I now regularly use the VE for most of our editing. This one small application of Wikidata material (showing a one-line description below the article title) is incredibly useful, and substitutes for clicking through to a disambiguation page or link for every single wikilink we enter using the VE. So, the functionality is useful.

But it's impossible to see or edit from enwiki. (Maybe the former is desired, but the latter is a problem.) Moreover, the alias is literally part of the interwiki system from the Wikidata side. It should match up with the article, as understood by people on enwiki. So, I think it's crucial for it to be durably changed and maintained from within the corresponding language Misplaced Pages. Surely, there's also some way for it to show up as an editable object in the VisualEditor. This problem should be fixable without addressing the bigger problems at Wikidata. And the solution should involve Misplaced Pages-generating content overriding/correcting/appearing on Wikidata.

(Also, Wikidata has a huge lag in data verifiability and maintenance that makes errors and vandalism quite persistent. I just removed the unsourced "ealiaesean" as an unsourced alias for Björk that has persisted since 4 April 2013, but appears literally nowhere else on the searchable Internet. If Wikidata is to become our indexing engine, it has to shape up.)

Zooming out for a minute: As someone who just started seeing these debates a few months ago, I find the lengthy tirades, raised hackles, and persistent frustrations attached to enwiki/WMF arguments to be a diversion from these (overlapping) groups of people understanding one another. Those Wikipedians who have chosen to spend time on governance issues tend to share a focus on defeating vandalism, COI editors, and other on-wiki threats. Conversely, WMF seems to be kept up at night by the threat of declining relevance to mobile users (fast becoming the majority of the Internet) and of having the lifeline of visitors shut out by Google's structure AI development, which could provide (free) Misplaced Pages content, without sending users to Misplaced Pages in return. Both of these are important fights to wage: without high quality safeguards, Misplaced Pages will lose credibility, and without an ongoing stream of visitors, Misplaced Pages would lose its relevance and the banner-ad visitors who keep the lights on and the servers running. In this case, as in many, I see the concerns of the "Misplaced Pages community" as highly legitimate, but the rule-based solutions proposed by community members as thoughtlessly aimed and undercutting ongoing initiatives to make Misplaced Pages's information more structure, more searchable, more accessible by mobile users, and available in formats that are more familiar to the current generation of digital device users. But unless and until we speak from a position of interdependence, rather than boundary-setting, we won't be able to collaborate in keeping Misplaced Pages the kind of smart, universally accessible knowledge tool it could be.--Carwil (talk) 18:20, 14 September 2017 (UTC)

Differences between Wikidata and en-WP are not imaginary or bureaucratic; they are very real.
WMF has overstepped and made a mistake. It happens.
The solution is not to pretend it didn't happen.
The solution is to undo the mistake, and find a different solution to the perceived content problem. Jytdog (talk) 19:20, 14 September 2017 (UTC)

Jkatz (WMF), I appreciate you and the other staff members coming here to discuss this with us. You also produced a very thorough list of upgrades for wikidata descriptions on wikipedia. I believe the people asking for improvements will be very satisfied by it. I also appreciate the reasons you gave for not wanting to remove wikidata descriptions. However I would appreciate it if we could clarify the scope of discussion here.

If you are offering to upgrade wikidata descriptions as your preferred option, and we're also discussing local solutions (using lead sentence and/or {{short_description|}}), great.

If not, then it's not really an offer. That would just be a proposal to increase how much of wikidata is forced on us. People who do not want wikidata descriptions also do not want increased integration of wikidata descriptions.

I think most of the discussions on this page are going in pointless circles, debating the pros and cons of wikidata in general. I think everyone pretty much knows the various positions. I'm not seeing much real movement. The noise here needs to be refined into a consensus. If you're offering to upgrade wikidata descriptions, I'd be more than happy to collaborate on drafting a Village Pump RFC with your proposed upgrades. Although to be honest, I give "upgrade" less than 50% chance of acceptance unless something unexpectedly shifts consensus. I'm an experienced RFC closer, I carefully studied the previous RFC in terms of the proposed improvements. A minority thought wikidata descriptions were fine as-is. Another minority asked for improvements. However among those who were concerned with the descriptions, the concerns were primarily for descriptions to be local. You're basically trying to build a coalition-consensus between people who want improvements, and people don't care about improvements because they think current descriptions are fine. That might get you to consensus, but I think you fall short. I think consensus will be for local descriptions. Alsee (talk) 02:11, 17 September 2017 (UTC)

No, absolutely not. What JKatz wrote are things that I and many other people already knew, and they do not speak to any of the issues. The WMF has still overstepped its role, and of course nothing that they wrote addressed the policy and governance difference between the projects. And all that the proposed tool to edit Wikidata descriptions here in en-EP would do, is set up unresolveable cross-project edit wars. Someone changes X there in Wikidata, it propagates here, I change X here, that propagates to Wikidata, and who ever did it there, reverts it there, and that propagates back here.... It is just a bad idea. Jytdog (talk) 02:35, 17 September 2017 (UTC)
Jytdog, maybe you read it too hastily? Are you saying "absolutely not" to an RFC on which way to resolve the issue? As I indicated, I think consensus will be for local descriptions. Alsee (talk) 02:59, 17 September 2017 (UTC)
yes i did. struck. What you write about the descriptions thing if a bit off though. The consensus is likely to be just be "no" to any "description" at all, not "yes" to local descriptions. You seem to be begging the question somewhat and accepting the WMF's stance that "descriptions" are needed at all in en-WP articles. Jytdog (talk) 03:06, 17 September 2017 (UTC)
Jytdog, I think duplicating the lead sentence on mobile views of the article would be redundant. I had intended to say "except where it's redundant", but it that got lost during pre-save rewrites. The description is also used in a several other places such as the link-creator button in VE and in the search results at the www.wikipedia.org search portal. It's clearly useful to have descriptions in those places. Using the lead sentence would be a definite upgrade, because many pages have no wikidata description at all. VE and the search portal currently just show a blank description box for those articles. Alsee (talk) 05:08, 17 September 2017 (UTC)

Vandalism on Wikidata

Above, user:Jkatz (WMF) said

"Regardless of our progress, independent research is also beginning to provide us with a more thorough understanding of vandalism on Wikidata. A new study found that vandalism rates on Wikidata have decreased significantly in recent years (from 2013 to 2016) and are quite low: ”... -lately- only between 0.1% and 0.2% of are malicious”."

Technically, this may be correct and seem impressive. However, when I actually look at Wikidata recent changes, it seems to me that a) this is an underestimation, b) this doesn't take into account the median time between vandalism and revert, which seems to be a lot higher than on e.g. enwiki, and c) this doesn't take into account the completely different nature of editing on Wikidata.

On enwiki and on Wikidata, a vandal often makes a quick, small vandal edit. On enwiki, a positive edit is often relatively large though. On Wikidata, by its nature, all edits are "small" edits, and if you want to create an item you need to make many edits. Many positive edits I encounter are semi-automated, repeated tasks, with uncontroversial and often hardly worthwhile data. An edit like this is not worth vandalizing.

To put it differently: an "article" on Wikidata consists of many properties, but only a few are wortwhile for a vandal. The positive edits vs vandal edit rate there is much closer to what we are used to on enwiki, and the reversion times are usually much slower.

Looking at 100 recent changes by IPs, made between 13.45 and 14.20, I note many edits I can't judge (Chinese labels and the like), some which seem positive, and at least 25 vandalism edits. This would mean that in the same period, some 12,000 to 25,000 positive edits must have been made to get the cited percentage (and this assumes that no registered editors made vandal edits). Now, we may well reach this figure, but in this period, approximately 95% of the edits was made by one editor using "Quickstatements", making her (Harmonia Amanda) essentially a maintenance bot.

  • 2 edits first vandalizing and then removing correct information
  • 2 edits vandalizing already incorrect information, which were then semi-reverted, semi-vandalized by 2 further IP edits
  • 8 blatant vandalism edits
  • 4 edits vandalizing Internet
  • 7 vandal edits, reverted 17 minutes later by Izno (thanks)

I know, anecdote isn't data, but I have looked at Wikidata way too much recently, and this rate (and low reversion rate) seems quite typical.

So please, take all statements about the low vandalism rates on Wikidata with a very big grain of salt. Wikidata has a small group of dedicated editors using tools to make small changes very rapidly, and apart from that a very small group of more "regular" editors who are at the moment unable to adequately, rapidly deal with vandalism. This is not the fault of those people who actually do vandalism reversions, and this section is not intended to blame anyone. But the end result is that, compared to the number of editors, Wikidata has actually a high vandalism rate, which doesn't get reverted very fast (I often see easy-to-spot vandalism remaining for hours and days). Fram (talk) 14:40, 14 September 2017 (UTC)

Seems like the issue may be more "a overly large proportion of Wikidata pages contains vandalism at a given point of time". Jo-Jo Eumerus (talk, contributions) 14:44, 14 September 2017 (UTC)
As you say, this is anecdotal. Would a comparative analysis of the vandalism and revert rates between Wikidata and English Misplaced Pages be helpful in putting your mind at rest addressing your concerns, as I perceive them, over vandalism and revert rates? I don't know if I can make it possible to do so, but I can inquire. CKoerner (WMF) (talk) 16:05, 14 September 2017 (UTC)
This reply is already problematic, in its assumption of the desired conclusion ("put your mind at rest") before even doing the investigation that might lead to that conclusion. It suggests that the investigation will be reported by cherry-picking whatever leads to putting your mind at rest, rather than in a properly unbiased way. Again, why is WMF trying to promote the invasive use of a sister project here? —David Eppstein (talk) 16:09, 14 September 2017 (UTC)
Well, revert ratios don't tell us how long vandalism stays around before it's caught, so that wouldn't help (and what about vandalism that wasn't reverted yet). Jo-Jo Eumerus (talk, contributions) 16:17, 14 September 2017 (UTC)
I was asking Fram, and others, if this work would be helpful to bring clarity where some lacks. I don't want to make a request if it's not desired as it could take a substantial amount of work. I've clarified my statement. CKoerner (WMF) (talk) 16:22, 14 September 2017 (UTC)
Here are some examples of longstanding, gross Wikidata vandalism:
  • , . From May 2013 to June 2015, the description of Larry Silverstein on Wikidata read, "In May of 2013, Larry and his pal Tom, confessed to the implosion of the WTC, and later were sentenced to multiple life terms in prison." instead of "American business man". The edit that vandalised the entry conveniently had the full text of that BLP violation in its edit summary.
  • For five months in 2014, Wikidata gave "Adolf Hitler" as an alias of Franklin D. Roosevelt.
  • I promised myself that I would be able to find a new bit of similar nonsense on Wikidata in less than five minutes. I did. The Ozzy Osbourne entry on Wikidata states that "Dross" is an alias of Osbourne's. (Dross Rotzank is a YouTuber who, it appears, looks a bit like Osbourne.) That alias has been on Wikidata since early December 2016.
There isn't the remotest chance that any of those howlers could have stood unchallenged for that long in the respective Misplaced Pages biographies. Do you acknowledge that? Andreas JN466 19:14, 14 September 2017 (UTC)
I think part of the reason is that not enough people see these vandalised entries (and of course not enough people do anti-vandal work on Wikidata). If enough people add the code at d:User:Yair rand/WikidataInfo.js to their Special:Mypage/common.js (or something equivalent), we might have a chance to notice Wikidata vandalism more easily. —Kusma (t·c) 20:23, 14 September 2017 (UTC)
I'm sorry if Fram, or others, got the impression I was ignoring the list. I see the examples and understand folks consider them to egregious. I should have acknowledged that before suggesting action items. A list of vandalism isn't very instructive if I have nothing to compare it to. Is it because we don't have a many eyes on Wikidata? Is it worse that what we'd expect here on English Misplaced Pages? I don't know. Folks telling me it is concerning is useful to know. I'm suggesting maybe we find out more together. CKoerner (WMF) (talk) 21:04, 14 September 2017 (UTC)
User:CKoerner (WMF), how can you ask "Is it worse that what we'd expect here on English Misplaced Pages?" Do you know that little about Misplaced Pages? There are plenty of WMF blog posts pointing out that gross vandalism in the English Misplaced Pages is usually quickly removed. Even if some of those blog posts are a little over-confident about Misplaced Pages's ability to spot and remove such vandalism, is it not very, very obvious that the situation in Wikidata is far worse than what you'd find in Misplaced Pages? Gross nonsense, including nonsense with horrifying BLP implications, lasts for months and years on Wikidata, even in items about public figures that are household names.
Much the same vandalism that happened about Larry Silverstein on Wikidata happened here on Misplaced Pages as well: see and then step through the following 20 edits or so to compare the response in Misplaced Pages, ending here, to that in Wikidata. Andreas JN466 21:24, 14 September 2017 (UTC)
To be honest, I come across vandalism on the English Misplaced Pages which stays in the articles for years on a regular basis. Just one example: this edit from November 2011 was undetected; 13 users in good standing (plus one bot) edited the article like if nothing happened, until I found and reverted it in November 2012 .--Ymblanter (talk) 06:57, 15 September 2017 (UTC)
It happens, but most of the vandalism gets reverted within minutes. On Wikidata, this is within hours instead. Fram (talk) 08:44, 15 September 2017 (UTC)
This is correct, but since there is much more vandalism on Misplaced Pages than on Wikidata, I suspect that there is still more vandalism which stays for hours on Misplaced Pages than on Wikidata. It would be great to have some quantitative estimates.--Ymblanter (talk) 08:52, 15 September 2017 (UTC)
What you had there, Ymblanter, was someone deleting a couple of lines of text and a heading in a text on Greek mythology. No one accused anyone of being Hitler, or of having blown up the World Trade Center, and caused that to be displayed at the top of mobile readers' screens for a year. --Andreas JN466 11:16, 15 September 2017 (UTC)
I find daily on my watchlist in the morning vandalism, sometimes BLP vandalism, which was added during the night and stays there for hours until I revert it. I believe Hitler in the description on Wikidata would be blocked by an edit filter though I might be wrong on this one.--Ymblanter (talk) 13:56, 15 September 2017 (UTC)
One problem with Wikidata surely is how prominently the vandalism is displayed. If you search for the European Commissioner article on the Spanish Misplaced Pages mobile site right now, you see "caquita" ("little shit") displayed in the search drop-down, and then displayed again right under the article title when you read the article itself. A site that's supposed to serve as a central repository informing lots of other WMF and non-WMF projects needs to be a bit more robust and reliable in my view. Andreas JN466 15:17, 15 September 2017 (UTC)
Andreas, I find it quite surprising to suddenly see you coming out as a defender of the English Misplaced Pages's quality and vandalism resistance, considering that for many years you/Wikipediocracy have been advocating exactly the opposite opinion (as can be seen, for example, in various articles that are still linked on your user page), highlighting apparently every case of Misplaced Pages hoaxes, vandalism and BLP violations that you could get hold of.
I think your conclusions about Misplaced Pages back then had the same flaw that your conclusions about Wikidata have now: Cherry-picked example edits are not a substitute for systematic evaluations of the quality of the content as seen by the reader.
Regards, Tbayer (WMF) (talk) 22:27, 15 September 2017 (UTC)
I mentioned above (and elsewhere) that in my view WMF's public communications have had an unfortunate tendency to overstate the reliability of Misplaced Pages, encouraging blind trust in readers rather than critical reading, including checking of references before propagating Misplaced Pages content and so forth. In my view, this has been an actual dereliction of duty by the WMF, which is harming the integrity of human knowledge. Misplaced Pages doesn't need credulous readers and re-users, it needs critical and discerning readers and re-users who understand and are alert to the inherent vulnerabilities of Misplaced Pages's crowdsourcing process.
But whatever problems Misplaced Pages has, Wikidata raises them to a whole new level by importing masses of data from Misplaced Pages projects, many of which have a far less developed culture than the English Misplaced Pages and some of which (such as the Croatian, Kazakh and Azeri Wikipedias) have known, very significant problems that the WMF also keeps mum about in public. Wikidata lacks robust standards (or any standards, really) for reliable sourcing and BLP content. Moreover, as a number of people on this page have pointed out – convincingly to my mind – vandalism control on Wikidata isn't well developed. That's inherent in Wikidata's ambitious scope: people are adding content in dozens of languages that's then prominently displayed to mobile readers. A vandalism patroller on Wikidata has to be able to spot vandalism in Arabic, Hebrew, Pashto and Turkish as well as French, Spanish, Portuguese and English and dozens of other languages ... which makes the task a lot more time-consuming unless you're fluent in 55 languages. And I don't think there are equivalents to ClueBot NG (which does a brilliant job in en:WP) in many of these languages. Those are problems Wikidata needs to address. The pushback you're seeing here is in good part a result of the fact that Wikidata has been struggling to do so to date. --Andreas JN466 09:52, 16 September 2017 (UTC)
Well first, at least with regard to the use of Wikidata descriptions in the app (that has been the focus of contention here), these concerns seem unrelated - the app won't display Pashto Wikidata descriptions above English Misplaced Pages articles. In general, I personally agree that there are some interesting questions here, but I would also be curious how widespread such issues are in practice - have you observed actual mass imports of problematic BLP statements from, say, the Kazakh Misplaced Pages into Wikidata, or is this more a theoretical concern so far? And concerning patrolling, keep in mind that most of the information on Wikidata is language-agnostic (it's meant to be machine-readable, after all), and the language-dependent information (descriptions and labels, in particular) is in a very restricted format that makes it easier to patrol. Speaking as a volunteer editor who has been a fairly active RC patroller on Wikidata for over a year now, here are some vandalism reverts I have made for descriptions in languages I don't speak: . That said, for this slice of content on Wikidata that is language-dependent, it's obviously more efficient if patrollers can focus on changes in the languages they are fluent in, and earlier this year some tools became available for that. Regards, Tbayer (WMF) (talk) 13:13, 16 September 2017 (UTC)
The concerns are related in that it takes a patroller far longer to identify vandalism in a language they don't speak. It means that patrollers are stretched thinner, for all languages. If you spend a few minutes figuring out whether נבוא גלוון המלך של סין is vandalism or not, that means you're missing a number of edits in other languages. As for mass imports from Wikipedias known to be politically corrupted, this is something the WMF could profitably study and keep an eye on long-term (as indeed I have argued WMF and/or partners should study the political content of the Wikipedias themselves that are known to have, or suspected of having, problems around political freedom, with the resulting findings reported to the public). Beyond that, I think it is self-evident that many minor-language Misplaced Pages projects have sourcing standards that are at least a decade behind those of the English Misplaced Pages. I can't see how the content imported to Wikidata from these Wikipedias can remain unaffected by this. Regards. --Andreas JN466 14:25, 16 September 2017 (UTC)
Incidentally, Tilman, is a relative of ClueBot even used to spot English-language vandalism on Wikidata? And are there any other bots designed to revert vandalism in other languages? Something like "caquita" or "pringao" even going through as a description (which is then prominently displayed for mobile users) without instantly being bot-reverted, as it would be here, leads me to think that there isn't one for Spanish at least, but do correct me if I am labouring under a misconception. It's always better to have agreed facts on the table. --Andreas JN466 11:02, 16 September 2017 (UTC)
See this discussion which I started several days ago. Apparently, there is interest in developing such a bot, but it did not yet happen.--Ymblanter (talk) 11:07, 16 September 2017 (UTC)
Andreas, to quote from Jon's statement above:
"Here are some steps particularly around the area of vandalism: Introduction of anti-vandalism bots making automated reverts of edits that are very likely to be vandalism"
The bot linked there has been up and running, here are some of its recent auto-reverts:
Regards, Tbayer (WMF) (talk) 13:13, 16 September 2017 (UTC)
These are good reverts, but the system's level of sophistication still seems to lag considerably behind ClueBot NG, judging by the obvious cases still slipping through. And can't ClueBot NG be adapted to run on WD? There may be problems with that idea that I'm ignorant about, but I'm surprised this wasn't done years ago. Best, --Andreas JN466 14:25, 16 September 2017 (UTC)

Hi Fram, there are some thoughtful observations and hypotheses in what you wrote. However, I'm not convinced by these assumptions:

  • On enwiki and on Wikidata, a vandal often makes a quick, small vandal edit. - you mean a small impact on the content?
  • On enwiki, a positive edit is often relatively large though. - and often not, just look at the amount of minor edits in recent changes.
  • On Wikidata, by its nature, all edits are "small" edits, and if you want to create an item you need to make many edits. - The creation of an article on Misplaced Pages often involves many edits too, and in any case such initial creation activities form only a small minority of edits overall. The actual number of edits per article or item contradicts your assumption: it's much higher on Misplaced Pages (96) than on Wikidata (17).
  • Many positive edits I encounter are semi-automated, repeated tasks, with uncontroversial and often hardly worthwhile data - same on Misplaced Pages: formatting tweaks, typo fixes, edits that update a single number...
  • approximately 95% of the edits was made by one editor using "Quickstatements", making her (Harmonia Amanda) essentially a maintenance bot - it may be a big mistake to exclude such edits from calculations, considering that a lot of the descriptions (the vast majority as I seem to recall from one data analysis I did a while ago, would need to check the exact numbers) are added or substantially changed by Wikidata editors using such tools. For example, generic descriptions such as "American actor" or "surname".
I'm all for exploring the subtleties of such research results, and different ways of looking at the data. (By the way, if someone wants to actually read the paper and write a review, these are always welcome in the "Recent research" section of the Signpost, doubling as the Wikimedia Research Newsletter, that I have been editing with others since 2011. Let me know if you are interested.)
But so far, as an attempt to discredit "all statements about the low vandalism rates on Wikidata", the above looks not very convincing to me. To explain away such a conclusion by seven independent academic researchers, one needs more than such unproven assumptions (some likely false, see above) combined with anecdotal data and minuscule samples.
Regards, Tbayer (WMF) (talk) 22:30, 15 September 2017 (UTC)


So, after I posted the above list of vandal edits, I took another set of seven vandalized articles to see how fast such vandalism gets reverted at Wikidata.

I didn't filter out immediately reverted vandalism, these were simply the first ones I encountered and easily spotted in the recent changes. It is obvious, every time I look at it, that vandalism patrol at Wikidata is way, way too slow to be acceptable as a source for any info on enwiki at the moment. Fram (talk) 07:31, 15 September 2017 (UTC)

There seems to be a lack of manpower in Wikidata ... and it's a multilingual problem. I pity the patrollers. User:YMS seems to have done about half the recent vandalism reverts by himself.
Even so, the following were easy to find; they are all unreverted IP vandalism in Wikidata's recent changes. I focused on descriptions only, as displayed in searches and at the top of mobile screens: 2 days, 2 days, 2 days, 1 day, 1 hour ("dickhead").
You'll need to find more people volunteering for what's a Sisyphean and mind-numbing job, along with ClueBot-level AI tools in dozens of languages. A tall order. --Andreas JN466 14:12, 15 September 2017 (UTC)
@Jayen466: Sorry, I don't have the time to dive into this discussion now, but I would be personally interested in how you came to the conclusion, that I am doing half of the patrols? Just from looking in the logs, or is there a way or place where I find accumulated numbers? Thanks for telling me. --YMS (talk) 11:28, 16 September 2017 (UTC)
@YMS: It was just based on my scanning recent changes for vandalism. Of the ones I found that had been reverted, more often than not it was you who had done so. Best, --Andreas JN466 22:35, 16 September 2017 (UTC)
Found some statistics now: (includes data up to December 31, 2016) shows 16 users with more than 10'000 reverts. However, 9 of those are bots, and they are hardly used to actively fight vandalism, but more likely just randomly restore old versions if someone e.g. removed a label or edited a sandbox item. Of the 7 human users, I'm number 3 there, but I very much increased my vandal-fighting activities in 2017, while I'm not aware of any particular recent activities in this field of the top 2. @Erik Zachte: Would it be possible without too much effort to get a more up to date version of those stats? Because since February, I'm using an RC tool that I developed, which is not stable enough for public use yet, and I was unsure whether I should ever release it. If it would turn out that now I'm actually doing an overly large portion of the RC work, I guess this would indicate that this tool is actually quite powerful, and should get available for others. --YMS (talk) 15:36, 18 September 2017 (UTC)
Here is a look at the Misplaced Pages vandalism reverts I have made as a volunteer editor so far this month (September 2017), and how long the vandalism had remained live in each case:
(Does not include some reverts of possibly good-faith edits, such as this likely hoax: 3 months.)
Regards, Tbayer (WMF) (talk) 14:31, 15 September 2017 (UTC)
Which shows that we are far from perfect, but ignores the number of vandalism reverts made immediately or near immediately. The one you show are the ones that feel thorough the cracks (and yes, there are too many of those); the one I showed were all the vandalism edits from that time period from IPs (all the ones I could easily spot at least, I haven't checked identifiers, arab descriptions, ...). The experience you have with some edits remaining unnoticed for too long is what happens to (nearly) all vandalism on Wikidata. Fram (talk) 15:08, 15 September 2017 (UTC)

Let's take a step back up and get a sense of perspective:

  • According to the most recent data available on Wikistats , the ratio of reverted article edits on the English Misplaced Pages is 8.1% (higher when excluding bot edits - likely >10% -, and 19.4% for anonymous edits)
  • According to the cited paper by Crescenzi et al, the ratio of reverted (damaging) edits on Wikidata, excluding bots, is between 0.1% and 0.2%.

In other words, the ratio of vandalism edits on Misplaced Pages may be up to two magnitudes (50 to 100 times) higher than on Wikidata - quite contrary to the impression given in some comments above.

And according to the same Wikistats page, English Misplaced Pages sees 3.8 million reverts per year. That's enough to cherry-pick from to fill entire books with embarrassing examples.

Yes, there are some subtleties, e.g. around the exact definition of reverts (note though that each ratio is an apples to apples comparison). And I think Fram made a valid point that the speed of vandalism cleanup (e.g. the mean or median time to revert) needs to be considered too. But so far nobody has presented solid data on the latter. (Again, a spot check of only a few edits at a specific moment in time is not a valid way to do this.) And even if the vandalism cleanup on Wikidata was, say, 10 times slower than on Misplaced Pages on average, that would still mean that the relative impact of vandalism on what the reader seens is 5-10 times higher on Misplaced Pages than on Wikidata. That's not even considering that Wikidata has vastly more items (35 million) than English Misplaced Pages has articles (5 million).

The data question that's IMHO most relevant for the current debate has not been examined yet: How likely it is that the reader will see a vandalized version when they look either at a Misplaced Pages article or its corresponding Wikidata description. Gathering this data might take some time but could be worthwhile.

Regards, Tbayer (WMF) (talk) 23:10, 18 September 2017 (UTC)

Not sure if, when you say, "the current debate", you mean this round of discussion of Wikidata in WP. Assuming you are, IMHO vandalism is not the most important issue. I would put it way below the WMF making content decisions without getting consensus, and the differences in policy and governance between Wikidata and en-WP.
Vandalism is a problem everywhere but is not really The Problem. The more meaningful thing to measure would be "bad edits". Whether they are intentional or not, bad edits are what harm WP, and there are definitely way more than whatever is being counted as "vandalism".
The problem about the pneumonia article that Doc James mentioned above, was created by someone running a bot at Wikidata that added what they thought was "useful" information about "drugs useful to treat X" which filled that field with garbage. Bad edit. Not vandalism. And via inboxes that bad edit to Wikidata effected many, many en-WP articles. We killed that field so that can't happen anymore. But this is the kind of thing that needs to be considered; not just "vandalism". Jytdog (talk) 23:33, 18 September 2017 (UTC)
Hi Jytdog, I said "the data question that's IMHO most relevant for the current debate", not necessarily the most important issue overall. I did get the impression that vandalism seemed to be the most important concern to several commenters on this talk page (cf. the length of this section), but you clearly feel different and I did not mean to dismiss that.
Regarding the pneumonia example (i.e. this controversy between medical Misplaced Pages editors and scientists from the ProteinBoxBot team), I lack the topic expertise necessary for forming a definite opinion about who was right, so I'll take your word for it. We should keep in mind though that this case was about displaying Wikidata information in an article's infobox, which is separate from the issue of displaying Wikidata descriptions in the apps. The apps certainly don't do the former on their own and (cf. Jon's statement) the Foundation does not plan to change that.
Regards, Tbayer (WMF) (talk) 00:10, 19 September 2017 (UTC)
Where to start with this one... That Wikidata has vastly more items is because they are indiscriminately importing whole databases, creating e.g. every potential source as an item. These are not used anywhere, not shown anywhere, and vandals would have very little reason to edit these. That Wikidata has vastly more unproblematic edits is because they need vastly more edits to get some result (e.g. adding the same label in 10 languages = 10 edits), and many of the "edits" at Wikidata are not even real edits there (just like many "editors" at Wikidata have never actually edited Wikidata (I supposedly have some 250 Wikidata edits, but I never edited Wikidata except three or four test edits in 2014). "The data question that's IMHO most relevant for the current debate has not been examined yet: How likely it is that the reader will see a vandalized version when they look either at a Misplaced Pages article or its corresponding Wikidata description." Like I said below, this is a general page about the use of Wikidata on enwiki, not specific to the case of the descriptions. I started this as a separate section to highlight vandalism issues in general, not vandalism of the descriptions specifically (though that is one of the more often vandalized statements).
I also asked below where the 50 million or so sources in the last month have come from, and which "editors" made these. It is the kind of thing that makes me doubt any statistics about this, as it seems unlikely. Fram (talk) 07:14, 19 September 2017 (UTC)
Your final statement seems right to me: the key question is "How likely is it that a reader looking at corresponding data on the two sites will see vandalism?" Re your earlier comments: pulling some numbers from memory, I think I recall studies showing that the average revert time on en-wiki is about five minutes. Certainly Cluebot must bring the average down pretty low. If that's right, then if there are, as you say, 100 times as many vandalism edits on en-wiki as on Wikidata, the revert time would have to be more than about 500 minutes -- 8 hours or so -- for it to last longer. Fram's sample data is certainly not rigorous, but it does at least make it plausible that the average revert time is much longer than that.
I also suspect (with no data to support me) that vandalism is more likely on items corresponding to Misplaced Pages pages, and less likely on data imported from vast technical databases such as genetic data; if so, that would increase the visibility of vandalism on Wikidata.
Despite both the above points, I think vandalism is a secondary issue. If the interface to Wikidata permitted an editor to see article vandalism (as the script for Wikidata descriptions does); and to see it in one's watchlist too (which is not usefully possible at the moment); and to revert it from a WP page (not possible at all); then I think the vandalism would mostly get reverted from en-wp. Those enhancements seem necessary to me for other reasons, so I don't think vandalism is the real reason for resistance to Wikidata integration. It's just the consequence of the lack of integration. Mike Christie (talk - contribs - library) 23:41, 18 September 2017 (UTC)
  • This is kind of dumb discussion. Wikidata isn't "read" and there aren't "readers" of Wikidata. Wikidata is "used". You run queries, build graphs, etc. It is data. With regard to vandalism if I move a decimal in a field in Wikidata, somebody "seeing" that is a really different process that somebody "seeing" vandalism in en-WP. (People maybe "see" vandalism in Wikidata by running some query and having one of the results be a funky outlier, and they go to find out why, and find a vandalized field. That sort of thing)
Part of the problem with the WMF grabbing the "description" field and slathering it all over the place, is that the description field is probably one of the very few fields in Wikidata that is meant to be read by humans and is the kind of content where Wikidata is weakest, policy and governance-wise.... It just not the kind of thing that Wikidata was built for - and this difference in kinds of content is probably the main reason why the policies and governance is so different between the projects.
But WMF chose probably the weakest field in Wikidata, to put all this weight on. Which is one of the things that is so hard for me to understand. Jytdog (talk) 00:43, 20 September 2017 (UTC)

Misplaced Pages descriptions vs Wikidata descriptions

An experiment with article descriptions. My hypothesis: that we could get better descriptions by taking the first sentence of article text (up to the first full stop) and stripping any parenthetical clauses than we could be looking at Wikidata. After the first few examples, I modified the hypothesis to also include stripping any text before the words "is"/"was" (and the following article if any), if it appears in the first sentence. Test set: articles generated by the "random article" button, without any filtering from me.

Article Misplaced Pages lead Wikidata description
Sara Lampe Democratic Party member of the Missouri House of Representatives, representing District 138 since 2004 American politician
Anogeissus leiocarpa tall deciduous tree native to savannas of tropical Africa species of plant
Black Lightning (2009 film) 2009 Russian action superhero film directed by Alexandr Voitinsky and Dmitry Kiseliov, and produced by Timur Bekmambetov 2009 film by Aleksandr Voytinskiy, Dmitriy Kiselev
Frank Lammers Dutch television and film actor Dutch actor
Katzie First Nation band government of the Katzie people of the Lower Fraser Valley region of British Columbia, Canada (none)
Military art characterized by its subject matter rather than by any specific style or material used works of art on military themes
Lunsford L. Lewis American attorney and politician American politician
Conopomorpha chionosema moth of the Gracillariidae family species of insect
Victor Scantlebury Acting bishop of the Episcopal Diocese of Central Ecuador (none)
Oļegs Aleksejenko former Latvia international football midfielder footballer
Massilia kyonggiensis Gram-negative and rod-shaped bacterium from the genus Massilia which has been isolated from the surface of a soil sample from a forest in Suwon in Korea species of prokaryote
Run for Your Wife (1965 film) 1965 Italian comedy film directed by Gian Luigi Polidoro 1965 film by Gian Luigi Polidoro
Oliver F. Atkins American photographer who worked for the Saturday Evening Post and as personal photographer to President Richard Nixon American photographer
Jones Motor Company historic U.S. Route 66-era building located on Central Avenue in the Nob Hill neighborhood of Albuquerque, New Mexico (none)
Isosauris genus of moth in the family Geometridae genus of insects
Geoff Valli former New Zealand rugby union player New Zealand rugby union player
Albion, Oklahoma town in Pushmataha County, Oklahoma, United States town in Pushmataha County, Oklahoma
Chrysanthos of Madytos Greek poet, chanter, Archimandrite, and Archbishop, born in Madytos Greek archimandrite, chanter and teacher of music
Cape Wilson (Ross Dependency) bold, rocky, snow-covered cape, forming the south-east end of the Nash Range and marking the northern entrance point to Shackleton Inlet on the western edge of the Ross Ice Shelf headland in Antarctica
German submarine U-1019 Type VIIC/41 U-boat of Nazi Germany's Kriegsmarine during World War II (none)
Every Little Whisper song co-written and recorded by American country artist Steve Wariner (none)
Lepa Lukić Serbian folk singer with a career spanning more than five decades singer
Bogenbay Batyr famous Kazakh warrior from the 18th century Kazakh warrior
Danish Committee for Aid to Afghan Refugees non-political, non-governmental, non-profit humanitarian/development organization working to improve the lives of the Afghan people since 1984 organization

Conclusions: It's hard to say which is better. The Misplaced Pages text is more reliably present and usually significantly more detailed, while the Wikidata text can be vague to the point of uselessness ("organization"). But I think that the simple syntax-based stripping that I initially hypothesized isn't good enough to get uniformly concise descriptions. Some sort of natural language processing method that recognizes dependent clauses and strips them when the description is too long might work, but at some point any sufficiently advanced hypothetical system becomes indistinguishable from the work of human editors. (E.g. for Jones Motor Company, it would be nice to strip down the Misplaced Pages text to "building in Albuquerque, New Mexico" but that seems too advanced to expect software to handle automatically.)

Nevertheless, I think that the Misplaced Pages text is reasonably usable as-is, and avoids all the political issues with importing Wikidata text of unknown provenance and incompatible sourcing policies. If we posit that the WMF has a real problem (how to describe article links in mobile views) and is merely taking the wrong solution to it, this could provide an alternative solution that is more palatable. —David Eppstein (talk) 19:39, 14 September 2017 (UTC)

If we use the lead sentence, we already have a pre-built solution. The relatively recent hovercards/article_preview_popup project has already done the work reviewing various cases of what should be stripped or included. To a rough approximation, it trims out things in parenthesis. Alsee (talk) 21:32, 14 September 2017 (UTC)
@David Eppstein:: your table is exactly what the solution should look like. Any user should be able to bring up (in a tool, on Misplaced Pages, whatever) their watchlist with the lead sentence and the (Wikidata description/to-be-created Misplaced Pages short description to be used in searches, VisualEditor, etc.). And the right hand column should have little edit pencils to fix the description entries. That, plus watchlist updates on visible Wikidata changes (ideally, with more user friendly way to fix them) would be the right package. (The watchlist updates is this item on Phabricator).
(Conversely, the Wikidata interface—which needs work, imho—should get a tool that brings up opening paragraphs of linked Misplaced Pages pages to aid in data entry over there.)
Having short descriptions is good for Misplaced Pages and good for Wikidata. We're talking about WP search functionality and ease of editing/wikilinking, especially on VisualEditor. Having the Wikidata descriptions automatically defer to those created by Wikipedians is probably good for Wikidata in all or almost all cases.
I support fixing this. I support solutions in which Misplaced Pages and Wikipedians can improve a still-new-ish project at Wikidata which needs this information. It's neighborly and produces a real synergy for us. However, I oppose "Get off my lawn!"-style solutions that don't enable the functionality that a short description field provide, or pointless wall us off. (Acknowledging that more openness can only come when Wikidata has more policy maturity around V, BLP.)--Carwil (talk) 17:25, 15 September 2017 (UTC)
Is there any sort of standard or MoS for these short descriptions? My opinion is that they should be created and maintained on Misplaced Pages, for Misplaced Pages and by Wikipedians. If the physical location of the stored material is somewhere else, it makes no difference to me provided I can edit and watch it from Misplaced Pages via my usual browser on my desktop or laptop. I do not use a mobile for internet as I have difficulty reading it, and this is unlikely to change for the better. Wikidata can house it if they like, no worries. · · · Peter (Southwood) : 12:58, 18 September 2017 (UTC)
See also: wikidata:Help:Description. They function mostly as disambiguators. So, short but just descriptive enough that you can tell two things with the same name easily apart. If more than 6-10 words, it's likely too long. In terms of length, you would normally have, Title, wikidata description, hovercard aka page preview, wikipedia lead, wikipedia article. —TheDJ (talk • contribs) 14:27, 18 September 2017 (UTC)

"In contrast, Wikidata has sources to most of the statements, these sources are reliable by Misplaced Pages standards, and the share of these sourced statements increases."

This claim, and ones similar to it, have been made a few times in these discussions. However, somehow these reliably sourced statements seem often to elude me when I actually look at Wikidata items. Using the "random item" selector, I get (excluding categories, templates, ...)

The pattern seems very obvious: if you have a Wikidata item which corresponds with a Misplaced Pages article, the vast, vast majority of statements is unsourced (or Misplaced Pages sourced, which is essentially the same). The well-sourced items are bot-created, database-scraped entities which nearly always don't correspond with Misplaced Pages articles. So for our purposes, to judge whether Wikidata items are well-sourced or not compared to Misplaced Pages items, the answer has to be a clear "no". Fram (talk) 13:35, 18 September 2017 (UTC)

Well, if something escaped your attention it does not yet mean it does not exist. Nikkimaria, a staunch opponent od Wikidata, brought this references above in the discussion: . It shows that over 50% of Wikidata statements are sourced to sources different from Wikimedia projects. In fact, the absolute majority of these statements are databases which obey WP:RS. The small minority are junk sources such as Find a Grave. The same graph shows that the share steadily grows. The real problems are that (i) most of these referenced statements come in the items such as Q27970632 (note that the image is sourced to Commons which in this way is a perfectly valid reference, as you yourself argue above, and the reference URL is not sourced because it could be only sourced to itself - and thus the item is only 80% formally reliably sourced though in fact it is 100%) which are not among the first topics we see on Misplaced Pages. (ii) at some point, a mistake (in my opinion) was made, and bots brought a lot of Misplaced Pages statements to Wikidata adding "imported from xxx Misplaced Pages" rather than making an effort to find actual sources. This is being corrected but still can take a couple of year to reduce the share of such sources to a negligible number; (iii) descriptions can not be sourced by construction, and they seem to be the most visible things for the time being. In my opinion, they are useful for working on Wikidata (no opinion for Misplaced Pages, I do not use the mobile version as I find it extremely inconvenient for editing), but likely not ready for use in Misplaced Pages.--Ymblanter (talk) 14:17, 18 September 2017 (UTC)
The main thing I got here from Fram was "The well-sourced items are bot-created, database-scraped entities which nearly always don't correspond with Misplaced Pages articles." Agree, disagree? It's irrelevant (for the discussion we're having on this page) if Wikidata has well-sourced items, if those items aren't likely to be displayed on Misplaced Pages. - Dank (push to talk) 14:22, 18 September 2017 (UTC)
Yes, I agree. Wikidata currently has 39 million items, and this number can not be maintained by human effort.--Ymblanter (talk) 14:47, 18 September 2017 (UTC)
Well, actually, to make a positive statement, indeed, a lot of statements were imported to Wikidata and labeled as "Misplaced Pages sourced". However, they, whereas being unsourced, contain the same information Misplaced Pages already has. (let us not talk about differences between different language versions, this is small fraction anyway). Restricting this info will likely have no effect on Misplaced Pages. However, information imported by bots directly from databases is reliably sourced, up-to-date, and typically is not on Misplaced Pages. Restricting this information is luddism.--Ymblanter (talk) 14:57, 18 September 2017 (UTC)
"However, they, whereas being unsourced, contain the same information Misplaced Pages already has." No, they have at best the information Misplaced Pages had at that time. "However, information imported by bots directly from databases is reliably sourced, up-to-date, and typically is not on Misplaced Pages." The percentage of such information in items with an enwiki article is very, very small (a few specific niche topics excluded). Most bot-included "information" is long lists of scientific articles, newspaper articles, ... or long lists of usually not very interesting (or at worst unreliable) identifiers. Actual, encyclopedia-like information on enwiki subjects is very hard to find among the bot edits, and is usually still the work of humans. "Luddism" is a nice FUD call, but has very little to do with this. Fram (talk) 07:22, 19 September 2017 (UTC)
I do not think you address my point. Indeed, Wikidata contains all kind of info, of which 90% is possibly not even usable on Misplaced Pages. On the other hand, only a very small share of information in Misplaced Pages articles can even in principle (current problems aside) be imported from Wikidata. Therefore it is irrelevant what percentage of informaion from Wikidata is currently used on Misplaced Pages, and what percentage of Misplaced Pages information is coming from Wikidata. The relevant question (for Misplaced Pages) is what information in principle can be imported from Wikidata, and what would be the provenance of this information. There are indeed some "specific niche topics", how you call them, and, indeed, the usage of Wikidata will never go beyond these specific niche topics. This is perfectly ok, because the Default Language Misplaced Pages is not the only Wikidata reuser (I am not sure it is actually the biggest reuser). Therefore, for example, it is irrelevant that references are stored in separate items on Wikidata, and these items will never have Misplaced Pages articles about them. What is relevant is that some (a very small fraction) of these sources are used on Misplaced Pages, and that they can be directly loaded to any Misplaced Pages page (which will become more complicated after {{Cite Q}} is deleted). And these references were imported by bots from databases, and I do not see (apart from some technical problems which are fixable) how one can claim that these sources are not reliable or have unclear provenance (actually if they have unclear provenance they can be deleted according to Wikidata policies).--Ymblanter (talk) 07:39, 19 September 2017 (UTC)
What's the point of writing an article, using a source, and then needing to go to Wikidata to check if that source is perhaps available there as well, and then try to get the source to be displayed correctly through some template (which in most current cases was problematic or simply wrong)? All of this because perhaps someday the reference needs a change, and then if the source is used on multiple pages it would be faster to do this on Wikidata, if you are lucky. When you couple this with the effect that the page gets more opaque for casual editors, making it harder to correct a source in many cases, I don't see where the benefit is supposed to be. That's not luddism, that's comparing pro's and con's and drawing a different conclusion than you and some others do. Fram (talk) 08:22, 19 September 2017 (UTC)
References might not be the best example because they indeed change very seldom if ever. There are, however, two issues. Indeed, references one typically adds by humans in Misplaced Pages articles, and often it would be inappropriate to add them automatically and by bots. There are examples however when references are quite appropriate to add by bot, for example, for listed buildings which are referenced to national databases of protected heritage. Especially of these databases are not in English, it is unlikely that references would be added by editors en masse, but they can be added by bots no problem from Wikidata, and I do not see any issues with this automatic addition. Furthermore, there are other things which change on a regular basis, are used in Misplaced Pages, and are pain in the ass to update by humans. An example is population; there are some issues with European databases (license incompatibility), but for the US and Canada I believe Wikidata is reliable (or, if I am wrong, it can be easily made reliable), and then the population data in zillions of Misplaced Pages articles could be either read directly from Wikidata, or updated by bots on a regular basis.--Ymblanter (talk) 09:13, 19 September 2017 (UTC)
I'm not a "staunch opponent od Wikidata". I think that in theory the concept has merit. What I am an opponent of is poor sourcing practices and standards, as demonstrated in discussions like this one or this. And unfortunately, that graph underestimates the number of poorly sourced statements. On the one hand, it includes statements that this wiki would term BLUE, or that are truly self-sourcing. On the other, it includes hundreds of Wikia references, thousands for IMDb, etc. Nikkimaria (talk) 14:35, 18 September 2017 (UTC)
My apologies for labeling you as Wikidata opponent, this was my impression which I got from your statements I have seen on Wikidata and here. Anyway, I fully agree that statements sourced to junk (such as Wikia) should not propagate anywhere. It is not difficult to organize, and, in my opinion, this would be a much more constructive approach that "OMG! They have citations to Wikia!! They are nowhere close to reliable!!! We should prohibit any propagation of data from Wikidata to the (default language) Misplaced Pages".--Ymblanter (talk) 14:51, 18 September 2017 (UTC)
The English Misplaced Pages includes thousands of Wikia references and (at least) tens of thousands of IMDb references when measured this way. Regards, Tbayer (WMF) (talk) 14:54, 18 September 2017 (UTC)
No, they include thousands of links to these sites. Have you even looked at what you linked? In your first 100 so-called "Wikia references", there is 1 (ONE) mainspace article, Wikia itself. Looking at the bottom of your list, these are external links, not references. These are comparable to the identifiers Wikidata sees fit to include to Freebase, Quora, Findagrave... but are not what we are discussing here. For someone so eager to dismiss all Wikidata criticism for perceived failures, you really should do a better job in presenting your side of the equation. Fram (talk) 15:16, 18 September 2017 (UTC)
My claim is not that enwiki is perfect with regards to sourcing by any means. However, (a) many of those links are not used as sources, and (b) enwiki does have policies and practices that allow poor sources, and material supported by poor sources, to be removed, whereas at the moment Wikidata does not. The major sticking point as I see it isn't that Wikidata has unsourced or poorly sourced statements, it's that there seems to be a widespread culture that does not perceive that as a problem to be addressed, and that there are no agreed-upon and enforced site policies for addressing it. Nikkimaria (talk) 15:35, 18 September 2017 (UTC)
Wait, Fram, so you are proclaiming the outcome of a comparison between Wikidata and Misplaced Pages ("to judge whether Wikidata items are well-sourced or not compared to Misplaced Pages items") without having examined any statements on Misplaced Pages? What's the percentage of sourced statements there? Speaking as a volunteer Misplaced Pages editor who has put a lot of work into enforcing sourcing (you can find many thousand edit summaries in my contributions list that refer to WP:V) I continue to be surprised at some of the assumptions about Misplaced Pages in the discussions on this page. Regards, Tbayer (WMF) (talk) 14:54, 18 September 2017 (UTC)
Feel free to present your case wrt Misplaced Pages sourcing. Does Wikidata even have a "fact" tag or anything similar? Lambda-CDM model, one of the Wikidata items above, clearly has a lot more references here than on Wikidata. Multiracism, the other one with an enwiki article, also has relevant, reliable references. Do all articles here have those? Of course not. But at least I don't proclaim the superiority of Misplaced Pages based on some inflated figures which fall apart when you take a closer look at them. Using Wikidata in Misplaced Pages items "because more than half of the Wikidata items are reliably sourced" (to paraphrase some statements) is starting from a completely wrong position. Fram (talk) 15:23, 18 September 2017 (UTC)

Does anyone have any idea what happened between 24 July 2017 and 21 August 2017? In these 28 days, Wikidata got 4 million new items, and nearly doubled the number of "reliable" sources (i.e. "Statements referenced to other sources") from 55 million to 102 million statements.

This means that in 28 days, 47 million statements were sourced (not to Misplaced Pages). I can't immediately find info on which bots are responsible for most of this (assuming the numbers are correct). It doesn't seem to be Succubot (the most active bot), which doesn't add sources to statements usually apparently. Botninja isn't the culprit either. Neither is ValterVBot, Dexbot, Krbot, ... Fram (talk) 15:10, 18 September 2017 (UTC)

Doing the above again, but now only for items that also have an Enwiki article.

So, a small sample of 5 items again confirms that, for items which have an enwiki article, sourcing on Wikidata is on average considerably worse than on enwiki. Fram (talk) 16:35, 18 September 2017 (UTC)

WMF Annual plan 2017/18: Program 10 Wikidata

Employee chain sawing to control exotic invasive melaleuca

Reviewing this link provided above, one finds:

  • Outcome 2: Continue to increase the reach of Wikidata into the Wikimedia projects. We aim to significantly increase the instances of data uses from Wikidata by Wikimedia projects. We will achieve this by removing barriers for editors on Misplaced Pages and enabling new kinds of data to be collected within Wikidata and Wikimedia Commons — thereby making Wikidata more useful to the other projects..

-- Jytdog (talk) 15:49, 18 September 2017 (UTC)

I have no object to the goal of increasing use of Wikidata, if it's done by "removing barriers for editors on Misplaced Pages". Much of the discussion above is about barriers. Not all the barriers (control of vandalism, implementation of BLP and V policies) are under the WMF's control, but the software interfaces are. With the right interface I could see Wikidata being very useful, particularly for stable well-sourced data that comes from external reliable databases. It's the definition of "right interface" that's difficult. Mike Christie (talk - contribs - library) 16:34, 18 September 2017 (UTC)
To clarify, this is not an aim of the Foundation per se, but of the Wikidata team at the Geman Wikimedia chapter, as noted on top of the linked section ("Team: Wikidata (WMDE)" - I agree it's a bit confusing because the overall page is called "Wikimedia Foundation Annual Plan", IIRC the aim was to provide an integrated overview over technical work).
As explained in Jon Katz' response above where that annual plan page was linked, "Currently, experiments and plans for further Wikidata integration into Misplaced Pages projects exist, mostly driven by the Wikidata community and Wikimedia Deutschland, not the Foundation.... the Wikimedia Foundation has no concrete plans for integrating other data from Wikidata with Misplaced Pages". Regards, Tbayer (WMF) (talk) 16:50, 18 September 2017 (UTC)
The page is called "Wikimedia Foundation Annual Plan/2017-2018/Final/Programs/Product". This is stated as an aim of WMF. Jytdog (talk) 16:55, 18 September 2017 (UTC)
I want to understand the roots of this, so we can pull it up by the roots. As I noted above, it is bizarre that a WMF product manager came here advocating for integration of Wikidata. I want to spend my volunteer time working on content, not cutting down instances of invasive species. The WMF doing this, is not like a weed though. It isn't organic; the WMF is clearly committed to pushing Wikidata into en-WP. That is actually manageable. (Individuals doing stuff is an entirely different matter) Jytdog (talk) 16:56, 18 September 2017 (UTC)
Hey Jytdog, I'm back again to try and provide an alternative perspective. but first, let me be sure I understand. Wikidata is the invasive species. The foundation introduced it by adding the descriptions*. Not the first case of species being present outside of its native environment†, but the one that is most egregious (in your view).
The Wikimedia Foundation as a whole (not just a specific person or team) should have known it was an invasive species and not introduced it.
The foundation didn't, and it's grown "everywhere".
Now this is where I think some of the thinking diverges. I personally would say that it's impossible to remove in its entirety. However, we can build controls, learn from our mistake (to avoid other invasive species being introduced), and move forward on the technical, policy, and quality concerns.
I think you have a different opinion. What is your suggestion on what to do next?
As for the root of how this happens? Humans were involved. Different folks at the foundation at different points in time thought, "Hey, short descriptions would be handy here. Let's use Wikidata, it's part of the movement and seems innocuous" Then someone else on a different team said, "Yeah, particularly on mobile where screen space is limited". And so on. Next thing you know, they're everywhere. That's it. The foundation is very bottom-up in many capacities. We're more tightly associated than individual editors, true. However there is much agency in developing our annual plans and the quarterly goals to enact those plans. Not to say we don't have a unified strategy or the traits of a hierarchal organization, just that the bottom-up approach is moored in our history and persist to today. A very different experience than any of my previous employment (higher education, healthcare)!
Which means, no secret plans. It's really hard to have them when there are more folks working on developing them than just a few higher-ups. In fact, including it in our most strategic and important plan - the Wikimedia Foundation Annual Plan - that goes to FDC for review(!) shows that we are trying to be transparent and not sneak anything past anyone at any level.
Jon was telling the truth that there are no immediate plans for the foundation to do this work. Most of it is from Wikidata folks, with the exception of the Structure Data on Commons project. I can only find reference to Wikidata in the coming quarter's plans around that project.
I don't know if that help explains the roots, but it's the trunk of the situation. I look forward to your response.
*And prior to the descriptions it was introduced in mobile search results, and prior to that, the visual editor link inspector, and prior to that approving Wikidata as a good idea back in 2012.
† Some would argue that Wikidata, like it's cousin Vicimedia Commonus, is an example of natural long distance dispersal.
CKoerner (WMF) (talk) 19:17, 18 September 2017 (UTC)
Why view it as an invasive species? I'd argue that it's something that has grown internally in the Wikimedia ecosystem (it's not being forced on us by some other agency, it's something that at least a given set of Wikimedians wanted), and it's doing quite well, so it's spreading - but not invading... Thanks. Mike Peel (talk) 00:02, 19 September 2017 (UTC)
Chris, thanks for that reply. I am not questioning if Wikidata is a good thing. Sure it is. This is about using Wikidata in en-WP. How hard is it to remove the Wikidata description from the head of en-WP articles where WMF has put it? Seems like not that hard...
Mike Peel, a "weed" is a plant growing in the wrong place. (like "dirt" is matter in the wrong place). Wikidata is another movement project and there is nothing intrinsically wrong with it. But it is different from Misplaced Pages - different policies and different governance govern its content. It keeps poking into en-WP in inappropriate ways. Some of that is done by individuals who are enthusiastic and those instances need to be handled as they come. The stated goal in the WMF goals, of centrally looking for ways to integrate it, is different as it is "top-down" and able to make very wide-ranging changes, like adding the description field to every single en-WP article displayed in VE or the apps, etc. It is that central drive that makes it more like kudzu. That is what I want to uproot - that needs to be done with consideration of the different policy/governance between the projects and done with consensus, case by case. Jytdog (talk) 00:19, 19 September 2017 (UTC)
@Jytdog: If you want a gardening analogy, I'd suggest that Wikidata is more like adding a lawn to a garden - it fills in the blanks between the more interesting borders/features (Misplaced Pages articles), and does so in a better way than paving slabs (*maybe* dab pages? IDK) or a dirt yard (although I'd view this more as the absence of matter in this analogy). ;-) I think the WMF plan could have been worded better, to talk more about 'enabling' as a goal than 'increase the instances of data usage', but I think this comes through in the methodology (the 'removing barriers' and 'enabling new types of data' bits. Please remember that the goals aren't just about enwp - they are about all of the Wikipedias, and other language Wikipedias approach things quite differently (e.g., see the cebwp case). I don't think that the cases of Wikidata usage in enwp have been inappropriate, but I think they have been prototypes/new growths (and I include my own work here), that need fair evaluation and encouragement to grow in the right ways (sorry, back to gardening here), not just uprooting or cutting off at the base. (For transparency, I should note that I was involved in reviewing this WMF plan, and WMDE's annual plans that included Wikidata, when I was a member of the Funds Dissemmination Committee - but my views are my own, as always. ;-) ) Thanks. Mike Peel (talk) 00:45, 19 September 2017 (UTC)
The differences between the cultures of the projects needs to be taken seriously. Instances where that is not done are weedy. Jytdog (talk) 01:11, 19 September 2017 (UTC)

Concerns raised around Wikidata descriptions on English Misplaced Pages

Hey Folks,

There continues to be a lot of productive and helpful conversation going on. Thank you to everyone who has chimed in so far. I share Carwil’s sadness in feeling like there are bigger issues here that I hope we can solve them (last paragraph of this diff), but for this particular incident, I just wanted to summarize again what I’ve been hearing. This has been incredibly helpful to me and I am sorry that for some of you it feels like you’re yelling into cotton-filled ears. Your patience is appreciated.

Below are the main points I hear being raised as a response to my statement detailing what I thought the highest priority issues and potential solutions were.

Some caveats:

  • Some folks called out that they thought Wikidata descriptions were okay, or disagreed with concerns below, but I didn’t include those points and instead focused only on the concerns.
  • I also excluded the back and forths about relative quality of Wikidata. It seems that all of us can acknowledge it is a concern for some and that there is disagreement about how this does or does not impact Misplaced Pages or whether the proposed measures would sufficiently address concerns.
  • Below are the concerns I heard, I am not endorsing those concerns, but stating their essence as heard.

Heard Concerns:

Perception that the Wikimedia Foundation overstepping its authority by interfering with content

  • Placing perceived content at the top of each page, without editor consent is problematic since editors cannot easily moderate it.
  • Perception that this is a violation of the Foundation’s terms of service and it’s role in the movement.
  • This is about process and principle. The Wikimedia Foundation did not gain consensus and it likely would not have for the same reason.

Problem with making it easier to edit and track

  • Wikidata editors can still revert a correction and it is unclear what an EnWik editor can do without getting involved in another project’s administrivia
  • Some (or all?) enwiki editors have no interest in working on Wikidata’s policy
  • Some (or all?) enwiki editors have no interest in editing Wikidata or making it better
  • The Wikimedia Foundation missed that protected pages should have protected descriptions
  • Based on above, the Wikimedia foundation is unlikely to be successful if they just do the suggested upgrades and hold an RFC for it

The Commons analogy

  • The belief that Wikidata is not like Commons, for the following important reasons:
    • Smaller community
    • Less restrictive policies
    • Wasn’t made for Misplaced Pages ingestion
  • There is a difference between choosing to put an image link in your article and having the Wikidata description placed at the top without your agreement
  • Others seem to suggest that the issues are not fundamental or unfixable.

Concern about quality on Wikidata

  • Perception that the impact of Wikidata vandalism unacceptably lowers Misplaced Pages's quality

A potential solution proposed

  • Auto-create local Wikidata descriptions from the first sentences of articles


Special thanks to those of you who were clearly trying to bridge across the different perspectives, while being emotionally generous, kind and polite. This really is hard for the folks who worked on this at the foundation and for the English Misplaced Pages contributors who feel strongly, so your approach goes a long way.

We’re going to have to figure out the next steps together and we will be reaching out soon to move this along. In the meantime, I just wanted to let you know that we are listening and taking this very seriously at the Wikimedia Foundation.

Thanks, Jkatz (WMF) (talk) 22:13, 18 September 2017 (UTC)

I would only like to add: Auto-create local Wikidata descriptions from the first sentences of articles - alternative: obtain descriptions from a specialized template like {{Description}} in the article header or body. Thanks, —PaleoNeonate – 22:21, 18 September 2017 (UTC)
That is a decent summary. Thanks for hearing. Jytdog (talk) 22:34, 18 September 2017 (UTC)
I think it's worth noting that the views being expressed on this page are somewhat biased towards an anti-Wikidata viewpoint. The discussions on this page aren't really conducive to having a neutral conversation as pro-Wikidata voices (to balance the POV) aren't particularly welcome, and I'm not sure that people in the middle are represented here. I think it's good to pay attention to the concerns, and resolve them as much as possible, but please don't think that everyone on enwp thinks this way. Thanks. Mike Peel (talk) 23:57, 18 September 2017 (UTC)
I have to concur that this is a hangout of the anti wikidata crowd which does not reflect the complete enWiki editorship. Most of the editors that would like to use data from Wikidata will only find out about this when their access to Wikidata gets blocked through deletions or decisions made by a small group. Agathoclea (talk) 07:59, 19 September 2017 (UTC)
Well, the last RfC we had on the use of descriptions was not here but on the village pump. It seems to me that each time some use of Wikidata (the descriptions, Cite Q, ...) gets more exposure, outside the small circle of ardent Wikidata includers here, there is suddenly much more opposition. While this page probably doesn't reflect the enwiki community, just like template pages don't, it seems unwise to dismiss the criticism and discussion here as simply "the anti wikidata crowd" when actual, larger discussions show that the support for Wikidata on enwiki is seriously lacking outside this page and circle as well. Fram (talk) 08:15, 19 September 2017 (UTC)
Mike Peel I find it ironic you claim an anti-Wikidata bias here. You have over 16k wikidata edits, and I think you'd be hard pressed to find generic discussions on Misplaced Pages with a comparably high level of involvement by people with hundreds, thousands, or tens of thousands of wikidata edits. This page has attracted very motivated parties on both sides of the topic, as commonly happens with localized discussions. That's why RFC's actively call in uninvolved participation, and why we run RFC's like this at Village Pump. The previous RFC was clearly heading for removal of current wikidata descriptions, and I think it was leaning against the kind of upgrades proposed here. If the most involved parties this page fail to sort out an agreeable resolution, a new Village Pump RFC can sort out the true "unbiased" position. Alsee (talk) 01:38, 22 September 2017 (UTC)
@Jkatz (WMF): please note that this is a general page about Wikidata on enwiki: I deliberately started separate sections about e.g. vandalism or sourcing on Wikidata because they are not the same issue as the use of Wikidata descriptions in views, searches, ... Problems with other aspects of Wikidata on enwiki (see e.g. Misplaced Pages:Templates for discussion/Log/2017 September 15#Template:Cite Q, which gives some good insights in how people here feel about Wikidata on enwiki in general) should not be conflated with the singular issue of the descriptions imposed by the WMF on enwiki, and I would urge the WMF to first solve this one issue before moving on to the more general concerns and discussions. Fram (talk) 07:00, 19 September 2017 (UTC)
@Jkatz (WMF): I think you missed one "concern about quality in Wikidata". It's that Wikidata contains millions of statements that are not reliably sourced, according to en:Misplaced Pages standards. These statements are either unsourced, sourced from Wikipedias (which are not considered reliable sources in Misplaced Pages), or cite sources deprecated here.
It has to be acknowledged that Wikidata contains statement types that don't need sourcing or can't be meaningfully sourced (say, a Commons category). That skews statistics like this one, against Wikidata.
And it also has to be acknowledged that Misplaced Pages (incl. en:WP) contains millions of statements that are unsourced, many of them in legacy articles written years ago when referencing standards were less rigorous. I reckon well over half of all statements present in Misplaced Pages articles (article bodies rather than leads) today lack a footnote citing a reference.
But Wikipedians by and large do make an effort to ensure that any new content added to pages – especially the more visible pages – is sourced. They spend hours arguing over whether a particular source is reliable or not. They've thought about it over the years, educated themselves about who publishes what and with what level of professional oversight, consult and refer to precedents in places like WP:RSN, and they are proud of what they've learned since they started contributing, and the culture they've built.
And now you're coming with a project where millions of database statements that would be relevant to Misplaced Pages are either completely unsourced or sourced as "imported from Italian Misplaced Pages", "imported from Lithuanian Misplaced Pages", "imported from Cebuano Misplaced Pages", etc., without so much as a link to the article version that originally contained the info, let alone the source (if any) cited in that Misplaced Pages article at the time the import was made. And Wikipedians are supposed to be happy about content from that database being added to Misplaced Pages in various ways they can't control, when it hasn't been built to their sourcing standards. Can you understand that that goes against the grain and feels like a step backwards, diametrically opposed to the learning curve each of them has undergone to assimilate the culture that has been built here? I think there would be far less resistance to Wikidata if the sourcing standards matched. --Andreas JN466 14:33, 19 September 2017 (UTC)
I am one of those supporting the principle of using Wikidata in Misplaced Pages, but I must agree with Andreas here: the referencing of claims to Misplaced Pages articles in Wikidata is awful. There is no reliable source, and there is not even a date given when that Misplaced Pages might have contained the information. —Kusma (t·c) 15:05, 19 September 2017 (UTC)
Actually, these data should not be there at all. Indeed it was easy to take statements from Misplaced Pages(s), however, effort must have been made to also use the sources Misplaced Pages uses (and if these do not exist, not to import the statement). Most of them can still be easily fixed: if the item on Chad contains a statement that this is a country and the continent of this country is Africa, both being sourced to Misplaced Pages or unsourced, it is relatively easy to find a reliable source for both these statements and correct them by a bot.--Ymblanter (talk) 15:29, 19 September 2017 (UTC)

Strategies for improving the descriptions

Hi everyone,

Following up on Jon's summary of the concerns, I'd like to explore some of the options we have for making the Wikidata descriptions better and more reliable.

To start with, the screenshot here is an example of how the descriptions are useful for navigation. This is the "top read" feature on the iOS Misplaced Pages app, which shows the articles with the highest pageviews for each day. I look at this every day; it's one of the ways that I keep up with what's happening on Misplaced Pages, and in the world.

In this case, I think 3 of the 5 top articles benefit from having a short description -- I have no idea who Gennady Golovkin and Canelo Álvarez are, and having them described as "Kazakhstani boxer" and "Mexican boxer" tells me whether I'm going to be interested in clicking on those. (The answer on that is no, I'm not really a boxing guy.) I know that Mother! is a 2017 film, but I'm sure there are lots of people who would find that article title completely baffling without the description. Clicking through to the full list of top read articles, there are a lot of names that people wouldn't know -- Amber Tamblyn, Arjan Singh, Goran Dragić. This is a really popular feature on the apps, and it would be kind of useless without the descriptions.

That being said -- I've also occasionally been annoyed and mildly embarrassed by a description. I read the Misplaced Pages article on Evil clown on the app a while back, and the description said "Evil clowns are evil clowns that are scary" -- an obviously juvenile description. When I got to my laptop, I went to Wikidata under my volunteer account, and changed the description to "Pop culture trope". But I only knew how to do that because I work at Wikimedia. If I was still a Misplaced Pages volunteer contributor who didn't go to wiki conferences, I don't know if I would have heard of Wikidata, and I wouldn't know how to fix this.

So I think it's important to find a way to keep the usefulness of the short descriptions, and improve the quality and reliability. There have been several different options proposed here, and I want to summarize them, look at some pros and cons, and then talk with everyone here about changes that the product team/communities can work on to make this better. I'm sure that I'll miss some stuff, so it would be great if folks could help me fill in the gaps.

1). Having more eyes on the descriptions, encouraging people to fix mistakes

This is one of the goals for allowing people to edit descriptions from the Android app. If there are more good-faith people looking at descriptions and it's easier to edit them, then vandalism gets reverted faster, and inadequate descriptions are replaced by better ones.

The potential con: it's also easier for bad-faith people to edit the descriptions, and we're not sure how quickly those would get picked up and reverted/corrected. This is also true for well-meaning people making "bad edits", as Jytdog points out in the Vandalism on Wikidata discussion above; these might not be picked up as vandalism, but need to be corrected all the same.

I'm not totally familiar with how the moderation works on Wikidata; hopefully folks can help me out here. Are there enough people watching items to patrol descriptions effectively? When the apps team rolled out description editing on the Russian, Hebrew and Catalan apps, the data they collected shows that 4.6% of the description edits were reverted. This will need to scale to English.

I see a recent discussion on the Wikidata:Project chat -- "Pending changes?" -- where people are acknowledging that vandalism is an issue, and suggesting either a pending changes system or using ORES or bots to surface likely vandalism on items that have Misplaced Pages pages. That's potentially an area that we could support.

2). Including Wikidata description edits in Misplaced Pages recent changes, watchlists, history

Surfacing Wikidata description edits to Misplaced Pages editors would provide more experienced eyes who could look at the edits, and make sure the descriptions are appropriate and accurate.

The Wikidata team is currently working on separating out the relevant changes to surface -- in this case, just English descriptions. They're just about to deploy a test version on Greek Misplaced Pages to see how their current solution scales.

There are some questions about this approach: Is this going to create extra work that some people don't want to deal with? Is it a barrier if you have to go to Wikidata to revert? What if you get in a revert war with someone, do you have to go to Wikidata to report and resolve the situation?

There would be further feature work depending on the answers to those questions. It would be helpful if people patrolling description changes on Misplaced Pages could do as much from Misplaced Pages as possible, rather than switching over to Wikidata.

3). Magic words in Misplaced Pages articles to override Wikidata descriptions

This could be a magic word like {{DESCRIPTION: .

This would be a more direct way for Misplaced Pages editors to ensure that moderation or discussion about a specific page's description happens on Misplaced Pages, and not on Wikidata. It would only replace the Wikidata description when there's something typed in the field, not just blanking the description completely.

A con for this idea is that it might be confusing for people who see a bad description and want to change it -- do they go to the Misplaced Pages page, or the Wikidata page? Also, this would have to be accounted for in the app description-editing feature.

4). Use the first sentence of the Misplaced Pages article, when appropriate

This was proposed and discussed above, including a comparison table with sample descriptions. It would have to filter out some pieces -- "(title) is a", birth and death dates, translation and pronunciation, etc.

Pros for this approach: it's derived from Misplaced Pages text, so it's under enwiki control. Also, it guarantees that there is a description; there are gaps in the Wikidata descriptions, but every article has a lead paragraph.

A con for this is that sometimes the first sentence is too long or dense to be helpful as a short description. Maybe we can come up with an idea for how to handle long first sentences. The Wikidata descriptions could be a fallback, or the magic word.

5). Protecting the description on protected pages

This would protect the short descriptions on pages that are likely vandalism targets, presumably synching protection on Wikidata with protection on English Misplaced Pages, so that admins protecting a WP page wouldn't have to remember to do something on Wikidata.

I'm not sure exactly how this would work, and can't find a description of it right now. Have people figured out a mechanism for this? How would you go about protecting the description on Wikidata?

So there's a lot of questions, and I'm sure I missed some pieces, but I'm hoping that this helps focus some discussion on potential solutions. What do you think? -- DannyH (WMF) (talk) 22:03, 19 September 2017 (UTC)

My preference would be a combination of 3 and 4: Use a local magic word when available, fall back to (a filtered version of) the first sentence otherwise. That way everything is under local control, the interaction with Wikidata is significantly less complex, and (unlike Wikidata) we're guaranteed to get something. The descriptions will occasionally be too long, but that's not really a worse problem than being occasionally missing, and if editors insist on long sentences in article text we can still achieve tighter descriptions using the magic word. If Wikidata wants to run bots that import this information from Misplaced Pages to use as their descriptions, they could also do that, but it would be their local decision and wouldn't affect what we see here. —David Eppstein (talk) 22:09, 19 September 2017 (UTC)
This is not place or time to solve this problem in my view. This is (again) all begging the questions. To put a pointy analogy on it:
Putin: "So let's discuss the plans for the highway system in Crimea. There are lots of problems, lets fix them!"
Rest of world: "Dude, what the hell are you doing in Crimea"
The questions are 1) about WMF's role in making content decisions, and 2) even deeper questions about navigating differences in the various projects' content policies and governance processes.
I am not convinced that folks from the WMF even understand these two fundamental issues, and "solutions" that aren't grounded on a good understanding are also going to be unstable.
Reversing direction, and stepping back, is the correct way to go here. Not deeper in.
Please reverse course. Jytdog (talk) 23:49, 19 September 2017 (UTC)
Having descriptions (on mobile, on Visual Editor, etc.) is an unambiguous good for Misplaced Pages. As a Wikipedian, I have zero interest in this boundary conflict, and think the analogy to sovereign independent states is pointless. We are neither sovereign nor independent, we are collaborating and interdependent. Moreover, this is a list of options, (almost all of which) give Wikipedians control over "their territory": how things look on Misplaced Pages. Let's skip the diplomatic crisis and figure out how to make this work best.
I tend to think that Options 4 & 5 are strong starting points. I also would love to have a tool that shows the descriptions for my watchlist, and either lets me edit those descriptions or has clickable links to the corresponding Wikidata pages. (Editing description on Wikidata is actually very easy, unlike a lot of things over there.)
The real questions are: can we develop a manual of style for descriptions? Is that MoS compatible with Wikidata expectations? And, how does the Wikidata community feel about mass importing new descriptions from Misplaced Pages?--Carwil (talk) 01:37, 20 September 2017 (UTC)
It was a pointy example as I pointedly said, and trying to drive that down my throat is bullshit. I offered the colorful example because folks from the WMF don't seem to be getting it, that they overstepped and did a fucked up thing after they overstepped, and that continually setting the focus of the conversation on fixing their fuckup is not legitimate (it is as weird as talking with putin about fixing highways in Crimea... the whole conversation is surreal and begs the question - namely - why are we having this conversation at all?)
Collaboration depends on recognizing appropriate roles for all the collaborators. As Rilke said, "love is respecting the difference between". The WMF overstepped its role and its competence by doing this unilaterally (by 'competence' i mean that it, as an organization, didn't understand the policy and governance issues around this content).
The wrong thing to do now is flail around trying to fix this multi-layered fuckup. The right thing to do now is undo, step back, and think clearly before trying to implement again. Jytdog (talk) 01:52, 20 September 2017 (UTC)
Let me amend this Crimea analogy… The infrastructure contractors for Kyiv have built installed a subway system (mobile app, mobile view, etc.) that lets millions of people get around our city. In the process, they have installed navigation signage that draws on Russian-language text. What the WMF people are saying is: hey, how would you like us to get text for the signs. In response, what Jytdog is arguing is that the contractors should apologize for putting up signs at all. If your beef with WMF is so important to you, Jytdog, fine. Just stop pretending you speak for all of us.--Carwil (talk) 04:13, 24 September 2017 (UTC)
The community already rejected these roadsigns, installed by the WMF, for the mobile app. I am not speaking for myself. Jytdog (talk) 04:33, 24 September 2017 (UTC)
DannyH, the only acceptable options are those that are enwiki based (for enwiki articles). Descriptions are textual, language-based content which should reflect the article, and should be embedded and maintained by the project and editors, not by another project with completely different goals. The best solution seems to be some template placed at the top of the article. If this is easier for the WMF, we should strive to gove it a "universal" name, so that it can be used on all wiki-languages that want it. Initially, it can be filled by bot either by copying the Wikidata description or by a shortened, cleaned version of the first line of the article, whichever people think is best (I prefer the second, but this bit is not essential to the proposal). From then on, this gets maintained locally, independently of the Wikidata descriptions.
You say "A con for this idea is that it might be confusing for people who see a bad description and want to change it -- do they go to the Misplaced Pages page, or the Wikidata page?" which is obviously false. This would be simply a part of the article, very few people would really be confused and think "oh, I need to go for Wikidata for this". Why would they ever think this in the above solution? Fram (talk) 07:15, 20 September 2017 (UTC)
  • It's quite a task we're looking at. Five and a half million short descriptions is a hell of a lot of text to create and maintain. Over on Wikidata, I've been working on items for civil parishes in England. I hadn't got as far as the descriptions yet -- first I have been working on tidying up data and building up external matches. The prospect of addressing the descriptions has been quite daunting, even with only 15,000 items of more or less the same kind to consider -- a drop in the ocean compared to short descriptions for all the articles on en-wiki. (And I have to say, I am very dubious that one could simply automatically get the information from article first lines.
I get that there's a lot of unhappiness about Wikidata here, but one (admittedly small) thing in the other side of the scale is that at least it makes it possible to a quick idea of what sorts of descriptions there are, and also to (relatively easily) make systematic edits to large numbers of them at scale.
Anyway, to get an idea of what sorts of things we might like (and not like) for descriptions, it's maybe worth looking at some samples of what Wikidata is currently providing. In each case, the link below goes to a query for 200 examples -- follow the link and click the blue button half way down the left hand side to run the query.
  • People: tinyurl.com/yd6dvub7
  • Castles: tinyurl.com/ybxdr7g5
  • Populated places: tinyurl.com/yc3yq6gf
  • Rivers: tinyurl.com/ybdh6blw
  • Albums: tinyurl.com/yatcou33
  • Films: tinyurl.com/ybkk9928
  • Unidentified things: tinyurl.com/y7k3w6ud
  • Civil parishes in West Sussex: tinyurl.com/ydd2utow
(Note: to see more examples, increase the number in the LIMIT clause; to see different examples, change the number in the OFFSET clause; I didn't force a sort order, in order to increase variety, so the same query may produce a different set of 200 examples if you run it in 30 minutes time -- for a deterministic query, to get a repeatable set, add eg ORDER BY ?item before the OFFSET keyword. The 'link' button on the left hand side can be used to get a short URL to the modified query).
It is apparent that there is no great consistency or house style. (Though even what is there already may be useful for some purposes -- eg disambiguating searches). This is one question it would be really useful to have input on, eg from the reading team: what is actually wanted? I imagine there is quite a lot of flexibility in what is useful, but what is the ideal? How detailed/verbose is useful? How brief/succinct is better?
So for example for a civil parish like Donnington (Q666080), we currently have "village and civil parish in the Chichester district of West Sussex in United Kingdom". Is this appropriate? Would the shorter "village and civil parish in Chichester, West Sussex, England" be better to standardise on? Or drop Chichester district, and just "village and civil parish in West Sussex, England" ? Or just "civil parish in Sussex"? All of the above could be systematically rolled out, but what is most useful?
Looking at some of the other result sets, it appears that a lot of film descriptions have been standardised to "<year> film by <director>", sometimes with genre also given, or occasionally country of origin; a few have more discursive descriptions (eg Oliver Twist (Q645752), Thunderpants (Q708825).
Descriptions for albums seem less systematised. Most common seems to be "album by <artist>", sometimes specifying whether it is a studio, live, or compilation album. Some are longer, eg "debut studio album by the American rock band Flowerhead" (...Ka-Bloom! (Q14954705)) or "fourth studio album by CCM singer Mandisa" (Overcomer (Q15078867)). Many just say "live album" or "album".
For people a common form seems to be "<nationality> <occupation>". (I think these may have come from the old PERSONDATA templates -- more recently created items may not be so systematic). Again, some items are more discursive, eg Banksy (Q133600). Is this useful?
Raising quality and usefulness for short descriptions, wherever it happens, is going to be no small task. But a useful thing, however we go forward, would be some more discussion on what is considered a useful description, and what is one that could be improved. Jheald (talk) 12:36, 20 September 2017 (UTC)
I agree with Jytdog that this feature was implemented a couple years ago without due care and attention to the differences between the two sites. I don't think that's catastrophic; it's a mistake that we have to fix. But what we have right now is a feature that's useful, and people like it. I don't think that breaking the existing feature is a necessary step before we figure out how to make it better. That's basically punishing the people who use the app, in order to make a point that they don't know or care about.
Fram, I agree that creating a completely enwiki-based alternative is one of the options. I mentioned the problem of not knowing where to fix the description, because I was thinking of it as a combined system that used Wikidata as a fallback. As Jheald says, a con for the completely enwiki template/magic-word version is that there would be five and a half million descriptions to generate, and that's a serious thing to think about.
Jheald, it hadn't occurred to me that this was an opportunity to standardize the descriptions. That's actually an important thing to figure out, no matter where the descriptions live. I need to read your post again, slower, and think about it. I'm really glad you brought it up. -- DannyH (WMF) (talk) 14:21, 20 September 2017 (UTC)
Considering that Wikidata was apparently able to reliably source 50 million statements in a month (a feat no one has been willing or able to explain so far, but which is shown in the statistics and pushed Wikidata over the "50% of our statements are reliably sourced" threshold suddenly), it shouldn't be too hard to add 5 miilion descriptions to enwiki in a reasonable timeframe, if this is the way we choose (some clever programming which parses and "summarizes" the first sentence may also be an option and then wouldn't need article edits). We need a) a decision of the best solution (a global template, an enwiki template, or clever reading of the first line at runtime?), b) a decision (in the case of a template) of how we would populate it initially (copy the wikidata description, clever reading of the first line, something infobox or category related, ...?) and c) a botrun. In the meantime, we can decide whether we ask the WMF to turn off the Wikidata descriptions display off immediately, or wait until the bot run (or other solution) is finished.
If we start by copying the Wikidata descriptions, we don't even need to edit 5 million articles, as many Wikidata items don't have descriptions at the moment. (First random item I encountered, doesn't have one and doesn't need one). Fram (talk) 14:41, 20 September 2017 (UTC)
Fram, I want to make sure that some other people get a chance to talk before we jump straight into a solution. I'm not trying to backtrack, I just want to make sure people can talk about the options.
If it turns out that's the solution we go with, it would be good to include the product team in the implementation, not just run a bot and ask the WMF to turn something off. We're offering to be a part of this, and work on this collaboratively. One thought about switching to Misplaced Pages-populated descriptions: we could think about porting the changed versions back to Wikidata, to be the English descriptions there. I know that not everybody here is interested in improving Wikidata as well, but it would be good to find a solution that benefits everyone. -- DannyH (WMF) (talk) 18:21, 20 September 2017 (UTC)
I can only speak for myself (I may sometimes give another impression though ;-) ), but I see no reason to not take some time to find the best solution here, and have no problem with a solution which then takes some time to actually implement. I have indicated a few times what I believe are minimum requirements for such a solution, but it makes no sense to e.g. create a Template:ShortDescription here when perhaps the WMF would prefer a somewhat different Template:Summary or a magic word or whatever instead, which they can then read more easily (to use in apps, search, ...) and which may be something other wikis can implement without too much effort if they want to. We have the time to do this right, and we have the time to run a massive botrun if that is required. As for your final point, I see no reason why Wikidata couldn't import (or mirror) our descriptions if they then would like this: it's not something we can or want to impose, but it would be nice. Fram (talk) 19:09, 20 September 2017 (UTC)

My views on these options (from a perspective that using the Wikidata descriptions are a good idea in principle) are:

  1. Making things easier to edit is always a good step forward, however there should also be an easy way to revert the edit. Maybe some sort of "this was recently changed, does it look bad?" tag may be useful there.
  2. Sounds good, but it would be better to make all Wikidata edit summaries more useful rather than picking on particular bits.
  3. This is a terrible idea - it's basically duplicating a bit of Wikidata here (and, presumably, also on every other language Misplaced Pages). It would be much better to have some way of editing the Wikidata descriptions directly here instead.
  4. Sounds good. Maybe this could be done in such a way that it can feed into Wikidata - either by a bot, or some sort of gamification/user checking. I think this would be welcome on Wikidata, particularly for entries that don't yet have English descriptions.
  5. This is something that needs properly thinking about by people that are active with page protection. If a page is protected here, should the wikidata entry as a whole be protected, or all of the wikidata properties used in the page? Or some sort of semi-protection? Although we don't currently do this with Commons media included on a page.

Thanks. Mike Peel (talk) 23:08, 20 September 2017 (UTC)

@Mike Peel: I see your point about a magic word here being redundant duplication of what is already on Wikidata but I consider it that Wikidata is itself duplicating a role that should be en's (describing things in English text) rather than vice versa. I would only be willing to see Wikidata descriptions used here if we can make them subject to our local standards for sourcing, etc. Consider e.g. the long debates over whether someone should be described as a "climate change denier". We have well-established rules for sourcing biographies of living people here, despite which these questions are still difficult. Should we let tendentious editors forum-shop Wikidata's much looser rules over ours in such cases? I think not. —David Eppstein (talk) 23:20, 20 September 2017 (UTC)
@David Eppstein: I care more about avoiding the duplication of work/content than I do about which project should have which role. Technically, I think Wikidata has better infrastructure to hold the information (structured rather than free-form content), while the community and English-specific expertise is here. If we could forget the different project names, the ideal case might be the enwp community taking ownership of the English Wikidata descriptions and running them according to enwp rules. ;-) Thanks. Mike Peel (talk) 23:30, 20 September 2017 (UTC)
Since when are short bits of text "structured rather than free form content"? Fram (talk) 06:50, 21 September 2017 (UTC)

For me (4). Use the first sentence of the Misplaced Pages article, when appropriate is the only one that makes sense. The con is that "sometimes the first sentence is too long or dense to be helpful as a short description" but this is not a problem for Wikidata descriptions but for Misplaced Pages. Our guidance, at WP:BEGIN, is that "If possible, the page title should be the subject of the first sentence", and "Try to not overload the first sentence". The first sentence, as part of the first section, should also be accessible, even in a highly technical article. So too long, dense, or technical first sentences are not appropriate for WP.

The only issue is what to do when the first sentence does not describe the topic. E.g. List of songs recorded by Steps (from tomorrow’s front page) begins "The British group Steps have recorded songs for five studio albums". Wikidata though describes it as a "Wikimedia list article"; presumably other lists can be handled the same way. Other topics that are hard to describe might use a standard form, or just the title, as e.g. History of Iran does.--JohnBlackburnedeeds 23:34, 20 September 2017 (UTC)

"Wikimedia list article" is a rather dreadful description. That article doesn't even need a description, the title is self-explanatory, but if it has one it should be something "Songs recorded by Britsh band Steps", i.e. a description which adds something useful to the title, not a description which adds a totally irrelevant concept (Wikimedia) which can only confuse people instead of helping them. It looks as if all List articles have the very same description at Wikidata, which is again a good argument to take this functionality away from there and give it back to the local wikipedia versions (at least those that want this). Fram (talk) 06:50, 21 September 2017 (UTC)
(Of course, there may be a very good reason why these list descriptions are ideal for Wikidata, and I am not arguing that they should change them; but for enwiki, they are just not useful at all) Fram (talk) 06:55, 21 September 2017 (UTC)
The list description needs to be considered in the context of how it would be seen -- namely in a list on a mobile screen as in the picture shown at the top of this article, or as an explanatory line in a set of search results. In those contexts, I submit, it is quite adequate. Jheald (talk) 09:16, 21 September 2017 (UTC)
Umm, how? They explain nothing at all, they only introduce a concept which has no useful information and proably no meaning for the average reader, "Wikimedia". Thta it is a "list article" is rather obvious from the name anyway, so the end result is two superfluous words and one irrelevant one. In what world is that "quite adequate"? Fram (talk) 09:21, 21 September 2017 (UTC)

I'm gonna suggest an alternative: Let's just take the first sentence from TextExtracts. Just for English Misplaced Pages. Problem solved, little engineering required, English gets to be holier than holy, rest of the wiki's get the benefit from centralization and structured info, apps retain 'some form' of disambiguation labels for en.wp. No need for specialized edit interfaces, no need for magic words. Just toss ellipsis at the end, and maybe reduce the font size a bit and just live with that. I think first sentence is subpar from the descriptions that Wikidata provides, but we have to find some place of compromise and this seems like the least terrible option to me. I definitely DONT see a reason to spend engineering effort to duplicate Wikidata descriptions in Misplaced Pages.—TheDJ (talk • contribs) 07:30, 21 September 2017 (UTC)

What exactly is the benefit of centralizing descriptions, which are language-based? This means that you need editors fluent in all these languages to not only patrol and edit their own language wikipedia, but also Wikidata. Apart from that, you seem to continue to repeat the same misconceptions about "structured data" when it is just a short freetext sentence fragment, and the supposed superiority of current Wikidata descriptions when just above it is e.g. shown how all lists have an utterly useless description at Wikidata: we have about 100,000 of these, with many of them among our most popular articles, so this is not something marginal. To push for a subpar, English-only solution out of some kind of bitterness is not productive or helpful, when there may be opportunities here to make things better for enwiki and other wikis that might prefer the same solution in the end. Fram (talk) 07:56, 21 September 2017 (UTC)
A Misplaced Pages centric approach. From the global state of information and knowledge... what is it that that list is ? It is nothing physical in the real world that matches it from a data topic point of view. It's a Misplaced Pages article. Now if it were called "Discography of Steps", then that description might be different, because a discography is a real life concept, but 'list of' has no inherent meaning for most people.
When people say structured, it means structured storage and linking, not structured authoring. While for one property the value of that might be limited, when combined with all the other properties it is a very strong and Wikidata is proving that again and again. Wikidata is becoming the entry point for how others interact with the content in our movement, Misplaced Pages is the long form appendix that you can link to when someone is really interested. Making things better for Misplaced Pages is awesome, but I think that for 95% of all our language variants for Misplaced Pages, this change would have 0 benefit and might even be detrimental. Even for English Misplaced Pages the quality concerns are limited to a very specific set of articles. And that forgoes the point that I think that the ROI simply doesn't make sense for that option. Prediction; will take a year to complete such a feature and only 5-10 wiki's will use it. There is no space for it right now in the roadmap, and no budget allocation either... Shortcuts are the only option that I think are serious candidates. —TheDJ (talk • contribs) 09:24, 21 September 2017 (UTC)
Are you really arguing that in general, people will know what "Discography of X" means but will have trouble understanding what "List of songs by X" means (unlikely), and that somehow "Wikimedia list article" will then somehow lead to a better understanding for these people? I'll try to stay polite and just say that I disagree and think that most uninvolved people would disagree as well. As for your arguments about structured data, the descriptions are one bit which is actually quite separate from the remainder of Wikidata and doesn't really benefit or interact with the remainder. It just doesn't fit in with what Wikidata is and how it is structured at all, it is presented differently, edited differently, ... It has no room for sourcing, it is multilingual, it is everything the remainder of Wikidata is not. As for roadmap and budget problems, fuck them. Enough time and budget has been spent on things no one wanted or needed, and a lot of time has been spent by volunteers to convince the WMF that some things really are not welcome and should be shut down or totally rewritten. Here they have the chance to work together instead of against the community, and to develop a solution which may be beneficial to everyone involved. Fram (talk) 09:56, 21 September 2017 (UTC)
There is actually a problem here. Indeed in 99.99%, or most likely in 100%, "Discography of X" means "List of albums/songs performed by X". However, once in 00.01% cases (which may not apply specifically to Discography but may apply to other examples) it can make a name of a magazine, or a music band, or indeed a discography of another performer with a similar name. This is why it happens to be useful. Note that whether there are other meanings or not are language specific.--Ymblanter (talk) 10:11, 21 September 2017 (UTC)
For clarity: this shows that currently only one (Discography of Nico Carstens) out of 11 non-redirect article titles in the "Discography of X" format is an article containing a "List of albums/songs performed by X" (so less than 10%, with only one single instance, instead of "99.99%, or most likely in 100%"). --Francis Schonken (talk) 10:27, 21 September 2017 (UTC)
"This is why it happens to be useful. Note that whether there are other meanings or not are language specific." Your conclusions don't follow from your reasoning. Are you arguing that a generic "Wiimedia list article" is useful because not all "Discography of X" articles are a list of recordings of X? That's a total non sequitur. As for "language-specific", yes, but how is that relevant? Perhaps the Finnish equicvalent of "Wikimedia list article" is extemely helpful in Finnish, fine, then use that. But people who are so hell-bent on keeping the Wikidata descriptions that they can't even admit that 100,000 or so instances of "Wikimedia list article" are 100,000 examples of totally useless Wikidata descriptions (in English) for use on enwiki views, searches, ... simply make a mockery of this discussion and any attempts to find a rational compromise. Fram (talk) 11:55, 21 September 2017 (UTC)
First, I hope I demonstrated that your statement that descriptions are not needed because every sane person can say from the title what the article is about is wrong. Second, a "Wikimedia list article" description is not ideal, but it is better than no description, because is says, well, that the article is a Wikimedia list article.
I said that for most list articles (like list of Steps records) no description is really necessary, and you demonstrate something (not really sure what) about "discography of " articles, which are not the same (and don't even have a "Wikimedia list article" description by default. So no, you haven't demonstrated anything about my statements. Further, please explain in what way "Wikimedia list article" is better than no description? That it is a list article is obvious as it is an article titled list of; only the exceptions, where an article with such a title in fact isn't a list but e.g. the title of a book, film, or record really need a description. Like I also said already, even if they don't need a description, it may be helpful to have one which gives the reader more useful information, e.g. describing "List of Steps recordings" as "Recordings by British band Steps" or something similar, which adds that they are a British band, and not e.g. a type of dance. The current description though, adored now already by three of the more vocal defenders of getting descriptions from Wikidata, doesn't add anything useful. Please, all of you, understand that either readers don't know what Wikimedia is, and will think probably it a typo for Misplaced Pages (and whether it says "Wikimedia list article" or "Misplaced Pages list article", or they do know what Wikimedia is, i.e. the foundation behind the site they are surfing on. It tells you absolutely nothing, nada, zilch, about the list of X you are searching for or just started reading. It is just an annoying "thing" you get at the top of every list and which you have to scroll past. Having no description is in these cases clearly better than having this generic, bot generated description. Just like it makes no sense that our 200,000+ disambiguation pages like Blackboard (disambiguation) get the description "Misplaced Pages disambiguation page" (oh, here it is Misplaced Pages and not Wikimedia?); no kidding, Sherlock. (Did you know that we have a page titled Disambiguation (disambiguation)? The Wikidata description is "Wikimedia disambiguation page", which I wouldn't have known otherwise). Those descriptions make sense on Wikidata, where e.g. this doesn't have (or need) "Disambiguation" in the title: they don't make sense on enwiki. The fact that they serve two different purposes, two different needs which require two different descriptions is a very good reason why this feature should be hosted on enwiki for display in enwiki searches and articles. Fram (talk) 12:53, 21 September 2017 (UTC)
Honestly Fram, is this really the best you can do? So some of the descriptions are mildly redundant. Is that really such a big deal? Seems "mostly harmless" to me. I thought you had some concerns that were actually *serious* about WD descriptions. Yet I post some queries so we can look at typical samples, and you're not even bothered to comment on them. Get serious or stop wasting everybody's time. Jheald (talk) 13:27, 21 September 2017 (UTC)
No, this is not "the best I can do", it is but one argument among the many I have made. I try not to repeat everything in every post, as I already get the complaint of carrying on a monologue (which, considering how few of the replies I got had anything to do with what I actually said, is probably accurate). My main reasons are that a) the WMF should never push data from another site into enwiki content, b) this is language-based content which is not the domain of Wikidata but of the different language-based Wikipedias, c) Wikidata policies are too different (or lacking) compared to enwiki d) vandalism reversal at Wiki is on average way too slow (and note that while statistically vandalism is rare at Wikidata, in reality for descriptions it is pretty high), e) things like blocking, protection, ... on enwiki don't work on this, so people we want to get rid off can still subvert our articles through Wikidata (and Commons, but having one backdoor is hardly an argument to open a second one), f) hundreds of thousands of Wikidata descriptions are useless and confusing, and we would be better of without them, and g) probably a few other things I already said but which I don't immediately recall now... Which you would have known if you had actually read my posts, instead of taking pot shots at "is this really the best you can do" when I just gave yet another reason why this is a problem, not the only one or necessarily the best one. Anyway, looking at your queries, taking the one for albums, I see that the vast majority of albums have no description on Wikidata, and that for the remainder, about half is useful (giving extra, relevant information) and half is basically a repeat of the enwiki disambiguator we have in the title anyway (e.g. for "Spirit", it is nice to have the description "Depeche Mode album", but considering that our article is called Spirit (Depeche Mode album), it is hardly helpful to have this description). For your query for "unidentified things", only 11 of the 200 items (with an enwiki article) even have a description... Fram (talk) 13:50, 21 September 2017 (UTC)
For items with no description, it's worth noting the mobile app can fill in with an auto-description generated on the fly based on the wikidata statements available. Unfortunately I don't have a link to the code (perhaps somebody on this board can supply it?), but auto-descriptions by Magnus can be seen in action on eg Mix'n'match, which shows both auto-descriptions and manual ones for matched entries. Indeed, not two weeks goes by without User:GerardM suggesting that manual descriptions should be abandoned altogether, and descriptions just left to the automatic generator. I wouldn't go as far as that, as I think there are times when manual description can be necessary for clarification (eg two civil parishes with the same name in the same district of the same county -- yes, there are some examples of this). Also there can be advantages for queries in having baked-in text available. (Though in principle one could also make the auto-generated descriptions available within queries via a SERVICE routine).
But I am glad if discussion can take a harder look at some of the descriptions we have, and how they could be improved. External services and Wikidata-based systems will go on using this descriptions whatever WMF does or doesn't do, sometimes even as an index to Misplaced Pages content, simply because they are so accessible, so it's worth looking at them hard and thinking how we could do better. For the moment I think what we have at the moment is mostly better than nothing, and even in less useful cases mostly harmless; so I don't see it as a case of the sky falling.
I do share some concern about potential vandalism. It's one thing to say Wikidata's vandalism rate is low because it mostly skates under the radar as a low-reward proposition for vandalism. But much higher visibility and editability effectively paints a target on those statements. (Indeed, when this change was announced at Wikidata's Project Chat, my first instinct was to ask whether vandal fighters on en-wiki felt confident that they had the capability and the capacity to handle it. I think now after all the discussion above everyone would have to accept that the only current answer to that question has to be: No). But I think it's probably fixable.
As for BLP issues I think we need to accept that there is certain information in descriptions that we need to be very careful about, that perhaps should only be accepted on the basis of flagged revisions (perhaps triggered by particular words), if those descriptions are going to be presented alongside Misplaced Pages text. Giving Misplaced Pages admins the ability to activate flagged revisions for en-descriptions of a particular item (perhaps automatically if the item is protected on en-wiki) might also be a way forward to deal with concerns in that area.
Verifiability of descriptions (at least as interpreted as a requirement for explicit sourcing) I see as less of a concern, just as lead sections of articles on en-wiki don't require explicit footnotes, so long as they are supported by the rest of the article. Even with references, it's hard to control against people changing the information while leaving the reference. But for the most point, the contents of the description will be the most basic facts about an item, and are likely to be readily supported by the content of external links, and/or references in the attached wiki article.
In my view there is work to do on both the current description data and the underlying systems tying Wikidata and the wikipedias. But I believe this is achievable, to a good outcome. Jheald (talk) 14:52, 21 September 2017 (UTC)
I did not get the impression that you listen to what I am saying. I can reply, but, to be honest, I do not see any point in doing so, since you will likely come up with a new explanation completely unrelated to my reply, so I better do not. As I said earlier, I do not have any stakes in descriptions.--Ymblanter (talk) 13:07, 21 September 2017 (UTC)
I directly replied to the two statements in your post (conveniently labeled "first" and "second"). You are free to leave the conversation, but it would do you credit if you didn't fabricate reasons for doing so. Then again, you didn't refrain from fabricating things I supposedly had claimed ("your statement that descriptions are not needed because every sane person can say from the title what the article is about"), so this shouldn't come as a surprise. Fram (talk) 13:20, 21 September 2017 (UTC)
I can not really leave the conversation because there never have been one - you consistently fail to address the points I made instead cherry-picking quotes and making a strawman. As I said, I do not see any sense in continuing this exercise. Your position is also clear, it did not shaft a bit on this page irrespectively on any arguments which were brought by different users here. At some point, an RfC will be organized, and then we are going to see how much the community shares your ideas.--Ymblanter (talk) 13:28, 21 September 2017 (UTC)
We are here because an RfC was organized but only implemented partially by the WMF, remember? Fram (talk) 13:50, 21 September 2017 (UTC)
(ec) In most cases I have to say that I think just using mw:Extension:TextExtracts would not be very helpful. If we consider the image of the mobile screen at the top of this section, the short descriptions need to come to the point very quickly, without prefatory matter like pronunciation, etymology, field of the subject, or repetition of the subject name.
Unlike some others in this discussion, I am also pretty dubious about the extent to which good short descriptions could be extracted automatically. I think often they would still be too wordy and not suitable.
The point about whether it makes sense for WMF to put much in the way of limited engineering resources into duplicating delivery mechanisms when Wikidata already exists is a fair one.
@Fram: You are correct that the text slugs on their own are not structured data. However, it makes sense to put them into a retrieval system that is structured, so that as per the queries above they are instantly retrievable for any subset. As the queries above show, it's a lot easier to extract from Wikidata descriptions for eg all the civil parishes in England that it would be from eg Misplaced Pages -- it makes sense to store the descriptions in a structure that makes them directly accessible. Primarily these are going to be delivered as 'explanation lines' accompanying search results. One doesn't want to have to scrape the pages every time one wants to present the summary explanation line. Jheald (talk) 09:36, 21 September 2017 (UTC)
"Primarily these are going to be delivered as 'explanation lines' accompanying search results. One doesn't want to have to scrape the pages every time one wants to present the summary explanation line." Such scraping is done every time one does a standard search, e.g. this, where every result shows the start of the article anyway. Fram (talk) 09:56, 21 September 2017 (UTC)
DJ you want to say that Misplaced Pages is some kind of spoiled princess. Whatever. Here is a what a Wikidata editor wrote at Jimbo's If a change occurs to the Wikidata item linked to a Misplaced Pages page I watch, then that change shows up with a diff link to Wikidata. If you have issues with Wikidata's content, then you need to work with our (Wikidata's) community to work out a solution. Keep in mind though that Wikidata is a highly multilingual, mixed community where insisting that every Misplaced Pages policy be applied there is highly frowned upon.
No surprise to me, that a Wikidata person expects the norms of that editing community to be respected. The projects are different. There is this continued fantasy that norms are the same. They aren't. Jytdog (talk) 08:18, 21 September 2017 (UTC)
And maybe it deserves to be a spoiled princess. Maybe. But at the same time, we should also recognise that it is the exception. So instead of making everything follow Misplaced Pages's norms, the better option might be to have Misplaced Pages be the odd kid out. Princesses might grow up a bit in isolation at some point due to their status. —TheDJ (talk • contribs) 09:24, 21 September 2017 (UTC)
You continue with the sloppy garbage that it is OK for the WMF to play content DJ, breaking the fundamental deal here as well as policies in one or more projects, and setting projects against one another, in order to serve some aim that it sees as For The Greater Good. I am not going to get sucked into trying to convince people in Wikidata to follow en-wp BLP. That would be stupid and imperialistic. Nor am I am going to accept a mechanized process to introduce content into en-WP that is created without V or BLP. That too is idiocy. Jytdog (talk) 09:40, 21 September 2017 (UTC)
Could you please expand which people are going to be blocked and banned here? And by whom?--Ymblanter (talk) 09:49, 21 September 2017 (UTC)
Last week I had launched an RfC at VPP calling for blocks for the people who kept this going after we had the RfC in March, as this violated clearly expressed community consensus. I withdrew it when dialogue was opened last week. If the "dialogue" continues to beg the question on a "Lets fix the highways in Crimea" basis (see above in this thread) then I will re-open it. That one didn't specify individuals. Jytdog (talk) 10:13, 21 September 2017 (UTC)
Ok, thanks. You should have been more clear: not "people are going to be blocked or banned" but "I would like to see these people blocked or banned". The RfC as formulated does not have a single chance to succeed.--Ymblanter (talk) 10:21, 21 September 2017 (UTC)
Ok thanks. You should have been more clear that you are making the newbie and slimey mistake of Trying To Make a Big Deal And Even Quoting things that people obviously retracted before they were responded to. (I know how to step back when I make a mistake - I do understand that this is something rare around here). And thanks for consulting your crystal ball for me. Jytdog (talk) 10:42, 21 September 2017 (UTC)
I am not sure I understand whether this is meant as a personal attack or not, since English is not my mothertongue, but you are welcome to continue the rant, I am not going to respond to it.--Ymblanter (talk) 12:31, 21 September 2017 (UTC)
(e/c) And how would using the first line of the Misplaced Pages extract be playing content DJ for English Misplaced Pages ? That's my suggestion. I think it's totally unnecessary other than to keep the peace, but its what i'm suggesting none the less. —TheDJ (talk • contribs) 10:03, 21 September 2017 (UTC)
the WMF wants a single line of description it can use everywhere. I understand how that is very attractive. (i really do). It is however a huge deal for them to have made the decision to do so. Your solution is based on kissing en-WP ass and doesn't deal with the fundamental issues and in many ways is even more outside the norms of the movement than what the WMF did. Jytdog (talk) 10:13, 21 September 2017 (UTC)
I think in part, the WMF's role is to do things that communities and individual volunteers can't, like making apps, which have special app-specific features that need full-time product and engineering roles. I don't think that's an overreach. But I agree that that work needs to be done with the knowledge and the involvement of the communities, and that wasn't done well enough here. I'm hoping that having these conversations and working with folks here to come up with solutions is a step towards correcting that mistake. -- DannyH (WMF) (talk) 16:24, 21 September 2017 (UTC)
Making an app and making content decisions in an app are two different things, and you continue to obfuscate that. I am looking for the WMF to take these descriptions down and renounce the overstepping. I am not accepting what you are presenting as a fait accompli. Jytdog (talk) 17:55, 21 September 2017 (UTC)

I'm thinking about the discussion/argument above about descriptions of lists, albums, etc. On one hand, whatever the solution we end up with for short descriptions, there'll be plenty of time to figure out the standard format for rivers, museums, etc. But the conversation here is revealing, because it highlights a couple important questions that people have raised:

1.) Who's going to make the decisions about the standard format -- the Enwiki community, the Wikidata community, or both working together?
2.) Are Wikidata descriptions just for putting a heading on Enwiki articles, or are there other purposes they serve that would require a description to be different than what the Enwiki community would want?

Lists and disambiguation pages are an interesting example, because the Wikidata description isn't describing the subject of an article; it's describing the page. The description for the Gennady Golovkin article is "Kazakhstani boxer", which is useful both for a description on enwiki and any other use that someone might have for Wikidata information. But "Wikimedia list page" is not a very useful description for the enwiki app/search, and I can't think of any other use case where it would be helpful. It's kind of a description for description's sake, and seems like an example of something that enwiki could override with no real consequences.

If we can figure out a way for folks from Misplaced Pages and Wikidata to work together on making the descriptions appropriate for enwiki use, then that could benefit everyone. If not, then it seems to me like a template/magic word override on enwiki would make sense. There are a lot of useful descriptions on Wikidata, and I don't think it's practical for English Misplaced Pages to come up with five million descriptions from scratch. But using the helpful ones and overriding the unhelpful ones is a potential way forward. -- DannyH (WMF) (talk) 17:25, 21 September 2017 (UTC)

Wikidata descriptions, at the very least, serve to provide a proper choice on Wikidata itself - for example, when I am trying to fill in a property of an item, and I do not known the Q-number of the item I want to refer to, I just type an approximate name and get a bunch of options to choose from. Without descriptions, these options are not usable. With long descriptions, they will not be usable either. Every description, unless false, is better than nothing.--Ymblanter (talk) 17:34, 21 September 2017 (UTC)
Nobody has disputed the Wikidata editing community's use of the description field in Wikidata. That is their deal and none of en-WP editing community's business Jytdog (talk) 17:59, 21 September 2017 (UTC)
I was reacting to point 2 by DannyH (WMF) above.--Ymblanter (talk) 18:05, 21 September 2017 (UTC)
DannyH, you missed question zero as you have throughout this discussion. 0) Is it appropriate for the WMF to make content decisions? If (a big if) the answer is "yes", how should it interact with the content-producing communities? Jytdog (talk) 18:10, 21 September 2017 (UTC)
I think the way that the WMF should interact with the content-producting communities is the way that I'm doing it right now -- talking to people, and working collaboratively towards a solution that works for the Enwiki contributors, the Wikidata contributors and the app users. I agree with you that that hasn't always happened in the past. -- DannyH (WMF) (talk) 18:28, 21 September 2017 (UTC)
DannyH, by limiting the discussion to the English, you allow them to high jack the conversation. Thanks, GerardM (talk) 06:14, 22 September 2017 (UTC)
So that addressed question 0b, and leaves 0a unaddressed. Which is the primary issue here... which to restate the analogy, is "Putin in Crimea". I do not accept this fait accompli. Jytdog (talk) 22:02, 21 September 2017 (UTC)
DannyH (WMF), thanks. You missed #4 supplemented with a variation of #3: A Magic word to override the first sentence of the Misplaced Pages article.
To restate in this section: My !vote, and I believe the community preference, is #4. Adding a magic word override would be a nice plus. Alsee (talk) 03:47, 22 September 2017 (UTC)
@DannyH (WMF): you ask us two questions:
1.) Who's going to make the decisions about the standard format -- the Enwiki community, the Wikidata community, or both working together?
2.) Are Wikidata descriptions just for putting a heading on Enwiki articles, or are there other purposes they serve that would require a description to be different than what the Enwiki community would want?
Neither of these is in any way a relevant question if you go with the requested solution, and to pose these questions here and now gives the strong impression that you don't intend to do this or haven't actually read this page. There will be descriptions on enwiki, either directly (as text in a template probably) or at runtime (as text parsed from the first line and/or from the infobox). There will be descriptions on Wikidata. Wikidata is completely free to decide their standard format (including copying them from enwiki if they so desire), Enwiki is completely free to decide their standard format as well; the only thing we have to do at enwiki is discuss this with the WMF or whoever is behind the apps, search results, ... so that we get the best possible result, something which is workable in as many circumstances as possible. Your question 1 is thus a false trilemma: the correct answer, which you happen to omit, is "both working separately". Question 2 is probably even worse. If you want to know what Wikidata descriptions are for go to Wikidata and ask them. When you come here, ask enwiki what we want to use the descriptions for (or make suggestions of course). For us, "Wikimedia disambiguation page" is a useless description; I can imagine that for Wikidata, it is the perfect description. Fine, no problem, that's their choice, their right and I have no intention to make them change this in any way at all. That would be rude, unhelpful. Unless of course you continue to force enwiki to use these decriptions, whether we want to or not, which is the direction you seem to take again and again. If enwiki has to display these Wikidata descriptions, then they will have to be the text we want, and Wikidata be damned. This will only lead to a direct confrontation between the two communities and much ill will between the two (and even more towards the WMF probably). If that's what you want, just say so. If that's not what you want, then think harder about what you post here and whether it is in any way helpful. We've had enough fiasco's in the communication between enwiki and the WMF (which you, as the one responsible at the time Flow went down the drain here are certainly aware of), it would be best if we avoided this here and could continue with the more productive, open tone the WMF had adapted at the start from this discussion. Fram (talk) 07:20, 22 September 2017 (UTC)
Continued: you state "There are a lot of useful descriptions on Wikidata, and I don't think it's practical for English Misplaced Pages to come up with five million descriptions from scratch." For starters, as evidence above a few times, many, many enwiki articles don't have a description at Wikidata, hundreds of thousands have an unhelpful one, and many others have an unnecessary one (where the description on Wikidata is the same or similar to the parenthetical disambiguation on enwiki). These descriptions are useful on Wikidata, but not here. So even to get as good as the WIkidata descriptions are now, we wouldn't need to come up with 5 million descriptions, 1 million would probably be sufficient. And we don't need to come up with them from scratch, multiple possible solutions have been given, like initially copying the Wikidata descriptions (preferably in a smart way, e.g. dropping the ones for lists and disambiguation pages), using text from the first line, or using info from the infobox (if the infobox is an "infobox album", you can construct a description with "a "year of album" "type of album" by "artist or band" description fairly easily). Yes, it would take some bot coding and one massive bot run, but it isn't the first time something like this has been done. Fram (talk) 07:26, 22 September 2017 (UTC)
Fram, you and I are more on the same page than you think we are right now. I'm sorry that I wasn't clear about my intentions in that post; I'll clarify. This is going to be okay. :)
The reason why I'm asking questions in this discussion is that I want everyone here to have a chance to think and talk through some possible alternatives. When you say "Neither of these is in any way a relevant question if you go with the requested solution" -- I want to point out that that's the solution that you requested, which is a good one. Other people in this current thread are talking about other approaches or variations on that approach, and I want to leave some space for people to think them through, so that we can get to something closer to consensus. I'm not planning to spend the rest of our lives dragging this conversation out, but people are still actively discussing some different ideas.
When I asked those two questions, I was trying to summarize the discussion above my post, where people were talking about "Wikimedia list page", "Disambiguation page" etc. The answer to question #1 could be "the Enwiki community should make those decisions", and #2 could be "yeah, Wikidata has its own purposes, and it's just not appropriate to use that description field on Misplaced Pages." That's where that discussion was trending, but I wanted to leave some room for somebody to come up with a compelling argument for an alternative.
For the part about English Misplaced Pages coming up with five million descriptions: the solution you're championing involves importing all of the existing Wikidata descriptions. That means that you think there's value in starting with the work that's already been done on Wikidata, and then using some of it, changing some of it and building on that work. I agree with you that that would be more practical than the alternative that Jytdog is supporting, which is to scrub all the Wikidata descriptions completely, and start over from scratch.
So: if changing and building on top of the existing Wikidata descriptions is the direction we're going, there are two different ways that we could do it. One is to do the bulk import, and fork completely from Wikidata, which is your requested solution. Another is to use the template/magicword as an override, as we did with the "related pages" feature a while ago. That means good and useful descriptions added on Wikidata in the future could still appear, while English Misplaced Pages contributors could change the descriptions for the pages/topic areas where the Wikidata descriptions aren't good enough. There's pros and cons for both directions. I think it's reasonable to have some discussion about those alternatives. -- DannyH (WMF) (talk) 19:14, 22 September 2017 (UTC)
As the queries above showed, there are a fair proportion of the descriptions of Wikidata that could benefit from some systematic improvement, either before or in the process of any such import. But also the statements at Wikidata can often provide just the content needed to do just that. Jheald (talk) 19:34, 22 September 2017 (UTC)

From my perspective Options 2 and 3 would be helpful: keep drawing from Wikidata, but allow a local override. I don't mind making changes to the Wikidata descriptions, but others do. Let's allow a local override. I would also add an option 3a:

Option 3a: Allow a null override of Wikidata description for cases where the title itself is adequately descriptive. So, History of Iran and List of songs featured in Shrek just don't have a description below them.

Also, let's write a manual of style for this, and see whether our MoS and Wikidata's overlap or not.--Carwil (talk) 04:13, 24 September 2017 (UTC)

Still, History of Iran might be a notable book with its own article, and it would be useful for descriptions to discriminate it from the item on the history proper.--Ymblanter (talk) 07:42, 24 September 2017 (UTC)
Option 3 can effectively be converted into 4a, by a bot running at one edit per second for two months overriding wikidata on every article. However if that is the result community wants, it would be better to do so directly via 4a rather than via a bot-hack on top of 3. Alsee (talk) 08:31, 24 September 2017 (UTC)
@Ymblanter: That's what History of Iran (book) is for. There's no need for any description in that case as well.--DarwIn (talk) 12:06, 24 September 2017 (UTC)
Really? If you see History of Iran (book) you know immediately what it is about? I actually doubt this.--Ymblanter (talk) 12:30, 24 September 2017 (UTC)
@Ymblanter: Most certainly. And if the book actually is about the History of Iran, as it should be in 99.9% of those situations, there's no need for description at all. When you look at it, you wouldn't think it's a book about "Fishing in Portugal", would you?--DarwIn (talk) 12:56, 24 September 2017 (UTC)
I do not know about you of course but I happen to think that the name of the author of the book is essential information about the book.--Ymblanter (talk) 13:00, 24 September 2017 (UTC)
@Ymblanter: Sometimes it is, sometimes it isn't - many of the most important History books I know are the work of a large group of people under some coordination, and not of a single author. And History of Iran (book) is more than enough "to discriminate it from the item on the history proper", as you stated. Anyway, I understand your point. When/if a description is needed, add one, just don't use Wikidata as the prime source for it.--DarwIn (talk) 13:08, 24 September 2017 (UTC)
For users of the mobile app and the VisualEditor, the description does more than disambiguate, it also clarifies the exact topic being referenced. So, A History of Iran should not just say "book" in the description, it should say "2008 book by Michael Axworthy." And The History of the Siege of Lisbon should (and now does) say "1989 novel by José Saramago." Unlike disambiguation pages, the descriptions should aim to still work even as more items are added to Misplaced Pages/Wikidata.--Carwil (talk) 15:47, 24 September 2017 (UTC)

clarification

User:DannyH (WMF) I am trying to understand your role at WMF and in the WMF decision-making process about what to do with the descriptions. I checked the org chart and it appears that you are within "Community Tech" as a "Senior Product Manager". Would you please clarify - are you here writing as some individual employee of the WMF, or as someone with authority over decision-making on this issue? It is also not clear to me how your position relates to Jon's; would you please explain? Thx Jytdog (talk) 19:43, 22 September 2017 (UTC)

Sure, I can see how that's unclear. Jon is the product lead on the Reading team; I'm product lead on the Community Tech team. In my work on Community Tech, I've had a lot of experience over the last couple years working directly with community members on feature design, including some experiences where things got heated. I was talking with Jon and other people on his team about this discussion, and they asked if I could take lead on the feature-related communication, and help to find a solution. I'm not directly in charge of the product team that would work on making these changes, but we're all talking, and when we get closer to a conclusion on the community side, I can bring everybody together, and we can figure out requirements and timelines. -- DannyH (WMF) (talk) 00:40, 23 September 2017 (UTC)
OK, thanks for explaining. So, a) you are kind of "chief negotiator" for the WMF here, and b) you are looking to arrive at a concrete solution here. Please tell me if I have that wrong.
Three additional questions:
With regard to the goal of arriving at a conclusion here, is the intent that what is decided here is what will be implemented, or is WMF intending to take the conclusion to RfCs at the relevant communities?
Reviewing what you have said here, my sense is that the WMF is unwilling to take the description off of all en-wP content (the apps, visual editor, etc). Is that correct?
If that is correct, who is the person at WMF responsible for the decision to not take the description off?
Thanks again. Jytdog (talk) 01:05, 23 September 2017 (UTC)
Regarding Jytdog's last two additional questions: indeed, a lot of talking next to each other seems to be going on. Seems like, to use an analogy, WMF is trying to keep a car with a leaky tire driving (we'll figure out how to repair or replace the leaky tire while driving, in a sort of "think of the children" reasoning ("how would they get to school without the car?" or something in that vein)), while many of the Wikipedians in the discussion give clear signals the car would be better taken out of traffic first, and not allowed back in traffic before the leaky tire situation is remedied. The proverbial children may never reach school in the car driving around with a leaky tire. For the less technically inclined: continuing to drive around with a leaky tire is not so much an issue of loss of comfort, as the technical fact that it makes the tire heat up, and ultimately explode, due to friction causing heat and heat causing air to expand uncontrollably ("friction" and "hot air on the brink of explosion" fit well in the analogy of what I'm seeing on this page). So, indeed, who is the driver who can decide to take this car out of traffic before serious injury (read: some sort of loss of credibility for WMF projects, ultimately leading to less users) is caused? Figuring out repair modes is less prone to controversy during a period when the vehicle is temporarily not "live". --Francis Schonken (talk) 08:49, 24 September 2017 (UTC)
Well put.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅ᴥⱷ≼  13:01, 24 September 2017 (UTC)
Removing all of the Wikidata descriptions "immediately" would be a time-consuming engineering project that would take longer to implement than finishing this discussion and coming up with a better solution. It's really not a practical strategy. I understand why people aren't trusting the Foundation on this, since there was already an RfC. And I understand why people aren't trusting me, because why should you, and it's up to me to act trustworthy. I'm going to keep talking to people about a practical solution. I think the Crimean school bus is going to be okay for a minute. -- DannyH (WMF) (talk) 16:21, 24 September 2017 (UTC)
??? Who said anything about "removing all of the Wikidata descriptions"? I understand it is just about disabling an automatic coupling of "Misplaced Pages" and "Wikidata" in the two remaining apps that still make this coupling (and keep it off in all implementations where en.Misplaced Pages editors can't turn it off by removing a template etc). All the rest is "solutions", or not something for which WMF needs to intervene (whether or not Wikidata content is pulled via certain en.Misplaced Pages templates, is, as such, and putting it in as few words as possible, nothing for you to negotiate). Wikidata descriptions are of course useful within the Wikidata system, for instance when manually updating an item's properties. So, nobody asked to remove Wikidata descriptions from the Wikidata system.
@DannyH (WMF): seems the basic distinctions needed to negotiate in this discussion are lacking (e.g., distinction between "content", which nobody asks to remove, and "automatic coupling of Wikidata and Misplaced Pages", which the en.Misplaced Pages community has asked to switch off in all remaining apps that still do that *automatic* coupling). Maybe time to ask for a different negotiator, that is, one who can make these distinctions. --Francis Schonken (talk) 16:56, 24 September 2017 (UTC)
@Francis Schonken:: sorry, that's what I meant by "removing all of the Wikidata descriptions" -- taking out the automatic couplings from the apps. I didn't mean removing them from Wikidata. The concept of removing Wikidata descriptions from being displayed on the apps sounds simple, but is actually technically more complex than it sounds, because they're integrated in a lot of different places. It's not a grand project that would take months, but it would take more than the couple weeks that I hope it will take to figure out a better consensus solution to this problem. -- DannyH (WMF) (talk) 13:31, 25 September 2017 (UTC)
DannyH, that ("figure out a better consensus solution to this problem", combined with the previous sentence, sounds as if you have already decided that "taking out all the automatic couplings from the apps" is not the best (or even a good) solution. Why? That it may be hard for the developers (which may or may not be true, the WMF has too often used this excuse even when it was patently untrue) doesn't mean that it isn't a good solution or that we have to find a better one. You still seem to be pushing for a certain direction (pro-Wikidata), despite claiming that this is not what the WMF does. And of course, you (WMF) could take them out one by one, and keep us posted about the progress. Or you could actually present a concrete reply to some of the suggested better (!) solutions, like introducing a new, general template which (like Persondata) could be used across wiki-languages and could be read by the WMF where needed. As it stands, I see very little actual progress being made by the WMF, more stalling and pushing in a certain direction. Fram (talk) 13:41, 25 September 2017 (UTC)
  • User:DannyH (WMF) thanks for posting here. Would you please answer the three follow up questions? Thanks! Jytdog (talk) 18:48, 24 September 2017 (UTC)
    • @Jytdog: just a friendly suggestion: maybe reformulate the second follow-up question a bit clearer, the part starting from "take the description off of all ..." which may have set Danny on a wrong foot regarding what exactly was being asked (if I understand correctly, Danny seemed to think that the request was to "remove all of the Wikidata descriptions", which is a question they answered with "no", but not really the question you asked, I suppose). --Francis Schonken (talk) 19:15, 24 September 2017 (UTC)
Jon listed the places where it is used well above in their section 4 which I will copy/paste here:
As you may know Wikidata appears in other places on Misplaced Pages. Wikidata descriptions appear not only below the title on mobile web in all languages except English and Russian, but in the following places:
  • Apps under the title
  • Visual editor (desktop and mobile)
  • Portal search (www.wikipedia.org)
  • Mobile web and mobile app search
  • Related pages (bottom of mobile web and app pages)
  • iOS widgets
  • App maps feature
  • Apps feed feature
The ones that are of the most concern are the first two, as both are explicit interference with en-WP content. I understand the descriptions have been taken down from the 4th in en-WP as a result of the March RfC. I have been uncomfortable with use of the Wikidata description field in the various navigation places -- as far I understand it, these uses arose in the course of the work of the Discovery team following the lines laid out by the Knowledge Engine debacle under Leila when the WMF completely lost its way and wanted to become The Great Aggregator of All Noncommercial Content... but I am not currently contesting that use for those purposes. I probably should, and may do later, but that is not the issue now. So to restate the three questions
  1. Is the intent that what is "decided" here is what will be implemented, or is WMF intending to take the conclusion to RfCs at the relevant communities?
  2. Would you please confirm that WMF is unwilling to remove the Wikidata descriptions from Apps under the title and Visual editor (desktop and mobile) for en-WP content?
  3. If that is correct, who is the person at WMF responsible for the decision to not take the description off these places?
-- Jytdog (talk) 19:33, 24 September 2017 (UTC) (removing VE as this is a navigation thing Jytdog (talk) 18:05, 25 September 2017 (UTC))
"as far I understand it, these uses arose in the course of the work of the Discovery team following the lines laid out by the Knowledge Engine" eh.. that seems extremely unlikely to me. Other than the portal work, all those usages originate from different teams. I think some even predate that entire team... —TheDJ (talk • contribs) 12:38, 25 September 2017 (UTC)
@Jytdog: P.S... what makes VE a content usage in your view? To me the usage by the link inspector seems more similar to the other usages, than to the subtitle usage... —TheDJ (talk • contribs) 15:00, 25 September 2017 (UTC)
Perhaps I am misunderstanding: i don't use VE and didn't actually go check. By listing "VE (desktop and mobile)" this way, I believed that the description field is what you see at the top of an en-WP article when you are using VE on web or mobile. Is something else meant? Jytdog (talk) 15:10, 25 September 2017 (UTC)
That's absolutely not how the VisualEditor uses these descriptions. It offers a drop-down menu for new links—see image on the right—which is (as I said above) exceptionally useful for people editing a page. When the link is chosen, you don't see the description, nor the does the VisualEditor help you see or edit the Wikidata description of the page you are currently editing.--Carwil (talk) 17:28, 25 September 2017 (UTC)
I see, so it is a navigation thing. As I noted above, this is... problematic but not what I am focused on now. Thanks for explaining. Jytdog (talk) 18:05, 25 September 2017 (UTC)

Hi everyone: Based on the conversations that we've had here, I've made recommendations to the Reading team and to Product as a whole. It's going to take people a day or two to talk about it, just because there's a bunch of people to check in with, in different time zones. I don't want to say much about what the recommendations are just for the next day or so, because I don't want to end up making promises that I couldn't keep. I'll definitely get back to everyone here by end of the day Wednesday (in SF) -- if I don't have anything clear to say then, I'll at least check in and explain what's going on in more detail.

So, to answer Jytdog's questions: #1. My intention is that decisions here will be implemented. There was already an RfC in March, and based on the discussions here, I don't think another RfC would be much different. But, like I said, there needs to be conversations with a bunch of people. #2. Right now, while this conversation is going on, (ie for the next couple days, and maybe couple weeks if things drag out) the WMF does not want to pull all of the Wikidata descriptions out of the apps before we've all discussed and agreed on a solution. That's what I've understood from Jytdog's posts over the last week -- that the Wikidata descriptions should be pulled from the apps immediately (as in, today) before we discuss or decide on a solution that gives Enwiki editors more control over the descriptions. If the question is "Would you please confirm that WMF is unwilling to ever remove the Wikidata descriptions," then the answer is no, we are not permanently unwilling to to ever remove them or give Enwiki editors more control. Sorry, I'm trying to be super extra clear, but there are a couple double negatives involved. :) #3. The decision to not remove the Wikidata descriptions this week is shared among pretty much everyone at the WMF, because we want a couple more days to talk about it and figure it out. The decision on whether to remove the description or give Enwiki editors more control has not been made; we'll be talking about it, and I'll definitely check back by Wednesday. Sorry I can't be totally definitive right now. I know that it's frustrating that people on this page have been talking about this since March (or longer) and you're not getting a definitive answer right now. -- DannyH (WMF) (talk) 13:51, 25 September 2017 (UTC)

Thanks for your replies. The notion that the WMF is "considering" giving the en-WP community "more control" over en-WP content is completely upside down. I will until your Wednesday reply before deciding my next steps. Jytdog (talk) 18:19, 25 September 2017 (UTC)
DannyH (WMF) as long a reasonable progress is being made, I accept that it would be more efficient to leave the current system in place while building an agreed-upon-solution. On the other hand, I'm feeling a bit wary/paranoid about the vague way you phrased "give Enwiki editors more control". If that means continuing to use wikidata descriptions and providing 'more control' by increasing wikidata-integration - then I am willing to help draft an RFC on the proposed enhancements. However I don't support it and I suspect the proposal will fail. Alsee (talk) 18:45, 25 September 2017 (UTC)
Alsee, if in their Wednesday response the WMF doesn't say it is taking the descriptions down from the apps and that it will seek consensus from the relevant editing communities before re-instating some new version, I am thinking that I will re-instate an RfC along the lines of the one you asked me to take down. In my view this is somewhat of a movement constitutional crisis. The folks from WMF don't understand the fundamental deal here (volunteers generate content following their project policies and guidelines; the WMF publishes it) nor do they understand the importance of consensus nor even why that process is so fundamental in this environment. (It is telling that they were going to run with whatever the few people talking here had suggested.)
I realize that the descriptions are just a few words but the principles here are important to me, and I think they are important to most other people in en-WP as well. The world should not remain upside down. Jytdog (talk) 19:22, 25 September 2017 (UTC)
Isn't stripping functionality for 5.6 million Android users, unknown millions of iOS users () on the Mobile App, and thousands of VisualEditor users because of "a constitutional crisis" between active editors and WMF exactly what WP:POINT is meant to try and prevent? Why are we not talking about this in terms of the experience of readers: What helps them navigate? What helps new editors write (and link)? What will cause the least astonishment: fixing a problem iteratively or ripping out functionality and then putting it back in?--Carwil (talk) 17:26, 27 September 2017 (UTC)
Putin: But look, I really improved the highways in Crimea! Isn't that great?! I mean, look at this metric I created -- all the numbers are great!! I am improving Crimea while all you people just stand around and wring your hands over trivia and criticize me. Stop getting in my way and help me improve Crimea!"
Rest of the world: "....." Jytdog (talk) 17:30, 27 September 2017 (UTC)
When the WMF builds a highway—I mean an app—it appears simultaneously in every country—I mean language. The "rip it out" request requires forking the Misplaced Pages app to be less functional in English than any other language. Again, we and the WMF collaborating and interdependent, not sovereign and independent. Anyhow, you're just reinforcing that this is about making a point, not improving the encyclopedia.--Carwil (talk) 17:39, 27 September 2017 (UTC)
Putin: "The territorial imperatives of Russia are not a matter for you tiny people to debate. Now who will help with the highways in Crimea!? Where is my 'attaboy!' for this great work I did!?"
Rest of world: "................." Jytdog (talk) 19:45, 27 September 2017 (UTC)

Hi everyone: I said on Monday that I would let you know what's going on today. The product team is still talking things over, so I don't have anything substantial that I can talk about yet.

There are a bunch of people from several different teams who are actively talking about this question right now, and what our response should be. People are coming at this from different perspectives, and as you know, sometimes it takes a while to reach consensus.

We're having a meeting tomorrow morning to talk things over. I don't know if we'll have a clear answer yet, but I'll definitely come back to this page tomorrow and let you know how it's going. This issue is important, and we're taking it seriously; we want to make sure that we're on the same page, when we come back here and talk with you all again. Sorry for the delay, I'll write more tomorrow. Thanks. -- DannyH (WMF) (talk) 00:38, 28 September 2017 (UTC)

Proposal from WMF

Hi everyone: As I mentioned yesterday, the product teams had a discussion this morning about the Wikidata descriptions. I'll tell you how we're thinking about the problem, and what we think would be a good direction for the feature. We're seeing this as a continuing discussion, so we want to know what you think.
Short descriptions are useful in search, and they're essential to features that are used very heavily on the apps, including the list of Top Read articles. Removing the descriptions completely would be damaging to the readers' educational experience, with no benefit to anyone.
But there is a problem with editorial control and dispute resolution, which we didn't pay enough attention to. When there's a content dispute on English Misplaced Pages, there's a structure for how to resolve it, with a way to escalate the problem if the editors can't resolve it amicably. We don't have a structure like that for cross-project work, so if there's a difference of opinion between Misplaced Pages editors and Wikidata editors, it's difficult to resolve. The existing feature gave that editorial control to Wikidata, because they had a structure for defining a short description. But through this discussion, we're understanding that if the page we're showing is from English Misplaced Pages, then it's appropriate for English Misplaced Pages to be the center for editorial control. So we're thinking of the proposed approach as a cross-project default with a local override, which gives the local community the ability to resolve any differences. This is similar to the way that we use images from Commons, or interwiki links from Wikidata.
We're proposing a new magic word -- {{#D:description}}, or something similar. That local description would be the one that's used. If there's no magic word or the parameter is left blank, then it defaults to the Wikidata description.
We think that it wouldn't make sense for English Misplaced Pages to start from scratch and create millions of descriptions, so the local override would allow people to use the existing Wikidata material that's good, and override it when there's a reason to fork from the Wikidata version. We'd like to encourage people to continue partnering with the Wikidata community as a source of new and updated descriptions, but we also acknowledge that once this feature is set up, it's up to the English Misplaced Pages community to decide how to use it.
If this is where we're going, then we'll also talk about how editing descriptions in the app should work. Right now, on all languages but English, users on the Android app can edit the Wikidata descriptions. We could work on supporting editing the local exceptions instead, but we'll need to figure out how the user interface would work. We're still talking about it, and we're interested in what other folks think.
Now, if descriptions are still coming from Wikidata as the default, then people will want to be able to monitor changes from Wikidata. Right now, you can see Wikidata edits in your watchlist if you uncheck "hide Wikidata" or enable the Wikidata edits filter, but that includes all edits to the item, not just the English description. The Wikidata team is currently working on showing only the locally relevant Wikidata properties -- a test version of that feature is currently live on Greek Misplaced Pages -- but it's too early to say when that feature would be available for English.
Like I said, we'd like to continue this discussion with folks here, to find out what you think and see if we can get closer to a consensus on this feature. While this discussion touches on larger questions -- like governance on cross-project features, inter-project dispute resolution, and Wikidata integration in Misplaced Pages -- I think that this discussion isn't the right place to resolve those. I'd like to keep this conversation focused on the practical things that we can do to restore English Misplaced Pages's editorial control for the short descriptions. If you think this requires bigger conversations, we're open to having those discussions, but I want to work on tangible solutions here. So that's where we are right now. What do you think? -- DannyH (WMF) (talk) 23:31, 28 September 2017 (UTC)
This is not like how images from the Commons are used. Use of images from the Commons in en-Misplaced Pages is a) driven by en-WP editors who add images to en-WP voluntarily one by one, and b) is governed by en-WP's WP:Image use policy.
When you say "We'd like to encourage people to continue partnering with the Wikidata community", I hear "extortion".
The Wikidata field will show, and if it violates en-WP policy, then it is up to en-WP editors to take action to override it, and everybody has to learn some weird template to do that. I do not find it all reasonable that WMF dumps a bunch of unsourced content into en-WP and then just leaves that for en-WP volunteers to fix (and that you would "give" us tools to fix it, is even crazier.) I have said this before but the arrogance and ignorance of this, is just beyond my understanding. And I really believe you have no idea at all how batshit crazy what you are saying is or how blatantly the WMF is displaying power and disdain.
Putin: "So I get it that that when we changed all the highway signs in Crimea to Russian that has messed with people and we have done some mistranslations maybe. You all can fix those signs where ever you find them - I will give you all some paint brushes. OK, go get moving. Aren't these highways great?!"
Rest of world "...................... "
Please listen to the metaphor. This is what you sound like.
You never got consensus to systematically add content to Misplaced Pages. You just moved on in. Jytdog (talk) 03:05, 29 September 2017 (UTC)
  • It was a (very) bad idea to give Wikidata editors control over Misplaced Pages content. Giving Misplaced Pages editors a gizmo with which they can control Wikidata content is a stupidity of the same order, and doesn't even begin to address the first issue, which was, summarized: one WikiMedia project should not decide on the content of another WikiMedia project. Misplaced Pages editors do not control the content of Commons (which seems to be a misunderstanding in Danny's explanation above), Commons editors do not control what Misplaced Pages editors decide to retrieve (or not) from Commons for use in Misplaced Pages. --Francis Schonken (talk) 05:56, 29 September 2017 (UTC)
Another way to think about this, is that WMF has essentially run a bot to systematically add content to en-WP articles. en-WP has a bot policy: WP:Bot policy. Did WMF go through the process described in that policy to run the software that made these systematic changes to en-WP content in the apps? Jytdog (talk) 06:00, 29 September 2017 (UTC)

"So we're thinking of the proposed approach as a cross-project default with a local override, which gives the local community the ability to resolve any differences. This is similar to the way that we use images from Commons, or interwiki links from Wikidata." As has been siad countless times now, this is not how we use images from commons. With Commons, we decide which image, if any to use, no images are sent by default ever (I hope, or has the WMF done this as well somewhere?). Interwiki links is exactly what Wikidata has been set up for, and where enwiki and the others voluntarily relinquished the lead. But this is not content shown in articles and seen as the first thing by all mobile or app users.

"We're proposing a new magic word -- {{#D:description}}, or something similar. That local description would be the one that's used. If there's no magic word or the parameter is left blank, then it defaults to the Wikidata description." No, no, no! The default is enwiki. There may be an override where we can explicitly say "use the Wikidata description instead", but in many cases we will want no description at all, or certainly prefer "no description" over "the Wikidata description". The examples of lists and disambiguation pages have been given, or something like Spirit (Depeche Mode album), which doesn't need a description here, and certainly not the utterly redundant "Depeche Mode album" used as description on Wikidata (where this description makes 100% sense). At the very, very least, either "no magic word" or "magic word without description" should result in "no description" instead of the Wikidata one. My preference would be "no magic word = no description".

"We think that it wouldn't make sense for English Misplaced Pages to start from scratch and create millions of descriptions, " I doubt that Wikidata hsa "millions of descriptions" we could use, if you discount all lists and disambiguation pages, and most or all pages with a disambiguator on enwiki (which already serves as a description in many cases), and take into account all pages on Wikidata without a description anyway. Bot adding the magic word to all pages which don't meet the above exceptions shouldn't be too hard anyway. Using a smarter bot instead which creates descriptions from either enwiki first lines or enwiki infoboxes may be even better of course.

"We'd like to encourage people to continue partnering with the Wikidata community as a source of new and updated descriptions " Why? It is not the role of the WMF to encourage or discourage such things, and the descriptions on Wikidata very often serve a different purpose than the ones here. It doesn't make sense to look at a much smaller, multilingual community to be the source of descriptions on enwiki, when the descriptions on that community often serve a different need in the first place.

"We could work on supporting editing the local exceptions instead, but we'll need to figure out how the user interface would work. We're still talking about it, and we're interested in what other folks think." Well, it would be rather ridiculous to show people the enwiki description, and then have an "edit" functionality that sends them to Wikidata, where any change they make won't affect the end result anyway. Which is a god reason to drop the "use Wikidata decriptions under circumstances X, Y and Z anyway" approach and go for a full and only enwiki approach instead. Fram (talk) 06:45, 29 September 2017 (UTC)

Note: I've added this discussion and proposal to WP:CENT, feel free to amend the note if it is unclear or biased. Fram (talk) 06:56, 29 September 2017 (UTC)

Note 2: now also added to WP:VPPR, WP:AN and WP:BON. Please drop a note elsewhere if necessary. Fram (talk) 07:08, 29 September 2017 (UTC)

Bottom line: WMF thinks that short descriptions of some kind are essential, and doesn't believe the airy assertions above that 5 million perfect pink unicorns can be created here overnight. Instead, it suggests going with the nags we already have, even if some of their faces need a wash; and trusting in the wiki way of improving these where they fall short, by opening them to the community and letting the community improve them. (It's also a lot easier to improve them and systematise them at scale on WD than it would be here). In some cases they may not be great, but in most cases the current descriptions or auto-descriptions are better than nothing and at worst mostly harmless. The proposed over-ride mechanism lets editors improve descriptions from in here if they want to, and start hand-crafting bespoke descriptions for WP where we can be bothered -- eg in the first instance perhaps for the pages that are highest rated or most read or considered to be at a particular high risk. And probably a mechanism will evolve to offer these locally optimised descriptions back to Wikidata.
User:Jytdog might like to reflect on a point that earlier versions of one of the policy pages, perhaps WP:NOT, were quite brutally blunt about: WP is not a democracy. Ultimately it's WMF that owns the servers, and they can and will do what they want. If you don't like that, WP is not WP:COMPULSORY. Jheald (talk) 08:05, 29 September 2017 (UTC)
To be honest, I do not see any problem. There is an RfC that descriptions should be not taken from Wikidata automatically. There is a common wisdom that they can be taken from Wikidata, but many people, some of whom are especially vocal, believe this is not appropriate. I think the solution is obvious: (i) make a mechanism which would only show a Wikidata description on the English Misplaced Pages if the description was created from the English Misplaced Pages (similarly to interwiki links) or validated from the English Misplaced Pages in a similar way; (ii) instantly disable and do not show Wikidata descriptions unless validated. This is the only way to let people to start caring, and it should not affect any other projects.--Ymblanter (talk) 08:11, 29 September 2017 (UTC)
We can do more than nothing. And I don't think WMF actually wants to pull this kind of power play. I really hope not. Jytdog (talk) 08:28, 29 September 2017 (UTC)
This is also how I personally see it: since descriptions are tightly bound to article and language (this en-Misplaced Pages in this case), the solution which would make the most sense to me would be not for WikiData entries to be overridable by a special/magic variable, but for it to originate from en-Misplaced Pages directly, considering that it's only a short text which could be as part of a template. A bot could initially import existing descriptions into en-Misplaced Pages articles. However, I understand that from an implementation's standpoint the existing code depending on WikiData and perhaps the mobile applications might need modifications if this was done. An alternative would be to support the proposed override magic variable and to use a bot to override all existing uses, such that the code requires less changes while technically obtaining a similar result... On the other hand, while new articles are created, more and more articles could end up with descriptions from WikiData in the long term (unless a regular robot run systematically moved to en-Misplaced Pages any WikiData-originating description). —PaleoNeonate – 08:32, 29 September 2017 (UTC)
I am sure 95% descriptions can be generated by bots and be acceptable on both English Misplaced Pages and Wikidata. I think the real question is what to do with the existing description. I proposed to not show them on the English Misplaced Pages unless explicitly validated (possibly by bot)--Ymblanter (talk) 08:42, 29 September 2017 (UTC)
  • In the event any sort of 'magic word' was implemented, it would be trivial to create a bot to run through the ENWP articles making sure none get descriptions from wikidata. It might be a large number of articles (as Fram has pointed out it might not be as large as expected) but that would still be a matter of time to work through, in the weeks rather than months. If the end result is WMF using valuable engineering time in order to implement something we can then use to actively prevent any Wikidata descriptions being shown, it would be time better spent just disabling the descriptions from wikidata from your end. Its a waste of time and money implementing something that will only be used to bypass a *previous* waste of time and money. Only in death does duty end (talk) 09:26, 29 September 2017 (UTC)
    There's a lot coming up here, but I want to respond to one thing in particular. As I said yesterday, we want to give English Misplaced Pages control of the descriptions. When we're figuring out possible solutions with you all, the thing that makes it hard for us is the idea of blanking all of the current descriptions.
    I agree with Fram that the Wikidata descriptions that describe the page rather than a subject are useless -- "Wikimedia list page," "Wikimedia disambiguation page," and any other examples of that kind of thing. Those should be removed, and that's something we can do. But there are lots of helpful existing descriptions that make using the app a better learning experience, and the idea of going from x million descriptions to zero, even for a short time, is hard for us to agree to. That's what made us lean towards local exceptions, rather than automatically pulling all descriptions from Misplaced Pages. I think that we could come to a productive, workable solution that gives control back to English Misplaced Pages where it belongs, if that solution doesn't involve a period when there are no descriptions displayed at all. What do you think? -- DannyH (WMF) (talk) 22:52, 29 September 2017 (UTC)
    Why is it such a hard thing to agree to? It would indicate that WMF is willing to accept Misplaced Pages control over Misplaced Pages content. Retaining the descriptions shows a reluctance to leave Misplaced Pages content/appearance in the control of Misplaced Pages, and sends us a message that (somebody at) WMF is dead set on continued interference and on winning this battle, which should not even be a battle. This reluctance is likely to escalate the problem. · · · Peter (Southwood) : 06:09, 30 September 2017 (UTC)
  • "If there's no magic word or the parameter is left blank, then it defaults to the Wikidata description." What is the justification for this proposed behaviour? I can understand, if not necessarily support, wanting to continue using the WD descriptions as default, and using the magic word to "opt out" for a localised description instead, but articles are not created containing magic words by default: editors place them there deliberately. And it follows that if a blank {{#D:}} tag is in an article, it is because editors feel the description should be left blank. The null parameter should be respected as a null description. Please don't make use pass a single non-breaking space to all the pages we feel are better left without descriptions. Snuge purveyor (talk) 08:52, 30 September 2017 (UTC)
  • I have not seen objections which address the key point mentioned just under "Proposal from WMF", namely that descriptions are very useful as they allow the software to give better results when people search for topics, and they allow showing a brief outline of what an article covers when listing Top Read articles. Those objectives should be supported. Johnuniq (talk) 10:13, 30 September 2017 (UTC)
    • @Johnuniq: Personally, I find descriptions very useful, and I applaud that idea to make such thing appear at certain places, such as the search list, or the mobile app. In Misplaced Pages I've the article preview gadget activated, which does a similar function (and sometimes in a better way), and I recognize the great value of those short descriptions. But they should be entirely placed on the Misplaced Pages side, and under Misplaced Pages control. That's where content belongs to, that's where it can be properly curated, maintained, updated. Wikidata is useful for interwikis and possibly other things, but should never had been brought into this process. They should be excluded from it as soon as possible. Wikidata here it's only messing up things, with no gain at all. Generate short descriptions on the fly from the leading sentence/infobox from Misplaced Pages articles, seems to me by far the best option, if it's possible to implement. If Wikidata wants those descriptions as well, they can copy them afterwards, and do whatever they would like to with them.-- Darwin 12:31, 30 September 2017 (UTC)
  • I don't think this proposal is going to work, because it is a compromise. More important, I think it puts WMF in the awkward position of having to defend this compromise, while the community itself is still deeply divided. This opens up the foundation to a neverending amount of wikilaywering that they have to deal with. This community clearly has no interest in evolving any of this, has no consistent message for WMF and no plan. Just return it back to status-quo pre-2015, so that we can move past the drama. I'm not saying we should not have this functionality on English Misplaced Pages, but by now I've arrived at the point, where as WMF I wouldn't work on this until the community has made a design for it and gets sizable portion of the community to sign off on that design. It's time to let the editors do the software development, they clearly have a desire to work on this. This has gone on long enough, the foundation has more important stuff to work on. —TheDJ (talk • contribs) 18:00, 30 September 2017 (UTC)
  • DannyH (WMF), I think there is a lot of understanding for your concern: thing that makes it hard for us is the idea of blanking all of the current descriptions. Maybe it will help if I explain why that option keeps coming up. Many on the community side find it hard that the WMF keeps turning the discussion to blanking descriptions. I believe the effective community consensus would be for using the lead sentence, preferably with the override option added. That would effectively give descriptions for all articles. Major win. The reason 'blanking' comes up is because we can't build the desired solution from our end, and we do not presume to be able to order you to build it. When the WMF drops that option from the discussion, we naturally turn to the options that you leave available to us. When you narrow the discussion to "The WMF won't discuss anything except Wikidata descriptions", people who think this shouldn't be Wikidata at all are cornered into the "blank it" option. I don't know if the WMF is willing to discuss non-Wikidata solutions, but hopefully this helps you and others at the WMF understand why the discussion is going the way it is.
    Remember when I said I was wary and paranoid about what response you would bring back from the WMF side? I am disappointed, but completely unsurprised that you silently excluded the non-Wikidata option from discussion. You haven't explicitly declared it "out of scope for discussion", but your response here has implicitly done so. You are effectively asserting that "blank it" is the only alternative remaining on the table. Alsee (talk) 04:30, 1 October 2017 (UTC)
    Alsee, thanks for saying that. Actually, using the first sentence isn't out of the question -- you're right, I should have talked more about that option. I think you're right that blanking has come up because of WMF stonewalling, and then we respond to that by getting more nervous about community control, and the cycle continues. I should be thinking outside that cycle. We're going to have more internal conversations about solutions today, and I'll make sure that deriving descriptions from the first sentence is part of the discussion. I'll report back later today on what we're thinking. Thanks. -- DannyH (WMF) (talk) 16:29, 2 October 2017 (UTC)

Persondata-like system

I got involved in the last stages of the deprecation of persondata, that is the stage where we were hammering out a system to actually completely remove all persondata from mainspace. I rather tried to slow it down, at least impede an uncontrolled deletion, thinking, maybe we might need this still some day. But the reasons for removal were overwhelming, and thus we eradicated uncountable hours of work by thousands and thousands of Wikipedians. Sure, the system that is proposed now will be "different" in several respects, but reasons for not having it will be, in whatever form we have it, still overlap to a great extent with the reasons for eradicating the persondata system (and these reasons were sound, nobody doubted that).

Long story short: I don't think we need a system that knowingly or unknowingly mimics the old persondata (again, even when several people will contend it is "different" in many respects). There are too many reasons for not having it, without even speaking about the insult to the Misplaced Pages editing community: first they were asked to provide and maintain data for a system that on most interfaces didn't show up; then the content in that system was completely and utterly eradicated, flushing countless man-hours down the drain; and now there is talk about embarking on a similar adventure – to which my answer would be: no, no and again no, whatever we do, not something that has too many similarities to that debacle. --Francis Schonken (talk) 08:38, 1 October 2017 (UTC)

Extended disambiguator analogy

We have disambiguators in article titles, usually between brackets or after a comma (see #2 and #3 WP:ATDAB). For the purpose of this discussion I'll call these "short" disambiguators.

Then we have the somewhat longer disambiguating statements at, for instance, disambiguation pages, e.g. at Sarah Brown: "charity director, wife of former British Prime Minister Gordon Brown" and "American middle distance runner", plus often some type of time indicator (year of birth between brackets etc). Similar disambiguating statements may appear at the top of article pages, for instance implemented by {{this}}. These I'd call "extended" disambiguators, and are, afaics, the closest thing we have to Wikidata descriptors.

Thinking a bit further, it is clear how different Misplaced Pages's system for disambiguation is (i.e. the system for getting readers to the content they are looking for), compared to, for instance, Google's (which is the prevailing model on a broader scale). The systems are completely different, but are actually extremely complementary (Misplaced Pages's success owes quite somewhat to that complementarity). Wikidata-based search systems are a kind of hybrid: they generate a kind of disambiguation pages (if looked at from the Misplaced Pages angle), or a sort of Google-like search for small screens (if comparing to the market leader for such search operations) (tempted now to go on a tangent here about Jimbo Wales's ideas). But they're Wikidata, not Misplaced Pages, So I'd title them "Wikidata search", or whatever else that is not "Misplaced Pages". And look for fruitful complementarity instead of merging two fundamentally incompatible systems, which would be going completely and utterly nowhere.

As for the short descriptions under article titles of Misplaced Pages content pages: the development of these should be steered by those who actually use them. In-Misplaced Pages the apparent overlap with existing extended disambiguators could be exploited and expanded. But no live harvesting from another project (Wikidata) resulting in mixed content, for which neither project can be the ultimate stakeholder. It is extremely divisive (i.e. steering for disagreement between sibling projects) to suggest otherwise, and WMF spokespersons who keep harping on this have no place in this discussion: practically the tactics are a sort of "divide et impera", whether WMF spokespersons are aware of that or not (I prefer to think they are not, but in either case it should stop).

For VE and other uses of Wikidata descriptors: either it is some sort of disambiguator/search use (in which case: OK if clearly indicated as a "Wikidata" aid, see two paragraphs above), or it is something that should be developed in Misplaced Pages (in order to avoid mixed content being displayed as if it were all Misplaced Pages, and the in-Misplaced Pages development should be steered by those actually using the systems) – I think that for these other uses which one of the two routes sketched above applies most can usually be clarified in a few steps. --Francis Schonken (talk) 08:38, 1 October 2017 (UTC)

Expanding on "the apparent overlap with existing extended disambiguators could be exploited and expanded" applied with the {{this}} (i.e. {{About}}) template:
  • currently "109,000+ pages" contain information in this format:
    • {{About|*Use1*}}
Which results in:
  • This page is about *Use1*. For other uses, see
being displayed on these 109,000+ pages.
  • It is my contention that these 109,000+ "*Use1*" descriptions are the short descriptions we are looking for:
  1. First step: these 109,000+ short descriptions can be used immediately on these 109,000+ pages in mobile/app view (just leave out the preceding "This page is about" and the ensuing ". For other uses, see ", and you have a first base to start from (a base of 109,000+ descriptions not being too bad to get started...; also these 109,000+ pages are exactly those which are most in need of a short description while ambiguous with another similar term).
  2. Second step: it is incredibly easy to program this template thus that in normal Misplaced Pages surroundings nothing shows up in the event the suggested "For other uses" page would be a redlink (in normal screen view), after which the template could still be used for giving a short description of the article which can be harvested for app/mobile view; and if later the disambiguating or variant page gets created, nothing has to be done in Misplaced Pages normal view to make the DAB sentence pop up at the top of the page.
  3. Pages currently using similar templates (e.g. {{for}}, {{other uses}},...) could be integrated in the system, e.g. by allowing an "|about= ..." parameter, or merging their content in the {{about}} template once such template has been applied with a short description of the content of the page.
--Francis Schonken (talk) 10:00, 1 October 2017 (UTC)
At face value, looks like a good idea. I see no significant down side, though I have not searched very hard... Some work may be needed, but probably not difficult work. Cheers · · · Peter (Southwood) : 12:17, 1 October 2017 (UTC)
There are over 121000 pages using {{for}} and 45000 pages using {{other uses}}, a total of 166000 pages which will have to be checked and where appropriate, converted to {{about}}. I have no idea of what percentage will need a short description/disambiguator, but the point here is that this would be a good fix where necessary. It would improve the encyclopaedia consistently, while remaining entirely within Misplaced Pages both in terms of control and policy compliance. · · · Peter (Southwood) : 17:21, 1 October 2017 (UTC)

the override feature is worthless / Related Pages / WMF putting images on articles

Above Fram asked we decide which image, if any to use, no images are sent by default ever (I hope, or has the WMF done this as well somewhere?)

File:Andrex_puppy_(1994_advert).jpg: The Andrex Puppy, seen here in a British advertisement from 1994.

Unfortunately the answer is YES. In fact it took me two minutes to find that the WMF literally slapped an advertizement for a specific brand of facial tissues on our Facial tissue article. You can (maybe) see the problem at the bottom of the mobile view of Facial_tissue. However the Related Pages feature selects "see also" articles (and images) dynamically, so you may see different article links with different images. But if you randomly go to articles on "product" type items, it shouldn't take long to find one with a specific brand being promoted on the page. The Related Page feature links to articles containing many of the same words, so companies that sell that product are likely to be selected. You can also get some seriously bad BLP violations.

The community previously complained about this issue, but the WMF apparently didn't consider the concerns important. Not even when people were finding serious BLP violations on biographies. (I think one politician was linked to fascism, and if I recall correctly, Pig-faced women appeared somewhere bad.) They decided the "solution" was to hide the feature from editors hide the feature from desktop view, and to offer the same worthless "override" solution being proposed here. The Related Pages that are given change pseudorandomly, so only way the override feature would actually fix the problem is if we run a bot to set three (blank) overrides on EVERY every article.

Returning to the original topic: If the WMF insists on the "override keyword" for wikidata descriptions, then I now propose running a bot to apply the override on every article. The bot can either copy the lead sentence, or leave it blank with a hidden comment saying to fill it it. The same bot may as well apply three Related Pages overrides at the same time. Alsee (talk) 20:09, 29 September 2017 (UTC)

Hang on, didn't this note that non-free images would be excluded from that feature? That Andrex image is tagged as non-free - quite apart from advert concerns, it shouldn't be showing up there. Nikkimaria (talk) 20:27, 29 September 2017 (UTC) @Deskana (WMF): seems to have been active on the phab task linked. Nikkimaria (talk) 20:33, 29 September 2017 (UTC)
Nikkimaria, I'm pretty sure that appending a ping to an existing comment like that doesn't work. If you look at the diff for your edit you'll see that the blue diff-text does NOT contain a proper timestamp. Pings are only sent on a signed edit, and the software doesn't see a proper signature in that diff. I'll add your intended ping to @Deskana (WMF):. Alsee (talk) 21:09, 29 September 2017 (UTC)
@Nikkimaria and Alsee: I don't work in this area any more, but I took a look and managed to fix it. See my comment below. --Dan Garry, Wikimedia Foundation (talk) 10:09, 30 September 2017 (UTC)
Yes, quite aside from the advertising issues, this is a clear violation of our image use policy, as we have no fair use rationale for this use of the image. —David Eppstein (talk) 20:41, 29 September 2017 (UTC)
Holy crap, it didn't occur to me that this was a non-free image. WTF?! I saw the Phab task that supposedly prevented that.
Also, I had added the image to this section without noticing the non-free issue. I tried to remove it, but edit conflicted with Ymblanter fixing it. (Thanks Ymblanter.) Replaced with link to file page. Alsee (talk) 21:01, 29 September 2017 (UTC)
Apologies for reverting the second time, I misread the diff. Now I restored it.--Ymblanter (talk) 21:07, 29 September 2017 (UTC)
(ec)I thought phab:T124225 was resolved with the result that our non-free content policy won against the wishes of some of WMF's various coding teams. Has anything changed there? —Kusma (t·c) 21:09, 29 September 2017 (UTC)
The clear attitude on display here by WMF is that whenever we come to a decision or consensus that goes against the wishes of the coding teams, they will go ahead and follow their wishes anyway. I can predict that their response will be that the phab thread only talked about "mobile apps, RelatedArticles, Gather, and mobile web search" and that the related article links on the mobile view are something other than these things and therefore not covered by this decision. —David Eppstein (talk) 21:21, 29 September 2017 (UTC)
I am disappointed but not surprised by the WMF's response on the Wikidata descriptions... however I bet this non-free image issue is either a bug or (at worst) someone unaware who made an undiscussed change. I get the impression that WMF staff were OK with the non-free image issue, they explicitly built code to restrict when non-free images would be returned. (There is explicit concensus that non-free images can appear in the Popup-article-preview feature.) Alsee (talk) 22:34, 29 September 2017 (UTC)
@David Eppstein: It's a bug caused by a bad template. Please don't jump to conclusions. --Dan Garry, Wikimedia Foundation (talk) 10:09, 30 September 2017 (UTC)
Tracked in Phabricator
Task T177122
Resolved
I just created a Phab listing for the non-free image appearing in RelatedPages. Alsee (talk) 22:20, 29 September 2017 (UTC)

I don't work in this area anymore, but I took a quick look. The non-free page image associated with the Andrex article was due to an issue with Template:Non-free television screenshot which was not tagging the images associated images as non-free. I fixed the issue with that specific template. Maintenance of content-related templates is normally outside Foundation jurisdiction, so I encourage other people to take a look and see if the problem exists elsewhere. This is why we need structured data on Commons, by the way; this problem never would've happened if the data were properly structured. --Dan Garry, Wikimedia Foundation (talk) 10:09, 30 September 2017 (UTC)

@Deskana (WMF): (a) we do have such a data structure, the coders just chose to use something else instead of our Category:All non-free media. (b) Wouldn't it make more sense to fix the issue by adding the invisible code you're looking for to Template:Non-free media instead? Adding specialised code to lots of individual non-free licensing templates seems not the best way to do this. —Kusma (t·c) 16:19, 30 September 2017 (UTC)
The Non-free media template is doing that already. This is just a conflict between two templates. Dan made an intermediate fix, but that fix should not be necessary long term. I suggest people stop fingerpointing and stop blowing everything up. No one is able to keep up with what is going on right here, it fires of into every direction, this whole discussion is becoming completely useless this way. —TheDJ (talk • contribs) 17:26, 30 September 2017 (UTC)
Tracked in Phabricator
Task T177122
Deskana (WMF), thanks. I suspected this was some unintentional flaw. However I'm extremely surprised and confused at the method the WMF is using: an invisible, redundant, and apparently-undocumented-on-EnWiki "span" class. Is there any chance that the WMF could use the (obvious) Category:All non-free media? That's how we track non-free files. I expect more files will continue to slipping through the cracks based on the span method. Alsee (talk) 02:05, 1 October 2017 (UTC)

Why WMF should immediately stop pushing content from Wikidata

First, I am not a lawyer, & my knowledge of this portion of how defamation works concerning the common carrier provisions of Communications Decency Act is abysmal, but the more I think about it, the more I wonder if the WMF has really thought thru the legal ramifications when they pushing content from one of the Wikimedia projects to another.

As I understand it, if I write something defamatory about some living person on a Wikimedia website, in the end I am legally responsible for it. The WMF is held blameless because they are a common carrier. This is the legal arrangement the US phone companies have had since forever: after all, why should a telecomm be held responsible because two of their customers happen to be evil people who used their phone to plan how to blow up a school or otherwise cause massive mayhem? It's not their job to regulate what their customers discuss on the phone. In the same way, the WMF is held blameless about content on any of the Wikipedias, or Commons, or Wikisource, or Wikidata: it's not their job to regulate what is in the content.

However, once the WMF begins to edit the content of articles by taking material from one project & adding it to another, then the Foundation is making them liable for that content. At least it seems to me, & unless I'm an expert in this portion of the law -- or a judge has made a ruling on this matter -- I would advise against the WMF touching content at all. (Yes, there are exceptions & precedents about the Foundation editing articles, but these govern specific & extreme cases.) Because by inadvertently copying defamatory material from, say, Wikidata to Misplaced Pages, that potentially makes the Foundation legally responsible for it. And, as I just said, the only way to determine if the Foundation really is responsible is for it to be sued. Which costs lots of money I (speaking for myself) would not want to see spent.

Or maybe I'm just another ignorant editor, too deep into trying to keep facts about Romans of the 2nd century AD straight, to know that the project team already had the WMF legal department look at this & sign off on it. Meaning that the lawyers are perfectly happy with the risk of the Foundation being sued over an oddball case of potential defamation that will likely take years to sort out through endless hearings into something that can actually be taken to trial. But I've had enough brushes with situations involving potential legal responsibility to think otherwise. -- llywrch (talk) 07:41, 21 September 2017 (UTC)

@Llywrch: WMF aren't manually reviewing data taken from Wikidata. It's fairly clear that Section 230 continues to apply. Jheald (talk) 09:09, 21 September 2017 (UTC)
I agree it's a bit muddy though. Likely only possible to figure out in court, little precedence for a composition like this. —TheDJ (talk • contribs) 09:27, 21 September 2017 (UTC)
Maybe, Jheald. But what have the lawyers said about the Foundation directly modifying content on a project in this way? Would one of the WMF employees like to answer?

Please note: it's not my intent to trash Wikidata. As I've said elsewhere, it has tremendous potential for Misplaced Pages & other Wikimedia projects. (An obvious example is demographics: putting the raw data in one location alone is a big benefit for all of the projects; having them where they can be manipulated independently by each project -- or each page in each project -- is an even bigger benefit.) But if some vandal added something that violates WP:BLP on Wikidata, & the Foundation adds it to a content page on en.wikipedia, what would be the Foundation's exposure? Unless a lawyer can assure us any such lawsuit against the Foundation would be dismissed as frivolous, I would be concerned. (And remember, since the servers have been moved from Florida to Virginia, the laws regarding this issue have possibly changed. So there is a lot of uncertainty & potential risk here.) -- llywrch (talk) 15:01, 21 September 2017 (UTC)

The Foundation aren't "directly modifying content". They're merely showing user-supplied content sourced from two different sites adjacent to each other, without manual intervention. That is squarely covered by Section 230, which is Federal law, applicable anywhere in the United States.
If the Foundation were to take ownership of these short descriptions, maintaining them in-house as their own creation, that might be more tricky. But I don't think anyone is talking about that. Jheald (talk) 15:11, 21 September 2017 (UTC)
I don't know about the legal argument but what you are writing about the short descriptions appearing say in the android app is very weak. Passively hosting usergenerated content is very different from actively playing DJ. The systematic presence of the description anywhere other than Wikidata is 100% the product of WMF decision-making and action. Jytdog (talk)
The systematic presence of any content anywhere on any WMF site is the result of the code WMF maintains. If you think s230 doesn't apply, let's see some hard citation or argument or precedent. Otherwise it's simply how WMF chooses to present user-generated content. Jheald (talk) 18:14, 21 September 2017 (UTC)
Nope. Passively displaying vs active mixing are entirely different things, especially here where the WMF has been very clear that the content change they introduced was meant very much to be impactful. They know that putting the description as the first thing will affect what people do - they want it to. The mashup is a derivative work authored by the WMF. But as I already said I am not commenting at all on issues of legal liability - I don't play lawyer on Misplaced Pages - the WMF has lawyers. Jytdog (talk) 18:24, 21 September 2017 (UTC)
I'm pretty certain that this is a legal non-issue. It's user generated content, and it doesn't matter how much software it's sent through or where it appears. The issue is that the staff aren't manually reviewing and moderating the content. They aren't legally responsible for stuff that they literally haven't seen. Alsee (talk) 03:19, 22 September 2017 (UTC)
I'm not talking about liability; I am talking about authorship, and creating this kind of montage is undeniably a step removed from what the original author wrote. The WMF takes that authored content and pastes it elsewhere, very intentionally and this is a form of authorship. See for example Misplaced Pages:Copying within Misplaced Pages -- the person who does the copying is the "editor" recorded in the history, and we are supposed to attribute in our edit notes and record where we took it from. This dual nature is present as well in the WMF's decision to paste the Wikidata content where ever it - the WMF - places it. Jytdog (talk) 03:44, 22 September 2017 (UTC)
I had de-indented, intending to respond to the original liability concerns by Llywrch. Alsee (talk) 04:07, 22 September 2017 (UTC)
Llywrch, I checked with the Foundation's Legal team, and they read through this discussion. They don't have an issue with the feature. -- DannyH (WMF) (talk) 00:45, 23 September 2017 (UTC)

Wikidata and the English Misplaced Pages'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 Misplaced Pages'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 Misplaced Pages. 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 Misplaced Pages 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 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 Misplaced Pages 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 Misplaced Pages:Wikiproject Wikidata. Think of it as an embassy for Wikidata material to make sure it's properly sourced and expressed when placed on Misplaced Pages. And to put RfC before replacing major bits of Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages. 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 Misplaced Pages: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)
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. Misplaced Pages: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) : 06:36, 30 September 2017 (UTC)

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)

WP:Use of Wikidata in Misplaced Pages

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) : 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) : 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)

An alternative, possibly even a solution.

  1. WMF stops / removes all imposed Wikidata descriptions from English Misplaced Pages 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)
  2. 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:

  1. Wikipedians retain control of Misplaced Pages content. → Wikipedians are happy
  2. WMF get to display the short descriptions → WMF is happy
  3. Wikidata gets more useful data if they want it, and can use it how they want. → Wikidatans are happy
  4. 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
  5. 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
  6. Probably some Wikignomes will find this a great way to spend their time.
  7. There may be live eyes on some seldom seen articles which get other problems tagged during this process.
  8. 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) : 14:42, 29 September 2017 (UTC)

Misplaced Pages 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 Misplaced Pages 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) : 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) : 06:14, 30 September 2017 (UTC)
I actually pulled up the Misplaced Pages iOS app and did a couple searches to see for myself these descriptions in action. One thing I noticed is that sometimes "Misplaced Pages 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)

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 Misplaced Pages 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)