On Sat, Apr 6, 2013 at 1:00 AM, MZMcBride z@mzmcbride.com wrote:

Sorry, I don't know what this means. I thought Wikidata was already deployed to the English Wikipedia (and possibly other projects as well).

I've posted an announcement with more details on the technical village pump at http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Wikidata_pha... Let me know if anything is still unclear so I can clarify.

Cheers Lydia

-- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata

Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

On Fri, Apr 5, 2013 at 6:33 PM, Risker risker.wp@gmail.com wrote:

On 5 April 2013 19:07, Lydia Pintscher lydia.pintscher@wikimedia.de wrote:

...

On Sat, Apr 6, 2013 at 1:00 AM, MZMcBride z@mzmcbride.com wrote:

...

Sorry, I don't know what this means. I thought Wikidata was already deployed to the English Wikipedia (and possibly other projects as

well).

...

I've posted an announcement with more details on the technical village pump at

http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Wikidata_pha...

...

Let me know if anything is still unclear so I can clarify.

Cheers Lydia

Lydia, could you please point me to the discussion on *English Wikipedia* where the community indicated an interest in deploying this software? Infoboxes and sourcing to another website completely outside the control of English Wikipedia is a rather big issue, and I would expect to see a Request for Comment with at least 200-300 participants.

Risker/Anne

In my opinion, as a casual Wikidata editor and not-so-casual Wikipedia editor, I think the Commons analogy continues to hold up pretty well. Commons exists. We can use it, as a project. We don't *have* to (and indeed don't always, on en:wp, where fair use images are accepted). As I understand it, the same is true with Wikidata -- it will be around, if and when it seems appropriate to use. Of course Commons and Wikidata will both be more useful and more awesome the more projects do use them. But my very non-technical understanding of this deployment is that basically we made the projects able to see that Wikidata exists (correct me if I'm wrong!)

Now as far as I can tell there's a whole lot of work yet to do in order to figure out how exactly one might link to data or produce an infobox and what that might look like -- deployment does not seem to mean ready for prime-time, yet -- and of course the data-building itself is just barely getting started. Best practices for infoboxes does seem like a project-wide RFC to me. But hopefully, when we get to that point, wikidata will be a useful option.

-- phoebe

* I use this address for lists; send personal messages to phoebe.ayers <at> gmail.com *

On 5 April 2013 22:24, phoebe ayers phoebe.wiki@gmail.com wrote:

On Fri, Apr 5, 2013 at 6:33 PM, Risker risker.wp@gmail.com wrote:

...

On 5 April 2013 19:07, Lydia Pintscher lydia.pintscher@wikimedia.de wrote:

...

On Sat, Apr 6, 2013 at 1:00 AM, MZMcBride z@mzmcbride.com wrote:

...

Sorry, I don't know what this means. I thought Wikidata was already deployed to the English Wikipedia (and possibly other projects as

well).

...

I've posted an announcement with more details on the technical village pump at

http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Wikidata_pha...

...

...

Let me know if anything is still unclear so I can clarify.

Cheers Lydia

Lydia, could you please point me to the discussion on *English Wikipedia* where the community indicated an interest in deploying this software? Infoboxes and sourcing to another website completely outside the control

of

...

English Wikipedia is a rather big issue, and I would expect to see a Request for Comment with at least 200-300 participants.

Risker/Anne

In my opinion, as a casual Wikidata editor and not-so-casual Wikipedia editor, I think the Commons analogy continues to hold up pretty well. Commons exists. We can use it, as a project. We don't *have* to (and indeed don't always, on en:wp, where fair use images are accepted). As I understand it, the same is true with Wikidata -- it will be around, if and when it seems appropriate to use. Of course Commons and Wikidata will both be more useful and more awesome the more projects do use them. But my very non-technical understanding of this deployment is that basically we made the projects able to see that Wikidata exists (correct me if I'm wrong!)

Now as far as I can tell there's a whole lot of work yet to do in order to figure out how exactly one might link to data or produce an infobox and what that might look like -- deployment does not seem to mean ready for prime-time, yet -- and of course the data-building itself is just barely getting started. Best practices for infoboxes does seem like a project-wide RFC to me. But hopefully, when we get to that point, wikidata will be a useful option.

Well, the problem is that we *are* at that point now. Wikidata II *is* intended to be used in infoboxes. We already have edit skirmishes happening all over the project with people adding infoboxes where they aren't wanted, explicitly to take advantage of wikidata, and using wikidata as their excuse to bring it in. Load it up, okay. But don't turn it on until the community discusses whether or not it wants it turned on. It's simply contemptuous of the community to do that. You know as well as I do that as soon as a feature is available, it's used by some people who will fight to the death to keep using it, whether or not it is what the community wants. (See revision deletion which, as soon as it was turned on for administrators on English Wikipedia before the process had been worked out, immediately resulted in tens of thousands of inappropriate revision deletions in its first week. Even now, at least 30% of revision deletions are inappropriate.) You want to keep editors, you need to actually make sure that the changes you are adding are what they want, not what they'll leave over.

I disagree that the Commons analogy holds up. Commons is very active, and easily accessible, and it's pretty obvious how to remove unwanted images/media. It is *not* obvious how to remove wikidata, and it is a site that is extremely not user friendly (I've checked, and even got someone to give me a tour, and it makes wikitext look simple).

There is a rather big difference between images to articles, which aren't essential but are very complementary, and the information contained in an article. We know for a fact that there are many different versions of even supposedly factual data (dates of birth for well-known people, names of battles, Gdansk/Danzig, etc). In many cases, there has been a careful and sometimes very delicate consensus reached by local editors to address these variations. Now we will have infoboxes with one version and the actual article saying something else - and the information in the infobox will be outside of the control of the editors of the article absent going to another site. So now those wars about content will have to go to two sites at once, one of which will be international. So that means users who have never logged into Wikipedia will have the ability to control the content of the project.

