"I imagine that once IPv6 is widely in use, this problem will go away and we'll be able to turn on all notifications (including Thanks) for anonymous editors." Not completely correct when it comes to public computers and mobile IPs. On Fri, Jan 10, 2014 at 12:28 PM, Oliver Keyes <okeyes(a)wikimedia.org> wrote:

On 10 January 2014 20:28, Oliver Keyes <okeyes(a)wikimedia.org> wrote: Apparently that's the reason. However, being able to thank IP contributors for their contribution would be FANTASTIC. Saying "thank you" to casual drive-by contributors would give them quite a buzz, I'd think. Perhaps a timeout? Say, you can thank an IP for their edit within 1 hour? We can experiment and see what time gives the best amount of thanks versus mistakes. - d.

Yeah. It shouldn't be like welcome messages, it should be specifically for thanking for good edits. But this is a cultural issue, not a software issue. On 10 January 2014 21:30, Kevin Rutherford <ktr101(a)hotmail.com> wrote:

On 13/01/14 15:35, Marc A. Pelletier wrote: Not as fast as revisions, and we seem to cope with those. On the English Wikipedia, there were only ~27k anonymous edits per day over the last month, so it would take 10 years to add 100M rows at that rate, and the revision table has ~550M rows and we still haven't bothered to shard it. -- Tim Starling

On 13 January 2014 05:18, Marc A. Pelletier <marc(a)uberbox.org> wrote: ​We've talked about using the cached Parsoid HTML for read requests (with user-specific CSS styling applied at request time) rather ​than uncached MW HTML renders for a while. This'd be a good impetus to actually doing that. :-) J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

<marc(a)uberbox.org>Of course there already exists a way to thank IP editors. It is to go to their talk page and leave them a message that says "Thanks for your edit here [link to diff]." It is far more personal, far more likely to encourage the user to edit further (and maybe create an account?) based on research on the effects of template versus personalized talk page messages to new editors, and doesn't require anyone to write any code whatsoever. I'm not entirely certain it's a good idea to "technologize" such very basic user interactions. It takes as much work to "thank" someone using notifications as it does to leave them a talk page message. Risker/Anne

On Mon, Jan 13, 2014 at 12:37 PM, Risker <risker.wp(a)gmail.com> wrote: That's empirically not true. If I am on a page history or list of user contributions, it's takes just two clicks and you don't leave the page. To leave someone a Talk page message takes several new page loads and steps.

I dunno, guys. I certainly would take a talk page message over a mechanical "thank" any day of the week. More particularly, I notice a significant trend in using "thank" notifications to express agreement with people without having to actually say "yeah, I agree" somewhere. That the loss of human contact, replacing it with another technological whizbang, is considered a net positive...well, I guess that's what can be expected from Wikimedia. Risker On 13 January 2014 17:36, Oliver Keyes <okeyes(a)wikimedia.org> wrote:

