Hi guys, I understand your objections. Surely privacy is a key here. We should make "social" our way, taking in account various aspects of privacy and commerce... The goal definitely is rising the the number of editors... we should do this through all possible ways... as someone wrote here the only question is _how many resources_ (money etc.) is WMF wanting to invest into editor retention... Kozuch 2012/4/17 Nathan <nawrich(a)gmail.com>om>:

On Tue, Apr 17, 2012 at 12:13 PM, Thomas Morton <morton.thomas(a)googlemail.com> wrote: Yes. No. Aiming for quality, would only reduce the number of editors. Remember: "the free encyclopedia that anyone can edit." I disagree. A lot. -- Fajro

On Tue, 17 Apr 2012 16:44:48 +0100, Thomas Morton wrote: I actually do agree. It is not a secret that we are attractive for people having personal problems of some sort, who hope that they can get kind of attention in Wikipedia/Wikimedia they can never get in real life. At some point I was even put in a situation when I had views opposed to the views of such people, and I basically had to defend my views against them. This proved to be impossible: I am pretty much successful in my professional career, and for me Wikipedia is, well, a hobby. But for them it is life. It is very difficult to argue with people who are fighting for life, does not matter who is defending what views. Finally, I inevitably had to say "fuck you" and leave the argument. There is in principle nothing wrong with people who want to get attention. For instance, they might want to get attention by writing articles, creating a big number of FAs abd GAs. Or by fighting vandals. Or by writing useful gadgets. I am all for it. And of course not everybody behaves like the types I mentions in the above paragraph - only a small fraction. But I am afraid that the more we socialize, the more attractive we become for this type of people. And then they tend to form circles, voting collectively at RFAs - up for the those from the circle, down for those not from the circle. Or discussing RfDs. Or whatever. It is extremely dangerous when people start mixing personal and professional relations - to speak in a not-so-much-correct way, when they start making love while in the office. This does not help writing the encyclopedia. And I have seen plenty of examples - and I guess all of us had. This is why I am not particularly looking forward to increasing socialization. Wikilove - fine, as a sign of appreciation (though I personally prefer appreciation written in plain English). Barnstars - ok. But going to a full-scale social network - I am sorry, this is going to kill us. Cheers Yaroslav

Let's separate the two big issues here - the first is whether we want to encourage large numbers of new editors, and the second issue encompasses all the cool feature ideas we could add to accomplish the first. On attracting new editors and improving editor retention - editor retention explains itself, of course, and I think many people agree that improving the "social fabric" of project communities (and specifically en.wp) contributes to better retention metrics. There is some disagreement over the value of large numbers of new contributors. Many people in the en.wp community want to make contributions from these folks, especially "anonymous" editors without a registered account, more difficult rather than easier... The position of the WMF has lately been that this is misguided; in fact a large proportion of content, even the majority, has been added and improved by anonymous IP contributors. While individual editors devoting hundreds or thousands of hours to Wikimedia are highly valuable, the subset of contributors who are anonymous are so vital to project success that we should absolutely focus on increasing their numbers and encouraging them to return often. On cool features, we could brainstorm all day on different things that would be great to have. I'm sure everyone has a list of things they'd like to see, and most probably can think of much better features than I can. Here's my quick list: 1) Internal messaging - using "e-mail this user" is cumbersome, especially if you don't want to reveal your e-mail address, and divorces communication from the project itself. It also doesn't lend itself well to communicating with more than one individual. There is a place for non-public communication in our projects, and we should improve that communication by adding internal tools. 2) Discussion and comment threading. Not sure whatever happened to LiquidThreads, but the ten year old method of discussing article content is antiquated and far behind the current standard. You get better discussion on Gawker. Why, for instance, is the newest content still added at the bottom of every page instead of the top? Makes no sense. 3) Notifications and other quick, public communication. Warnings, bot notices, system messages, hat tips, barnstars, and quick notes should all be integrated as notification types in an internal notification system. There might be ease of access issues, but since these are focused on editors and not readers I think those hurdles can be overcome. Talk pages are as antiquated as the article discussion pages, and there are far better ways of organizing message content. 4) Article feedback. Our article feedback progress is just getting started, but it has a long way to go. I'd like to see a sidebar or footer that tells me how many people approve or disprove of the article content, aged for relevance to the current revision. Readers (logged in editors or otherwise) should be able to add Tweet-length comments, which can be +'d or -'d by others so a reader can get an 'at-a-glance' sense of what other readers think about an article and why. 5) 'Request an article' - it should be a feature of MediaWiki to track what article titles for pages that don't exist get the most hits, and it would be a really cool scrollbox to show readers and editors "500 editors looked for 'page XYZ' today and didn't find it - create this page now!" We might have to curate it like TfA, but maybe not, and I guarantee you'd get an article in OK shape for each featured redlink.

This is actually a very good example. Imagine this happened, and we got for several hours a million of users who do not know anything about BLP, verifiability, POV, notability, and other issues. Would we be able to clean up their edits? I doubt it. If I remember well, when 80K landscape pictures of British Isles were donated to Commons more than a year ago (which is certainly a good thing), they were not categorized, and many of them (several dozen of thousands) remained uncategorized last time I checked. We will not just be able to digest this. The way out obviously that we do not have a million random editors. We want a million of editors who understand basic principles and know what they want to do. I just do not see how it could happen. When I personally ask my friends to upload photos which are clearly needed (for instance, to illustrate an already existing article), my best success is to ask them to send a mail to OTRS, and then I upload photos myself. And uploading a photo is generally easier than to find a category for an article or to source a statement. Cheers Yaroslav