Let's not put this in place until the community decides whether or not it wants it.

Risker/Anne

Risker,

You are right that it will undoubtedly get used as soon as it is available, and it is unfortunate that it will presumably get deployed without any agreement having been reached on wiki about how it should be used.

However, when it comes to an area like infoboxes, I think a lot of hardship could be avoided if the community can ultimately come together and adopt a sensible set of guidelines for how wikidata should be used.

For example, one of the reasons Commons is able to work reasonably well within the global context is that every wiki ultimately has the option of ignoring it and uploading locally preferred files instead. I would argue that the use of wikidata in infoboxes should follow much the same principle. Specifically, templates ought to be engineered such that values are obtained from wikidata only when no corresponding value is present locally. So for example, one might have an infobox with a field for birthplace. If enwiki specifies birthplace = Athens, Georgia, then enwiki will be guaranteed to display "Athens, Georgia". And the template should query wikidata only if the field is omitted. So, if birthplace= is left blank, then we might ask wikidata for the answer, and can use the value recorded there, but only so long as no value was filled in locally. That's the kind of behavior that I think makes sense for infoboxes. Decisions about when to rely on local values and when to rely on wikidata are obviously an issue were guidelines are needed. For example, I'd argue that wikidata should never be used to define elements that are likely to be controversial or subject to dispute (e.g. Gdansk/Danzig). It could be a reasonable policy that controversial data values should always be retained using strictly local input. That would limit the potential for controversies over wikidata values from spilling into Wikipedia.

Unfortunately, I suspect we are going to take a while finding our way when it comes to wikidata interactions, though that doesn't necessarily mean we won't ultimately have coherent policies on its use. While obviously a bit late in the game to be starting now, I think many people would welcome a discussion on wiki of what best practices for the use of wikidata ought to look like, and I'm sure your input could be valuable to that discussion.

-Robert Rohde aka Dragons_flight

On 6 April 2013 17:27, Denny Vrandečić denny.vrandecic@wikimedia.de wrote:

I fully agree with Robert and Phoebe in this matter. Wikidata is an option. Requiring first to come up with rules on how to use Wikidata before it is switched on simply won't work, because there is not sufficient interest and experience for this discussion.

I'm very concerned that you would think that. In the real world, where attracting and retaining talented human beings is a key objective, testing of not-yet-ready-for-prime-time software (which this clearly is) is carried out in test environments and with teams who voluntarily agree to participate. The PDSA (plan-do-study-adjust) cycle is critically important; major changes are tested on smaller groups and constantly refined until they are ready to be applied effectively to the larger population. You still have a long, long way to go before this is ready for one of the biggest websites in the world.

And it is entirely normal that processes are developed in advance. English Wikipedia has done so for many other technical changes that have taken place over time, including the addition of revision-deletion/suppression, the introduction of the Vector skin, the enabling of pending changes. In fact, I would go so far as to say that technical changes that have any significant effect on content or the manner in which members of the community carry out their responsibilities are *normally* discussed and planned for in advance. This software represents not only a major change in technology, but a major change in the philosophy of the project, and that by itself requires some very significant discussion.

Please keep in mind that this is software that will affect every single editor of the project, not just a few who specialise in particular small niches. Someone pointed out that there was no community consultation about Scribunto/Lua, but that affects less than 1% of all active English Wikipedians (those who write templates), and many of them were either involved in the discussion or decided to stop working in the area.

Or, put differently, the Wikidata proposal has been published nearly two years ago. We have communicated on all channels for more than one year. I can hardly think of any technical enhancement of Wikipedia - ever - which was communicated as strongly beforehand as Wikidata. If, in that time, the community has not managed to discuss the topic, it might be because such changes only get discussed effectively after they occur.

"All channels" isn't really correct, although I can respect how difficult it is to try to find a way to communicate effectively with the English Wikipedia community. There is no centralized discussion point anywhere on the project. The technical village pump is almost completely populated by editors who have a strong interest in the technical side of things; others only drop in for a short period if they have a technical problem. Administrator noticeboards are watched by a larger percentage of the community, but discussions about changes like this would normally be moved off before any useful comment would be made.