On 13 January 2014 15:03, Steven Walling <steven.walling(a)gmail.com> wrote: Agreed. Re technological whizbangs.... If you're receiving this message, it's because I've successfully pushed on coloured lumps of plastic, sending electrical signals translated from English-language characters into unicode characters, themselves translated into binary signals, which are encoded by a lump of intricately etched and forked metal the size of a transit card. These are then sent as electrical signals, translated into pulses of light, translated back into electrical signals (repeat an unknown number of times), and reach a hunk of metal on your floor or desk containing a similarly etched piece of metal that translates them from pulses of electricity to unicode strings to character representations on a screen that ( assuming it isn't a CRT or some weird LED...thing) consists of a couple of squares of plastic with liquid, crystalline shapes connected to tiny transistors. There's tamed lightning there too. Some of the technical details may be wrong (Dammit, Jim, I'm an analyst, not a computer engineer!) but the point is that if 'technological whizbangs' are what you're objecting to, you should probably junk your computer. What I think you probably mean instead is that the message conveyed is, because it's in a standardised format, somewhat artificial. It doesn't give you the freedom to express the full gamut of human sentiments. And, well, it doesn't, because it was never designed to. If you want to write a love sonnet to a user for clearing up the copyright backlog, 'thanks' is not for you. If you want to drop in a template that transcludes in some CSS and SVG images in order to render a barnstar (potentially containing a love sonnet - I don't judge), 'thanks' is not for you. On the other hand, if what you want to do is say 'good job', you probably don't need all the capabilities and complications of a system oriented around trancluded templates with love sonnets in them. It's a much higher barrier than is actually necessary for what you're trying to achieve, which is just the internet equivalent of a thumbs up. Is there some loss of human contact? Well, potentially - there is whenever things are standardised - but, at least with the things /I/ use thanks for, there wasn't really any human contact initially. "Thanks for your edit on [page]" on a talk page doesn't really provide much more than "[user] thanked you for your edit on [page]". I know that whenever I've received thanks for that kind of thing, it's cheered me up quite a bit, so evidently the loss isn't /that/ great. In exchange, it dramatically reduces the barrier to giving that thumbs up - we're getting almost 3,000 thanks actions a day, every day, and I'd argue that's A Good Thing (and probably not something we saw when the options were 'Wikilove or bust', because a high barrier for a one-size-fits-all action does not benefit small uses of that action). Yes, it's less human than big long messages and barnstars and plaudits. That's fine - things worthy of big long messages != things worthy of a thumbs up, and Thanks is designed for the latter. When we have some spare cycles, if we want to reduce the barrier to more long-form thank-yous, that's probably a good thing to do as well. Just, please, nobody send me any love sonnets. -- Oliver Keyes Product Analyst Wikimedia Foundation

On 13 January 2014 20:32, Philippe Beaudette <pbeaudette(a)wikimedia.org>wrote;wrote: That would be difficult to track, but we can totally find out if there's been any change in, say, wikilove.

Yes, but what you'd then have to do is either go through the database dumps or hit the API and check individual diffs. Database-stored information on templates is "where are those templates linked from", not "and when were those links added" (unless something has changed relatively recently) On 14 January 2014 10:49, Philippe Beaudette <philippe(a)wikimedia.org> wrote: -- Oliver Keyes Product Analyst Wikimedia Foundation

There is inherent humour in being unable to test the comparative efficacy of a technological whizbang due to the lack of sufficiently standardised technological whizbangs ;p. On 14 January 2014 11:32, Marc A. Pelletier <marc(a)uberbox.org> wrote: -- Oliver Keyes Product Analyst Wikimedia Foundation

So you'd rather measure effectiveness through...the feeling in your water? On 14 January 2014 12:29, Federico Leva (Nemo) <nemowiki(a)gmail.com> wrote: -- Oliver Keyes Product Analyst Wikimedia Foundation

Aha. I totally agree with that, then, but I don't think it's the motivation for this feature. On 14 January 2014 13:28, David Gerard <dgerard(a)gmail.com> wrote: -- Oliver Keyes Product Analyst Wikimedia Foundation

On Tue, Jan 14, 2014 at 12:20 PM, Philippe Beaudette <philippe(a)wikimedia.org> wrote: Quite a few researchers have published quantitative analyses of barnstars, e.g.: https://meta.wikimedia.org/wiki/Research:Newsletter/2013/July#cite_ref-7 (analyzed 21,299 barnstars awarded to 14,074 editors on the English Wikipedia) https://meta.wikimedia.org/wiki/Research:Newsletter/2012/August#Briefly https://meta.wikimedia.org/wiki/Research:Newsletter/2012-04-30#Recognition_… Yes, some of them could probably have enhanced their datasets by taking e.g. talk page archiving into account, but I wouldn't rule out the possibility that they still achieved a good approximation. -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB

On 13.01.2014 23:57, Risker wrote: Actually, I think here there are two issues mixed here and this is why your message got such a reaction. We do not have just two types of messages - human and automated ones. We actually have three: human custom, human templated, and automated templated messages. I do not see much of a difference between human templated and automated templated messages. For example, when I nominate a file for deletion on Commons, this is done by one mouse click, and the uploader gets an automated message on their talk page. I do not have any problems with this. Certainly not more than if I had to go myself to the talk page and leave a template. Well, may be if I did it manually, I also could add their talk page to my watchlist and potentially answer questions - but OTOH I would have by now thousands user talk pages on my watchlist, and it would be very difficult to manage. Anyway. What does indeed make a difference and creates a sense of human interaction is custom messaging over templated messaging. I am myself a strong supporter of custom messages, and I do not use templates for communication except for the situations when I am legally bound to do it (deletion notices, copyvio notices, and block notices), and also welcome templates since they contain a lot of useful links. On my RfA in the English Wikipedia I was asked a question about it and went into some detail answering the question, and I am not going to repeat it here. I do believe that templates make Wikipedia more similar to MMORPG that we (at least I) would like to see it and in the sense contribute to the decline in number of active users. OTOH, I also see that someone who is overworked and had to communicate with dozens of users per day would choose over templating just to save time. Cheers Yaroslav

On 14.01.2014 15:53, David Gerard wrote: I am certainly not against the thank you mechanism for IP editors (I still do not quite understand whether it is feasible, but this is a different issue). I also use the thank you mechanism myself, mostly in the cases someone corrected my typo or introduced some minor corrections - I just find it easier, because otherwise I would probably not go to their talk page which may be in watchlists of hundreds of users. For significant improvements I leave a custom message at the talk page. If there is a discussion I certainly believe that one should go and participate rather than thank for the specific messages - first, in this case thenking is more like likes in social media, second, it is not even visible to others. I mean, echo is a cool and useful thing, and I am happy to have it, but it should not replace the watchlist. Cheers Yaroslav

On 01/13/2014 12:01 PM, Thyge wrote: True, but transparency has also always been important to Wikimedia. Without being a checkuser, or even an admin, people can see what company/ISP/school/government office a vandal is editing from, and report it to their abuse team. Without publically displayed IPs for anonymous edits, people couldn't do that. Matt Flaschen

On 14/01/14 00:18, Marc A. Pelletier wrote: Yes. Not very much. We already give anonymous users a session cookie on edit, which suppresses the frontend cache, the primary reason being (drumroll) user talk page message notification. So the impact would be that the cache-suppressing cookie would have a longer expiry time. -- Tim Starling

On 14/01/14 14:10, Matthew Flaschen wrote: Indeed. The data strongly points to sublinear growth. The English Wikipedia edit rate has been declining since about January 2007, and is now only 67% of the rate at that time. A linear regression on the edit rate from that time predicts death of the project at around 2030. Meanwhile, WMF revenue has gone from 2.4M (2006/2007) to 50.4M (2012/2013). I don't think backend scaling is really a problem we have anymore. -- Tim Starling

On 14/01/14 15:38, Marc A. Pelletier wrote: Reversing the decline in editor population has been a major strategic priority of WMF for many years. You are saying you have never heard of it before? Well, here is some reading material for you: <http://blog.wikimedia.org/2009/11/26/wikipedias-volunteer-story/> <https://strategy.wikimedia.org/wiki/Wikimedia_Movement_Strategic_Plan_Summary/Increase_Participation> <http://blog.wikimedia.org/2011/07/22/year-in-review-and-the-road-ahead-for-global-development/> <http://opensourcebridge.org/sessions/1061> <http://thread.gmane.org/gmane.org.wikimedia.foundation/63549> -- Tim Starling

On 01/13/2014 11:56 PM, Tim Starling wrote: My own opinion about how that decline isn't nearly as bad as some claim is well known. But also entirely besides the point: I was referring to that specific statement of yours: "A linear regression on the edit rate from that time predicts death of the project at around 2030." I kept expecting you to add "Netcraft confirms it" at some point. :-) -- Marc

On 1/14/14, 5:56 AM, Tim Starling wrote: I have heard much about the strategic priority, but much less about the rigorous data analysis. In particular, I have yet to see a demonstration that there is actually a decline in what we might call the "productive editor" population, people adding things to articles or otherwise improving them. Instead what's usually quoted are raw counts, things like "number of accounts that have made >5 edits in a month". But of course this kind of "blind quantitative" analysis is not a legitimate social-science methodology, at least not if some extremely strong ceteris-paribus assumptions are first validated. To just pick one hypothesized confound among many that have been discussed on and off, there may have been a decline in the joint population of "vandals + vandal-fighters". These are counted as editors by the ">5 edits" criterion, but between them produce no net editing, so a decline in their joint population is not a real editor decline, and an increase in their joint population is not a real editor increase. Another hypothesized confound is that there has been a wholesale replacement of "recent changes patrollers" with bots. A loss of net-95 editors because 100 people who solely did recent-changes patrol were replaced by 5 bots that do the same job would be a decline of 95 raw-data editors, but not really a net loss in productive editors. These confounds might, in the end, not account for much after all. But I have been looking and haven't found even an attempt to *really* substantiate claims that the number of actual encyclopedia editors has declined, versus just superficial quantitative analysis of the accounts-making-edits raw data. Best, Mark

Here are some charts which breakdown edits into several categories, reverts are counted separately. Of course edits is not editors, but it could be indicative of changed behavior patterns/policies. In the ongoing reassesment of metric definitions one thing discussed is whether we should count productive editors separately (I think we do), and if so on what basis (e.g. x edits per week/month which survived y days of not being reverted). http://stats.wikimedia.org/EN/PlotsPngEditHistoryAll.htm Erik -----Original Message----- From: wikimedia-l-bounces(a)lists.wikimedia.org [mailto:wikimedia-l-bounces@lists.wikimedia.org] On Behalf Of Mark Sent: Thursday, January 16, 2014 23:03 To: Wikimedia Mailing List Subject: Re: [Wikimedia-l] Thanking anonymous users On 1/14/14, 5:56 AM, Tim Starling wrote: I have heard much about the strategic priority, but much less about the rigorous data analysis. In particular, I have yet to see a demonstration that there is actually a decline in what we might call the "productive editor" population, people adding things to articles or otherwise improving them. Instead what's usually quoted are raw counts, things like "number of accounts that have made >5 edits in a month". But of course this kind of "blind quantitative" analysis is not a legitimate social-science methodology, at least not if some extremely strong ceteris-paribus assumptions are first validated. To just pick one hypothesized confound among many that have been discussed on and off, there may have been a decline in the joint population of "vandals + vandal-fighters". These are counted as editors by the ">5 edits" criterion, but between them produce no net editing, so a decline in their joint population is not a real editor decline, and an increase in their joint population is not a real editor increase. Another hypothesized confound is that there has been a wholesale replacement of "recent changes patrollers" with bots. A loss of net-95 editors because 100 people who solely did recent-changes patrol were replaced by 5 bots that do the same job would be a decline of 95 raw-data editors, but not really a net loss in productive editors. These confounds might, in the end, not account for much after all. But I have been looking and haven't found even an attempt to *really* substantiate claims that the number of actual encyclopedia editors has declined, versus just superficial quantitative analysis of the accounts-making-edits raw data. Best, Mark _______________________________________________ Wikimedia-l mailing list Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>