On Sat, Apr 6, 2013 at 1:00 AM, MZMcBride <z(a)mzmcbride.com> wrote: I've posted an announcement with more details on the technical village pump at http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Wikidata_ph… 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 &lt;risker.wp(a)gmail.com&gt; wrote: 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 &lt;phoebe.wiki(a)gmail.com&gt; wrote: 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ć &lt;denny.vrandecic(a)wikimedia.de&gt; wrote: 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. "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. 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. 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? 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 &lt;bjorsch(a)wikimedia.org&gt; wrote: 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 &lt;bjorsch(a)wikimedia.org&gt; wrote: Indeed. This is sheer bikeshedding. - d.

On Mon, Apr 8, 2013 at 7:59 PM, Risker &lt;risker.wp(a)gmail.com&gt; wrote: 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 &lt;risker.wp(a)gmail.com&gt; wrote: 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. 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? ;) -- Matma Rex

On 8 April 2013 19:46, Bartosz Dziewoński &lt;matma.rex(a)gmail.com&gt; wrote: 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 &lt;risker.wp(a)gmail.com&gt; 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. 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 -- * I use this address for lists; send personal messages to phoebe.ayers <at> gmail.com * On Mon, Apr 8, 2013 at 10:59 AM, Risker &lt;risker.wp(a)gmail.com&gt; 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. > > Risker/Anne > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- * I use this address for lists; send personal messages to phoebe.ayers <at> gmail.com *

phoebe ayers wrote: 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 &lt;risker.wp(a)gmail.com&gt; 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. 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. 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. 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. 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 -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

Thank you, also for the explanation. I am glad we could defuse this. On Apr 10, 2013 7:07 AM, "Risker" &lt;risker.wp(a)gmail.com&gt; wrote:

Risker wrote: 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 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). 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 &lt;legoktm.wikipedia(a)gmail.com&gt; 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

Sumana Harihareswara, 08/04/2013 14:36: Not communities, the WMF. "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(a)gmail.com On Mon, Apr 8, 2013 at 7:48 PM, MZMcBride &lt;z(a)mzmcbride.com&gt; wrote:

2013/4/8 Risker &lt;risker.wp(a)gmail.com&gt;om>: 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. 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‬