I do not recall ever reading about Wikidata on Wiki-en-L (the English Wikipedia mailing list), and only rarely on Wikimedia-L (mainly to invite people to meetings on IRC, but less than 5% of English Wikipedians use IRC). Indeed, almost everything I know about Wikidata comes from this mailing list (and much of what has been written is well beyond my comprehension. Nonetheless, I recognize that trying to find a way to effectively communicate with the English Wikipedia community is a major challenge even for those who are intimately familiar with the project, and would be doubly so for those who are not regular participants.

I base this statement on having studied previous introductions of new technical features to the Wikipedias (check for that my paper with Mathias Schindler), like the category system or parserfunctions.

Since Wikidata phase 2 is actually a less intrusive change than phase 1, and based on the effectiveness of the discussion about phase 2 on the English Wikipedia so far, I think that a post-deployment discussion is the right way to go.

In what way is this less intrusive? Phase 1 changed the links to other projects beside articles, a task that was almost completely done by bots, and did not in any way affect the ability to edit or to modify the content of the articles. Phase 2 is intended to directly affect content and the manner in which it is edited.

As well, phase 2 (dependent on implementation) requires that an editor go to a different website to modify the information on an article. There is no warning to the editor that they are leaving Wikipedia. And with the challenges that are about to happen with Firefox (the browser that is possibly the most commonly used by Wikipedians), we know that SUL is probably not going to work properly. Editors thinking they are logged in to English Wikipedia will find themselves on a strange site, not logged in, with a completely foreign editing interface. This is not the way to attract new editors, nor is it the way to keep existing ones.

Also, a very important consideration is raised by Phoebe: Wikidata is in its current form still in its infancy, and for a well developed project like the English Wikipedia this means that the actual usage (and effect) is expected to be minimal in the current stage. The deployment of phase 2 this week would merely be a start for an organic co-evolution of Wikidata and the Wikipedias in the months and years to come.

Yes, it's in its infancy. It needs to be put through its paces and problems identified and resolved. You already have a fairly significant number of projects willing to do that. Keep working with them. Why is there this insistence on putting software that is not ready for use onto projects that haven't indicated any interest in using immature software?

But this can only happen 'in the wild', as a priori debates about the possible usages of such features will remain not only too speculative, but also highly undemocratic due to the minimal engagement of the community in advance.

This is possibly the most disturbing thing I have ever read on a Wikimedia mailing list. You want to put software onto the most developed project in the entire Wikimedia community without any indication that the project is supportive of what it is intended to do, knowing that it is not actually ready for use at this point, knowing that its functions are directly in conflict with one of the project's known priorities of attracting new editors and retaining existing ones....and then you have the nerve to say that discussing how to use it would be "undemocratic"? The minimal engagement of the community in advance is the reason that deploying this software now is undemocratic.

The workflow is counterintutive, and all of the examples provided to date have shown that this is not ready for release to an extremely large, highly active project; in fact, I question why it is being deployed any further right now to any projects outside of those that have clearly expressed an interest. You are doing the right thing by continuing to work with projects of various sizes that have voluntarily agreed to participate in the ongoing development of Wikidata. There are already several users from English Wikipedia who are active on Wikidata. We can encourage more users to participate there and on the test wikis where it is enabled, to actually test it and provide the feedback that you need to keep improving the product.

As I've indicated very early in this thread, Phase 2 affects an area of English Wikipedia that is already under considerable dispute (i.e., infoboxes); requests for comment (RFCs) were already being drafted before this deployment was being announced. There is a pretty good chance that issues related to infoboxes will wind up being brought before the Arbitration Committee within the next few months. English Wikipedia is not the place to test this software now. That's what test wikis are for, and what voluntary project participation is for.

Best,

Risker

On 8 April 2013 09:20, Brad Jorsch bjorsch@wikimedia.org wrote:

On Apr 8, 2013 12:11 AM, "Risker" risker.wp@gmail.com wrote:

...

As I've indicated very early in this thread, Phase 2 affects an area of English Wikipedia that is already under considerable dispute (i.e., infoboxes); requests for comment (RFCs) were already being drafted before this deployment was being announced. There is a pretty good chance that issues related to infoboxes will wind up being brought before the Arbitration Committee within the next few months. English Wikipedia is

not

...

the place to test this software now. That's what test wikis are for, and what voluntary project participation is for.

Aren't the controversial issues along the lines of "who decides whether any infobox should be used on an article" and possibly "which fields should an infobox contain"? Both of those issues seem entirely unrelated to whether or not the data for the fields that are present in the infobox may be optionally fetched from wikidata.

On the surface, they appear unrelated.

I do not think it is particularly obvious outside of our project the way that Wikidata is being "weaponized" as the reason for attempting to force changes in local consensus about infoboxes (their existence and content) with respect to specific article categories or even individual articles. I am certain that such behaviours are contrary to the expectations of those leading Wikidata; nonetheless, when I've drilled down on several of the recent confrontations about infoboxes, at their core it has been about making sure that there is an infobox in existence and in a format that will be useable for Wikidata; it is not about "improving" the article or making it more accessible to readers, or even about internal consistency.

Risker/Anne

On 8 April 2013 17:51, Brad Jorsch bjorsch@wikimedia.org wrote:

Personally, I don't consider that people making spurious arguments based on the existence of wikidata is a problem with the planned wikidata phase 2 deployment.

Indeed. This is sheer bikeshedding.

- d.

On Mon, Apr 8, 2013 at 7:59 PM, Risker risker.wp@gmail.com wrote:

It's disturbing that even at the same time as the engineering and operations departments are working so hard to professionalize their work, to bring themselves up to industry standards, to properly staff themselves with people who understand not just the technical side, but also the content side - that there remains this cowboy attitude toward applying poorly developed software onto huge sites knowing full well that the software create significant community disruption. This isn't a little backwater website anymore, and it should never be the subject of a major test without the active engagement of those who are going to be the test subjects.

Wiki design 101 is that nobody gets sent to another page/website/etc to edit content on the Wikipedia. (Even clicking on an image that is held on Commons takes people to a Wikipedia page for the image, and then gives them the choice to go to Commons.) This software is not ready for deployment; everyone here knows it. This is now just pride taking the place of common sense. (And no, David, it's not bikeshedding.)

Figure out why the content itself is being affected, instead of creating a new namespace that will hold all this data: wikidata, authority control data, H-cards, V-cards, and all the other miscellaneous stuff that has been applied to articles.

This is not a technical problem to be solved. It is at its core a philosophical matter to be grappled with, project by project.

Learn some lessons from the folks down the hall in Fundraising - who have figured out how to fully fund all of these projects with the minimal amount of disruption to the content and the editorial process. Figure out how to do that, and you'll have a winner.

I understand you're upset but please also understand the other side. We've put a lot of work into making it possible for each Wikipedia to decide how they want to make use of the data for example. The existing system is built to exactly not disrupt anything that exists until the local community decides to make changes. I understand that making this decision is difficult in a large project as enwp but it's not like we're replacing infoboxes that exist automatically for example. We've from the beginning of the project started with letting people use early stages of the project exactly because we needed the feedback to shape the tool in a way that will serve Wikipedia - and we'd like this at each step of the way because otherwise we're bound to build something that is in one form or another not useful for you. We've always started with test systems and smaller Wikipedias (Go them!) but that only goes so far unfortunately.

Cheers Lydia

-- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata

Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

(Volunteer with no Wikidata association apart from a couple of edits.)

Risker, while I see your point, and I agree that the deployment cycle is maybe just a little too rapid (give the editors some time to update their help pages ;) ), then your last mail is both unfair and untrue.

Most of all, there is nothing forcing you to use the new syntax elements. If you don't want them, revert edits which add them, and explain this to editors that make them. This isn't a technical issue.

On Mon, 08 Apr 2013 19:59:07 +0200, Risker risker.wp@gmail.com wrote:

It's disturbing that even at the same time as the engineering and operations departments are working so hard to professionalize their work, to bring themselves up to industry standards, to properly staff themselves with people who understand not just the technical side, but also the content side - that there remains this cowboy attitude toward applying poorly developed software onto huge sites knowing full well that the software create significant community disruption. This isn't a little backwater website anymore, and it should never be the subject of a major test without the active engagement of those who are going to be the test subjects.

In my experience the Wikidata team has been extremely professional and amazingly productive, both in the quality and quantity of their creations. I was honestly surprised that it's possible to get something Wikimedia-related done that quickly. Lydia and everyone - great job :)

I see no cowboy attitude here. As pointed out, this was already tested on multiple wikis, some only a little smaller than enwiki. While the software is not entirely complete yet, this seems mostly by design (phase III, anyone?). It certainly works, and it's certainly good enough for wider deployment. There are some important bugs to iron out (https://bugzilla.wikimedia.org/show_bug.cgi?id=44874 comes to mind), but they're not really blockers, and I think (and hope!) they're being worked on.

Wiki design 101 is that nobody gets sent to another page/website/etc to edit content on the Wikipedia. (Even clicking on an image that is held on Commons takes people to a Wikipedia page for the image, and then gives them the choice to go to Commons.)

But you do need to go to Commons to, say, upload a different version of it. Wiki editing 101 for you.

And I think this was being worked on for language links, anyway. Lydia, is there a bug for that? ;)