Hi, A couple of quick comments. You have two way to approch gamification of content/service/product : * Built a game experience on top of the content/service/product * Lauche services/products dedicated to gamification based on your initial product What people are mostly talking about here is the first one. But we could also think of the second, like we could have a game interface to edit Wikipedia. You could have X thousands of sentence ready to translate and you could translate them one after the other little by little, and add a ranking of the top translators. This is how Facebook or Twitter translated their website. Gamification is a way to lower the threshold for a product/task. Making it fun and easy and something non-involving. We could also have the same thing for categorization of images. Corercting spelling mistakes. And so on. And the goal would be to make people that would have never edited, edit. As for making our content "social" or easier to share. There are, to some extent, privacy issues. But I doubt we would end with X thousand new people editing just that way. Would having those buttons hurt our mission or damage the user experience ? I doubt it. Would it be a major change and would generate press attention ? Definitly. So not a light decision to make as it can impact our image :) So even though -- Christophe

Am 17.04.2012 18:20, schrieb Sarah Stierch: Gamification might be a strategy for many things, but I don't think that it is working as a general approach throughout all communities. I doubt that european or asian communities would appreciate a playful approach on gathering and sharing knowledge as much as the en does. "encouraging people to bring their personalities to Wikipedia" - gamification might be of help for that. Trouble starts to make the brought-in editors stay when they see, that earning likes, favs and pluses is much more easier elsewhere, as you do not have to contribute lengthy on brazilian 200-m-sprinters, extinct languages of western papua, villages of western-central estonia, artillery battery commanders of the civil war, fossil species of foraminifera or fluid dynamics before. Maybe it might be more useful to support editing instead of collecting people only. I can't imagine that sharing a new picture on my userpage is helpful, while I am trying to figure out, if there is convincing information on the dispersal events of the genus Lilium in Japan and North America or trying to find a reference for the second album of a japanese ultra drone doom metal band. Would love to find help therein. Regards, Denis

Just to chip in here; Privacy, with *any* feature we introduce, is a top priority. When Product Development was coming out with the features engineering plan, anything that looked like it could screw with individual privacy was very, very quickly nipped in the bud. Now, if by "social" you mean "features purely dedicated to recreational/sharing activities", the answer is no: we're not currently planning any. From my (personal) perspective, it is very very hard to do these things and integrate into other services without putting our users at risk. And putting our users at risk is not what we're about. We're not doing what Facebook does because we're *not Facebook*. If, on the other hand, you just mean "features to promote greater communication and networking between editors", that's a clear priority - I'm happy to talk to people about the work we're doing, and to hear any suggestions along the way :). On 21 April 2012 21:52, Mono <monomium(a)gmail.com> wrote: -- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation

On 04/23/2012 01:03 PM, Jan Ku?era wrote: Hi, Kozuch. I look at https://bugzilla.wikimedia.org/show_bug.cgi?id=29806 and I see that, within a day of the issue being filed, multiple experienced MediaWiki developers commented on that issue to explain what the chart software's developers would have to do in order to make it suitable for use on our sites. I've also contacted the author of that extension to point at that bug's comments and at this procedural guide: https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment so if you could help me in alerting the extension's author to those comments, that would be great. Thanks! -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

Jan; we get new features fairly regularly :). At the moment we're working on two new pieces of software - the Article Feedback Form, v5, and New Page Triage (a replacement for Special:NewPages). After that we're moving on to a proper notifications system to allow better communication and participation across wikis. I appreciate the rate of progress may seem slow; it is worth pointing out we have a very small teem of features engineers (although more are being hired!) and so are limited in how many different things we can work on at once. On 25 April 2012 19:50, Jan Kučera <kozuch82(a)gmail.com> wrote: -- Oliver Keyes Community Liaison, Product Development Wikimedia Foundation

On Apr 29, 2012, at 1:04 AM, Jan Kučera wrote: You are comparing apples and oranges. Facebook: * Has *hundreds of millions* of dollars to devote to developer staff; * Does *not* have a community that demands to be consulted for every change; * Does *not* require that features work in ancient browsers; * Does *not* have to support skins and other technology built ten years ago; * Does *not* have to develop in order to support non-Facebook installs of their software; * Has *only* about 100 languages to develop for; * Pays *above* market rate I'm not sure I agree with you that Features Engineers should be the core of the Foundation's staff but that's not really relevant. There are two major constraints that I think need to be understood. First, the "multi-million budget" we have is actually *nothing* by the standards of sites and tech systems that are 1/20th of our size and scale. Bear in mind that features engineering only receives a fraction of the 30 million (or whatever) each year. (For comparison, a friend of mine runs a moderate-sized e-commerce site. Her budget, per year, is $300 million dollars. They get probably 1/100th of our traffic and users. Probably less.) Second, and this is going to make people surly, but the we don't pay crap. Our salaries are the lowest of the low. It is close to impossible to attract experienced talent when you are offering 80% of market rate. So even if we decided to put ALL the budget into hiring software engineers, it wouldn't mean anything because we still couldn't hire those people. This is the exact opposite of what you should be doing. If you feel strongly about this, you should lobby more and more people, and create a greater consensus that your chart software is important to everyone and should be elevated. Leaving the community isn't the solution: you miss 100% of the balls you don't take a swing at. --- Brandon Harris, Senior Designer, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

Sumana writes: Jan Kučera writes: +1 to investing in supporting code written by others. I think Sumana put it very well above :) You can help facilitate better/faster communication between core mediawiki devs and extension writers. SJ