On 8 April 2013 19:46, Bartosz Dziewoński matma.rex@gmail.com wrote:

Risker, while I see your point, and I agree that the deployment cycle is maybe just a little too rapid (give the editors some time to update their help pages ;) ), then your last mail is both unfair and untrue.

Risker is claiming technical issues in bad faith, because she is up for the next Arbcom elections in December - and fomenting discord now is a good start to building up a base for that election. Hence raising total non-issues as if they are issues, and attempting to spread a cloud of FUD.

- d.

On Mon, Apr 8, 2013 at 10:59 AM, Risker risker.wp@gmail.com wrote:

On 8 April 2013 12:51, Brad Jorsch bjorsch@wikimedia.org wrote:

...

On Mon, Apr 8, 2013 at 12:16 PM, Risker risker.wp@gmail.com wrote:

...

I do not think it is particularly obvious outside of our project the

way

...

...

that Wikidata is being "weaponized" as the reason for attempting to

force

...

...

changes in local consensus about infoboxes (their existence and

content)

...

...

with respect to specific article categories or even individual

articles.

...

It's not obvious within the project either, at least for someone like me who hasn't been following the endless arguments over whether some WikiProject should be able to decide not to use infoboxes on "their" articles and whether they're ganging up to prevent any local consensus to use infoboxes on "their" articles, etc, etc, etc.

Personally, I don't consider that people making spurious arguments based on the existence of wikidata is a problem with the planned wikidata phase 2 deployment.

Why do you think those arguments are spurious? Just because you don't agree with them doesn't make them spurious. Those articles belong a lot more to the editors of each of the Wikipedias than they do to Wikidata, or Wikimedia, that's for certain.

Not agreeing with the arguments of some editors *also* doesn't mean the entire engineering and operators department is "doing it wrong", or that the Wikidata project (which is not developed by WMF, incidentally, and is having its own interesting discussions *among its own community* as we speak) somehow is not capable of also debating these questions.

I do not agree with your arguments, Risker. I think Wikidata is great and I am happy it has been deployed (or will be soon). I think it will enable lots and lots of super cool things in the years to come, and having over the years lived through the deployments of commons, categories, new skins and who knows what else I am also confident, along with Denny, that we will figure it out in the wild as we go.

That viewpoint doesn't make me a bad Wikipedian, and it doesn't mean I'm not willing to hear you and others who disagree out (and I'm perfectly willing to learn about the infobox debates, which are actually new to me -- somehow in 10 years of editing I've managed to avoid this hotbed of disagreement). But do please bear in mind that in your messages you are telling *the entire* technical list, including all the paid development staff and the longtime technical volunteers, which includes pretty much everyone who has written MediaWiki over the years, that they don't know how wiki development works. In my opinion that's pretty patronizing, and is not helping your argument -- which, as far as I can tell, is that Wikidata phase II shouldn't be enabled on en:wp except after a community-wide RFC, correct? As far as that goes, since you are so strongly arguing for the autonomy of en:wp, I think the ball's in the en:wp court; an en:wp editor should be the one to organize an RFC. If the results skew strongly to one side or another, the WMF has listened to such things in the past. Personally I don't see the need for an RFC at this point in time, but I certainly don't begrudge anyone else the right to organize one, and I will happily vote accordingly.

-- phoebe

phoebe ayers wrote:

Not agreeing with the arguments of some editors *also* doesn't mean the entire engineering and operators department is "doing it wrong", or that the Wikidata project (which is not developed by WMF, incidentally, and is having its own interesting discussions *among its own community* as we speak) somehow is not capable of also debating these questions.

I do not agree with your arguments, Risker. I think Wikidata is great and I am happy it has been deployed (or will be soon). I think it will enable lots and lots of super cool things in the years to come, and having over the years lived through the deployments of commons, categories, new skins and who knows what else I am also confident, along with Denny, that we will figure it out in the wild as we go.

Hi Phoebe.

The infobox issues are tangential. Wikidata has _very real_ workflow issues: https://en.wikipedia.org/wiki/Wikipedia:Wikidata/Workflow. The current Wikidata implementation is incredibly anti-wiki. I think reading that page will clearly demonstrate this.

I agree that Wikidata is neat and I look forward to it to being available on Wikimedia wikis. However, I think it would be terribly (and painfully) premature to deploy it to a huge production wiki like the English Wikipedia in its current state.

I can understand the argument for allowing the workflow to naturally develop and evolve, but there are gaping issues right now, particularly the lack of a defined syntax for even using Wikidata data, that I don't believe should be overlooked or brushed aside.

I really don't understand what seems to be like a rush to deploy this on every Wikipedia.

MZMcBride

Risker,

I find myself unconvinced by your argumentation as I perceive it as inconsistent.

On the one hand, you suggest that before we enable the option to access data from Wikidata using either Lua or a parser function should be discussed and decided by the community beforehand - the same community, that has been informed since mid 2011 that this change is coming. You suppose that the community can actually come together and decide this globally.

On the other hand, you are not trusting the community with the use of the same feature. You say they would "weaponize" the feature, that the community will be unable to adapt to the new feature, and that it needs to discuss first how to use it, and for deployment to wait a few months (I do not fully understand why you assume that a few months will be enough to sort things out). You seem to assume that a wiki as large and active as the English Wikipedia is not resilient enough to absorb the rather minor technical change we are introducing.

It is, technically, a minor change. Socially it can lead to bigger changes -- but I found it hard to believe that anyone can predict the actual effect on the English Wikipedia community. This has to be seen and experienced, and I, for one, trust the English Wikipedia community to be as awesome as always, and to absorb and use this new features in ways no one has even imagined yet.

Also, to come back to the issue of deploying unmature code to Wikipedia: this is absolutely intentional. You say you want a mature system to be deployed on Wikipedia, not one in its infancy. I would ask you to reconsider that wish. I have been there: we have developed Semantic MediaWiki (SMW), with the intention to push it to the Wikipedias, and the system became highly usable and extremely helpful. Be it NASA, Yu-Gi-Oh fans, or the Wikimedia Foundation, SMW has found hundreds of uses and tens of thousands of users. And SMW got better and better for these use case -- to the expense of getting less and less probable to be deployed on the Wikipedias.

I would prefer to avoid this mistake a second time. Deploy early, deploy often - and listen closely to the feedback of the users and analyse the actual usage numbers. MZMcBride raises a number of very real issues that need to be tackled soon (I disagree that they are blockers, but I agree that they are important, and we are working on them). This was so far quite successful on Wikidata itself, and also for what we have deployed to the Wikipedias so far.

In all seriousness: thank you for your concerns. Having read carefully, I find that I do not share them and that I see not sufficient reason to delay deployment out of the points you mention.

A few minor comments inline in your mail below.

2013/4/8 Risker risker.wp@gmail.com

On 6 April 2013 17:27, Denny Vrandečić denny.vrandecic@wikimedia.de wrote:

...

Or, put differently, the Wikidata proposal has been published nearly two years ago. We have communicated on all channels for more than one year. I can hardly think of any technical enhancement of Wikipedia - ever - which was communicated as strongly beforehand as Wikidata. If, in that time,

the

...

community has not managed to discuss the topic, it might be because such changes only get discussed effectively after they occur.

"All channels" isn't really correct, although I can respect how difficult it is to try to find a way to communicate effectively with the English Wikipedia community.

I do not recall ever reading about Wikidata on Wiki-en-L (the English Wikipedia mailing list), and only rarely on Wikimedia-L (mainly to invite people to meetings on IRC, but less than 5% of English Wikipedians use IRC).

We have been on Signpost several times, we have been on the village pump. This is considered sufficient on the other Wikipedias.

A search over the mailing list archives shows that both lists you mentioned had discussions about Wikidata. They contained links to pretty comprehensive pages on Meta. There are pages inside of the English Wikipedia discussing Wikidata. Furthermore, we had reached out in many talks, e.g. at the last two Wikimanias, but also in smaller local events, and always supported Wikipedians to talk about it in their local communities.

Since you are saying that our communication has not been sufficient, I would be very glad to hear which channels we have missed so that we can add them in the future.

...

Since Wikidata phase 2 is actually a less intrusive change than phase 1, and based on the effectiveness of the discussion about phase 2 on the English Wikipedia so far, I think that a post-deployment discussion is

the

...

right way to go.

In what way is this less intrusive? Phase 1 changed the links to other projects beside articles, a task that was almost completely done by bots, and did not in any way affect the ability to edit or to modify the content of the articles. Phase 2 is intended to directly affect content and the manner in which it is edited.

It is less intrusive on in the sense that simply nothing happens until an editor consciously decides to do something, i.e. use the new functionality.

As well, phase 2 (dependent on implementation) requires that an editor go to a different website to modify the information on an article. There is no warning to the editor that they are leaving Wikipedia. And with the challenges that are about to happen with Firefox (the browser that is possibly the most commonly used by Wikipedians), we know that SUL is probably not going to work properly. Editors thinking they are logged in to English Wikipedia will find themselves on a strange site, not logged in, with a completely foreign editing interface. This is not the way to attract new editors, nor is it the way to keep existing ones.

I would like on which you base this last sentence. Our user feedback so far has more often used the term "addictive" than "strange". Also the numbers - about 7000 active editors, more than 100,000 edits by human editors - speak a different language. But if you have anything to support your statement, I would be extremely interested in them.

...

Also, a very important consideration is raised by Phoebe: Wikidata is in its current form still in its infancy, and for a well developed project like the English Wikipedia this means that the actual usage (and effect)

is

...

expected to be minimal in the current stage. The deployment of phase 2

this

...

week would merely be a start for an organic co-evolution of Wikidata and the Wikipedias in the months and years to come.

Yes, it's in its infancy. It needs to be put through its paces and problems identified and resolved. You already have a fairly significant number of projects willing to do that. Keep working with them. Why is there this insistence on putting software that is not ready for use onto projects that haven't indicated any interest in using immature software?

You seem to assume that the eleven Wikipedias currently using Wikidata phase 2 have asked us for a deployment. This was not the case (besides on Hungarian). They were informed that they would be the first Wikipedias to experience the roll out. This lead to several conversations, just as on the English Wikipedia as well.

But this can only happen 'in the wild', as a priori debates about the

...

possible usages of such features will remain not only too speculative,

but

...

also highly undemocratic due to the minimal engagement of the community

in

...

advance.

This is possibly the most disturbing thing I have ever read on a Wikimedia mailing list. You want to put software onto the most developed project in the entire Wikimedia community without any indication that the project is supportive of what it is intended to do, knowing that it is not actually ready for use at this point, knowing that its functions are directly in conflict with one of the project's known priorities of attracting new editors and retaining existing ones....and then you have the nerve to say that discussing how to use it would be "undemocratic"? The minimal engagement of the community in advance is the reason that deploying this software now is undemocratic.

I am sorry to have disturbed you so deeply, but I remain with my statement: based on the small engagement in this discussion, compared to the size of the English Wikipedia community, I regard this discussion as undemocratic, i.e. not representative of the editor body as a whole.

Do not misunderstand me: I am not claiming that the decision to switch on Wikidata has been democratic, or actually indeed that technical decisions in the Wikimedia Movement are in general achieved through democratic processes. I am merely noticing that I do not consider the current discussion to be any more democratic than that - I do not think that the community is represented here any better (or worse) than in the many channels we have used for communication before.

Cheers, Denny

Thank you, also for the explanation. I am glad we could defuse this. On Apr 10, 2013 7:07 AM, "Risker" risker.wp@gmail.com wrote:

On 9 April 2013 12:15, Denny Vrandečić denny.vrandecic@wikimedia.de wrote:

...

Risker,

I find myself unconvinced by your argumentation as I perceive it as inconsistent.

On the one hand, you suggest that before we enable the option to access data from Wikidata using either Lua or a parser function should be discussed and decided by the community beforehand - the same community, that has been informed since mid 2011 that this change is coming. You suppose that the community can actually come together and decide this globally.

...

On the other hand, you are not trusting the community with the use of the same feature. You say they would "weaponize" the feature, that the community will be unable to adapt to the new feature, and that it needs

to

...

discuss first how to use it, and for deployment to wait a few months (I

do

...

not fully understand why you assume that a few months will be enough to sort things out). You seem to assume that a wiki as large and active as

the

...

English Wikipedia is not resilient enough to absorb the rather minor technical change we are introducing.

It is, technically, a minor change. Socially it can lead to bigger

changes

...

-- but I found it hard to believe that anyone can predict the actual

effect

...

on the English Wikipedia community. This has to be seen and experienced, and I, for one, trust the English Wikipedia community to be as awesome as always, and to absorb and use this new features in ways no one has even imagined yet.

I'll just quickly point out the dichotomy in what you're saying here: first you say that you doubt the project can come together and make a global decision, and then you say that it is resilient enough to ... make a global decision.

This is, from the technical perspective, a small change. It is a major philosophical change: actively preventing editors from making content changes on the home project. It's also a contradictory change: it makes it more complex to edit content, but at the same time major investment of developer time and talent is being invested into making the editing process simpler and more intuitive through Visual Editor (and ultimately projects like Flow and Echo). Infoboxes (and ultimately lists) are an integral part of the content of Wikipedias; making text easier to edit and other integral content more difficult to edit suggests that, at minimum, there are some fairly significant philosophical and practical conflicts within the overall platform development. From the community perspective, a simpler editing interface has been a community priority for almost as long as Wikipedia has been in existence. It is good to see the WMF putting its (much improved) financial resources into a project that has been near the top of the editorial wish list for so long, and that investment has very good prospects of paying off with both editor retention and editor recruitment. Unless I've missed something, that's still a key metric for measuring success. I agree that Wikidata is "cool" (to use others' expressions), but I've not seen anything indicating it is attracting new editors; instead it seems to be drawing in editors from other WMF projects, who are now doing less editing in their "home" projects. I'd hope that is a short-term change as Wikidata develops as a project.

I suppose what I am saying here is that Wikidata doesn't seem to be working within the articulated "master vision" of the platform (which focuses on simplifying the editorial process), and absent the ability to edit the wikidata on the project where it appears, I don't see how it's going to get there. It doesn't make Wikidata any less of a great idea, and I still think it has potential for new projects to build content. I'm just having a hard time seeing where it's fitting with everything else that is going on, if data can't be changed by using "real words" directly on the wikipedia project.

What I am looking for is a good, plain-English explanation of how these two different directions in software development are not divergent, and how they are intended to co-exist without one adversely affecting the effectiveness of the other.

...

Since you are saying that our communication has not been sufficient, I would be very glad to hear which channels we have missed so that we can

add

...

them in the future.

...

...

Since Wikidata phase 2 is actually a less intrusive change than phase

1,

...

...

and based on the effectiveness of the discussion about phase 2 on the English Wikipedia so far, I think that a post-deployment discussion

is

...

...

the

...

right way to go.

In what way is this less intrusive? Phase 1 changed the links to other projects beside articles, a task that was almost completely done by

bots,

...

...

and did not in any way affect the ability to edit or to modify the

content

...

of the articles. Phase 2 is intended to directly affect content and the manner in which it is edited.

It is less intrusive on in the sense that simply nothing happens until an editor consciously decides to do something, i.e. use the new

functionality.

...

Ah, I see. This may be different for less mature or smaller wikis, but editors on English Wikipedia paid almost no attention to interwiki links; it was something bots (or a tiny number of editors) did, and was just another one of those contentless edits that made an article pop back up in their watchlist. It did nothing to affect the editing process of the article, and any random passerby could still edit every aspect of the content, so wikidata taking over that task is not perceived as intrusive.

Phase 2 affects the ability to edit the content of the article, the moment it is applied by one editor, and it can only be returned to its "natural" editing state by an experienced editor who will know how to revert the infobox back to its old format if desired. And yes, from the perspective of editors, infoboxes are part of the content of the article. The technology change may be minor, but its use means changing the core "anyone can edit" philosophy that has created, and constantly renewed and developed, the wikipedia projects.

...

You seem to assume that the eleven Wikipedias currently using Wikidata phase 2 have asked us for a deployment. This was not the case (besides on Hungarian). They were informed that they would be the first Wikipedias to experience the roll out. This lead to several conversations, just as on

the

...

English Wikipedia as well.

You are correct, I had made that assumption. I remembered reading about the discussions on hewiki, and that huwiki had clearly expressed interest, and assumed that this was a consensual decision on the part of all involved wikipedias. Thank you for correcting me.

...

I am sorry to have disturbed you so deeply, but I remain with my

statement:

...

based on the small engagement in this discussion, compared to the size of the English Wikipedia community, I regard this discussion as

undemocratic,

...

i.e. not representative of the editor body as a whole.

Do not misunderstand me: I am not claiming that the decision to switch on Wikidata has been democratic, or actually indeed that technical decisions in the Wikimedia Movement are in general achieved through democratic processes. I am merely noticing that I do not consider the current discussion to be any more democratic than that - I do not think that the community is represented here any better (or worse) than in the many channels we have used for communication before.

As I have explained to Danny more personally, this appears to have been a miscommunication by word selection. In common English usage, the term "undemocratic" is a charged political term associated with dictators and the revocation of rights like the right to liberty or the right to free speech. On off-line discussion, as well as in reading Denny's further comments here, it became apparent that he meant "not democratic". I entirely agree that software deployment is not democratic, on WMF or any other projects, nor would I expect it to be. I apologize to Denny for my being too much of a word wonk, and perhaps spending too much time reading political history.

Risker/Anne _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Risker wrote:

Lydia, could you please point me to the discussion on *English Wikipedia* where the community indicated an interest in deploying this software? Infoboxes and sourcing to another website completely outside the control of English Wikipedia is a rather big issue, and I would expect to see a Request for Comment with at least 200-300 participants.

I think the issue we're seeing here is that changes, particularly large changes, often aren't socialized well.

It probably doesn't help to target the English Wikipedia first, of course, given that it's often annoyingly exceptional. Wikidata seems like a large enough change that I agree that a bit more socialization might be nice. There are over 700 wikis on which to possibly deploy Wikidata, in theory.

MZMcBride

MZMcBride wrote:

I think the issue we're seeing here is that changes, particularly large changes, often aren't socialized well.

I mention socialization of features as I'm not sure all of the context is apparent here. There are brooding factions on the English Wikipedia over infoboxes, apparently. I was reading about them yesterday. Risker, as a member of the English Wikipedia Arbitration Committee, will likely end up being tasked with helping sort out this mess. Wikidata may be exacerbating the general infobox issue, which is why socialization of a big new software feature like this is so important.

On any wiki, we often want to avoid inorganic growth/evolution. New features and developments are great, but over time. This is why most wiki communities oppose, for example, bot-created short articles (stubs).

From reading the technical village pump and visiting Wikidata, I don't

think the workflows are clearly established yet. Certainly not to the point that I'd want this in production on a huge wiki like the English Wikipedia. My strong recommendation would be to give the smaller Wikipedias some time to see how this works before going full-throttle. Perhaps one of the Wikimedia Foundation site architects can weigh in here.

MZMcBride

In hewiki we had a discussion in village pump before phase II deployment and there is a simple bureaucratic policy for converting templates to use the new {{#property}} feature: a discussion in "Wikipedia:Village pump/templates" for each template conversion before actually adding {{#property}} for it. (this "village pump for templates" was already exist to eliminate adding unnecessary extra parameters that were added without discussion) This way we can check that each conversion is both technically ok, use the correct properties from wikidata, and doesn't add unnecessary parameters.

We don't use yet the new features - as in the real world cases it isn't just {{#property}} and to enjoy the powerful features of wikidata we must use WikibaseClient Lua api, but we are in final phase of testing {{Taxobox}} (with no parameters at all. really cool!)

I would like to thank to Lydia and wikidata team - you are doing a great job.

On Sat, Apr 6, 2013 at 6:40 PM, legoktm legoktm.wikipedia@gmail.com wrote:

On Sat, Apr 6, 2013 at 10:28 AM, MZMcBride z@mzmcbride.com wrote:

...

Risker wrote:

...

Lydia, could you please point me to the discussion on *English

Wikipedia*

...

...

where the community indicated an interest in deploying this software? Infoboxes and sourcing to another website completely outside the control of English Wikipedia is a rather big issue, and I would expect to see a Request for Comment with at least 200-300 participants.

I think the issue we're seeing here is that changes, particularly large changes, often aren't socialized well.

It probably doesn't help to target the English Wikipedia first, of

course,

...

given that it's often annoyingly exceptional. Wikidata seems like a large enough change that I agree that a bit more socialization might be nice. There are over 700 wikis on which to possibly deploy Wikidata, in theory.

Wikidata phase 2 is already live on 11 different wikis. ( http://blog.wikimedia.de/2013/03/27/you-can-have-all-the-data/)

...

MZMcBride

-- Legoktm

http://enwp.org/User:Legoktm

...

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

By the way, it would be lovely not to call communication like nationalization... sometimes I see people coming to communities saying they're socializing something and it feels weird. ;-) (Especially as it's false good news.)

https://en.wiktionary.org/wiki/socialize (transitive) To take into collective or governmental ownership

Nemo

Sumana Harihareswara, 08/04/2013 14:36:

Nemo, I have sympathy for you here -- it took a while for me to get used to the use of "socialize" in the way the Wikimedia communities use it.

Not communities, the WMF.

I think socializing is more than just "communication" implies, though; "communication" sometimes implies a simple broadcast, where "socializing" implies:

• this is a process, not a one-time global message
• presenting the reasons for a change, not just saying it's going to happen
• thinking from the perspective of the people affected and asking them

relevant questions

• learning new facts and perspectives from the affected communities and

using them to modify plans

• negotiation

  So I am resigned to using "socialization" because I don't think there's

a better succinct phrase for this.

"Negotiation" would be good enough. "Discussion" if you don't have an initial opinion. However those mostly decided things, so "communication" is just fine; or look for whatever word governments use to broadcast the reasons for their decrees, I don't know them in English but there surely are many. At any rate, don't tell anyone you're "socialising" something or them, it's just ridiculous.

Nemo

I think as long as it's pretty obvious from the context that Wikimedia is not establishing a sovereign socialist nation, we should be fine with the current terminology.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com

On Mon, Apr 8, 2013 at 7:48 PM, MZMcBride z@mzmcbride.com wrote:

Sumana Harihareswara wrote:

...

On 04/06/2013 09:16 PM, Federico Leva (Nemo) wrote:

...

By the way, it would be lovely not to call communication like nationalization... sometimes I see people coming to communities saying they're socializing something and it feels weird. ;-) (Especially as it's false good news.)

https://en.wiktionary.org/wiki/socialize (transitive) To take into collective or governmental ownership

Nemo

Nemo, I have sympathy for you here -- it took a while for me to get used to the use of "socialize" in the way the Wikimedia communities use it. [...]

I don't have much sympathy. Looking at https://en.wiktionary.org/wiki/socialization:

---

1. The process of learning one's culture

https://en.wiktionary.org/wiki/culture and how to live within it.

2. The act of interacting with others, of being social.

3. Taking under government control as implementing socialism.

---

Given the precedence here (the definition having to do with governments and socialism is third), I don't think it's very reasonable to call the usage within Wikimedia wrong or even noteworthy.

My local dictionary (New Oxford American Dictionary) also lists the socialism definition third.

So, yes, if you choose to ignore the primary and secondary definitions, the tertiary definition isn't a great fit. This is why it's the tertiary definition, of course.

MZMcBride

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

2013/4/8 Risker risker.wp@gmail.com:

Eran raises a key point. On his project, there was a significant discussion prior to the deployment. Hewiki has voluntarily, as a community, decided to participate in the early development of a tool. This is a very good thing, and one that reflects well on the hewiki community.

Thanks for the compliment. A bit more detail: I heard about Wikidata quite early on (November 2011), because I follow mailing lists and conferences and I try to learn about new developments. As soon as I could, I asked Lydia if the hewiki can get it early. Lydia and Denny agreed, but, very interestingly, demanded to have detailed discussion on the wiki and get community. This was a very smart move on their behalf - I suppose that they learned from earlier bad communication blunders, so big kudos to them for that.

I tested Wikidata early and fixed a few tiny bugs, and when I thought that it's ready to show to the community, I announced it in the village pump. I was prepared to answer questions, and when I didn't know what to say, I asked Lydia, who stepped in and answered everything in detail. After the questions phase ended, there was ZERO objection to joining early testing of Wikidata. Zero objection to a change is a very rare thing for hewiki :)

Technical problems *were* uncovered after the deployment. Quite a lot of problems, actually. But the community was well prepared, and reported them in a mostly constructive way. There was general understanding that Wikidata migration will happen anyway, and that it's better to suffer through a few bugs than to just grumble.

English projects, particularly Wikipedia, do not have that same shared cultural, geographic or historical cohesion; as the lingua franca of more than a dozen countries, and the second language for thousands of other editors, even localized variations in usage can be a stumbling block. Add into that the fact that English Wikipedia has such a large editing community, and that there is no effective centralized communication process, and the ability of the community to develop a consensus opinion on any major topic is exponentially more difficult than on many other projects.

I find SiteNotice and the notification area above the Watchlist very simple and effective communication tools. The latter is used now for the PageProtector RFC now, for example.

Now that I think of it, I don't recall that it was used for announcements about Wikidata (although I might be wrong). It probably should have. On the other hand, it might have created stop energy without very good preparation.

-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