These are two reason we don't have Thanks for anonymous editors: 1. Anonymous editors don't get notifications 2. Multiple editors often share the same IP address Problem #2 isn't as prominent as it use to be, but there are still many large companies and schools that connect to the internet through a single IP. 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.
Ryan Kaldari
On 10/01/14 19:21, Ryan Kaldari wrote:
These are two reason we don't have Thanks for anonymous editors:
- Anonymous editors don't get notifications
- Multiple editors often share the same IP address
Problem #2 isn't as prominent as it use to be, but there are still many large companies and schools that connect to the internet through a single IP. 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.
Ryan Kaldari _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
1. Why not? 2. A time limit might help resolve that with ipv4 addresses. Alternately, thanks could potentially be nice even if they didn't make the edit themselves, since it's the general feeling and such, so just letting that through for ipv4 addresses might be an option.
Mind I'm mostly just echoing something someone else said on IRC just now, but they seem like interesting points to me.
For 1: because it'd be impossible to accurately associate notifications with the person, I assume.
On 10 January 2014 12:11, Isarra Yos zhorishna@gmail.com wrote:
On 10/01/14 19:21, Ryan Kaldari wrote:
These are two reason we don't have Thanks for anonymous editors:
- Anonymous editors don't get notifications
- Multiple editors often share the same IP address
Problem #2 isn't as prominent as it use to be, but there are still many large companies and schools that connect to the internet through a single IP. 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.
Ryan Kaldari _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
- Why not?
- A time limit might help resolve that with ipv4 addresses. Alternately,
thanks could potentially be nice even if they didn't make the edit themselves, since it's the general feeling and such, so just letting that through for ipv4 addresses might be an option.
Mind I'm mostly just echoing something someone else said on IRC just now, but they seem like interesting points to me.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
"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@wikimedia.org wrote:
For 1: because it'd be impossible to accurately associate notifications with the person, I assume.
On 10 January 2014 12:11, Isarra Yos zhorishna@gmail.com wrote:
On 10/01/14 19:21, Ryan Kaldari wrote:
These are two reason we don't have Thanks for anonymous editors:
- Anonymous editors don't get notifications
- Multiple editors often share the same IP address
Problem #2 isn't as prominent as it use to be, but there are still many large companies and schools that connect to the internet through a
single
IP. 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.
Ryan Kaldari _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
- Why not?
- A time limit might help resolve that with ipv4 addresses. Alternately,
thanks could potentially be nice even if they didn't make the edit themselves, since it's the general feeling and such, so just letting that through for ipv4 addresses might be an option.
Mind I'm mostly just echoing something someone else said on IRC just now, but they seem like interesting points to me.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Oliver Keyes Product Analyst Wikimedia Foundation _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On that occasion, do IPs still receive information about messages on their talk page? (Since the orange bar was abolished and they now go through echo notifications all well) Am 10.01.2014 21:29 schrieb "Oliver Keyes" okeyes@wikimedia.org:
For 1: because it'd be impossible to accurately associate notifications with the person, I assume.
On 10 January 2014 12:11, Isarra Yos zhorishna@gmail.com wrote:
On 10/01/14 19:21, Ryan Kaldari wrote:
These are two reason we don't have Thanks for anonymous editors:
- Anonymous editors don't get notifications
- Multiple editors often share the same IP address
Problem #2 isn't as prominent as it use to be, but there are still many large companies and schools that connect to the internet through a
single
IP. 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.
Ryan Kaldari _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
- Why not?
- A time limit might help resolve that with ipv4 addresses. Alternately,
thanks could potentially be nice even if they didn't make the edit themselves, since it's the general feeling and such, so just letting that through for ipv4 addresses might be an option.
Mind I'm mostly just echoing something someone else said on IRC just now, but they seem like interesting points to me.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Oliver Keyes Product Analyst Wikimedia Foundation _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 10 January 2014 20:28, Oliver Keyes okeyes@wikimedia.org wrote:
For 1: because it'd be impossible to accurately associate notifications with the person, I assume.
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.
The downside of this is when we inevitably start thanking vandals by accident.
Kevin Rutherford
Sent from my iPhone
On Jan 10, 2014, at 4:03 PM, "David Gerard" dgerard@gmail.com wrote:
On 10 January 2014 20:28, Oliver Keyes okeyes@wikimedia.org wrote:
For 1: because it'd be impossible to accurately associate notifications with the person, I assume.
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.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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@hotmail.com wrote:
The downside of this is when we inevitably start thanking vandals by accident.
Kevin Rutherford
Sent from my iPhone
On Jan 10, 2014, at 4:03 PM, "David Gerard" dgerard@gmail.com wrote:
On 10 January 2014 20:28, Oliver Keyes okeyes@wikimedia.org wrote:
For 1: because it'd be impossible to accurately associate notifications with the person, I assume.
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.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
David Gerard, 10/01/2014 22:02:
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.
You already can, even on the unwelcoming ;) en.wiki and de.wiki: talk pages have not (yet) been killed. I think about 30-50k persons have been thanked with the simple {{grazie}} template on it.wiki across the years. https://meta.wikimedia.org/wiki/Cross-project_comparisons#Thanks
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.
On it.wiki, anonymous talk pages are purged monthly (with some conditions).
Nemo
I would very much enjoy notifications as an IP & for IPs.
We can make a few carve-outs: - major hubs (schools, businesses, wifi providers with thousands of users) can be excluded.
The message/framing to IPs would be slightly different than that for logged-in users: since we can't be sure it's the same person. Nevertheless we could make it fun for them to see the wall of comments left for the last user of that IP, and any global notifications for it.
The same message could highlight that they are logged out, in case they didn't realize (right now it's not easy to notice when you get logged out in the middle of a session, unless you've set a custom skin / color in your prefs).
SJ
On Fri, Jan 10, 2014 at 2:21 PM, Ryan Kaldari rkaldari@wikimedia.orgwrote:
These are two reason we don't have Thanks for anonymous editors:
- Anonymous editors don't get notifications
- Multiple editors often share the same IP address
Problem #2 isn't as prominent as it use to be, but there are still many large companies and schools that connect to the internet through a single IP. 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.
Ryan Kaldari _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
I think we should just thank everyone, on at least a yearly basis, with a "thank you" drive similar to what we do for fundraising. It doesn't need to be for a specific edit or tied to any one IP. After the fundraiser hits the goal we usually run it a little with a thank you banner, and if we did that separately and used it to encourage participation by our readers, all the projects should benefit.
On Sat, 11 Jan 2014, at 6:21, Ryan Kaldari wrote:
These are two reason we don't have Thanks for anonymous editors: ... 2. Multiple editors often share the same IP address
They already share talk page and contribs. I don't see notifications being a problem: each of them *knows* that the IP is shared, and has registration instructions readily available if such situation is a problem.
I don't know if we can confidently assume non-registered users know that they're using a shared IP - one of the most frequent complaints from readers, historically, was some variant on "why the ---- am I getting all these messages, I never edited anything" with varying degrees of alarm/distress.
A.
On 11 January 2014 06:10, Gryllida gryllida@fastmail.fm wrote:
On Sat, 11 Jan 2014, at 6:21, Ryan Kaldari wrote:
These are two reason we don't have Thanks for anonymous editors: ... 2. Multiple editors often share the same IP address
They already share talk page and contribs. I don't see notifications being a problem: each of them *knows* that the IP is shared, and has registration instructions readily available if such situation is a problem.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 11/01/14 06:21, Ryan Kaldari wrote:
These are two reason we don't have Thanks for anonymous editors:
- Anonymous editors don't get notifications
- Multiple editors often share the same IP address
Problem #2 isn't as prominent as it use to be, but there are still many large companies and schools that connect to the internet through a single IP. 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.
We could have a persistent cookie with an ID number assigned to anonymous users, and send messages to that. Then anons would get their messages despite roaming between IP addresses, and they wouldn't get messages for other people who happen to share their IP.
We could even allocate a row in the user table for them, which would be beneficial for various features that currently exclude anons due to the need to link to a user ID.
-- Tim Starling
On 01/12/2014 10:57 PM, Tim Starling wrote:
We could even allocate a row in the user table for them, which would be beneficial for various features that currently exclude anons due to the need to link to a user ID.
What you're discussing is an unnamed user account that's implicitly created and lasts as long as the cookie does. Those are going to pile up *really* fast, especially from browsers that do not keep cookies for any reason.
They could be cleaned up at interval, but then what attribution do edit gets? The IP as though there wasn't a cookie?
More questions that'd need to be answered: do you keep that user table row around for checkuser? (And I would say that the checkusers will demand that you do). What about talk pages? Use whichever IP's happens to be in use to have a User talk:Anonymous_192837? Do we keep /those/ around indefinitely?
Don't get me wrong; I would *love* to get rid of "anonymous-by-IP" users - they give /less/ privacy than an account do. But the UX is complicated to get right, and the needed code changes would be pervasive. For instance, you'd want users to be able to intuitively "import" what they did anonymously into a newly created account in a way that their IP will never have been shown.
-- Marc
On 13/01/14 15:35, Marc A. Pelletier wrote:
What you're discussing is an unnamed user account that's implicitly created and lasts as long as the cookie does. Those are going to pile up *really* fast, especially from browsers that do not keep cookies for any reason.
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 01/13/2014 12:19 AM, Tim Starling wrote:
Not as fast as revisions, and we seem to cope with those.
Fair enough.
So you'd implicitly create the user, track it by cookie? With some well designed UX this'd work well and hide IPs entirely (and allow users that do create an account to retroactively rename their contribs).
Wouldn't that affect caching though?
-- Marc
On 13 January 2014 05:18, Marc A. Pelletier marc@uberbox.org wrote:
On 01/13/2014 12:19 AM, Tim Starling wrote:
Not as fast as revisions, and we seem to cope with those.
Fair enough.
So you'd implicitly create the user, track it by cookie? With some well designed UX this'd work well and hide IPs entirely (and allow users that do create an account to retroactively rename their contribs).
Wouldn't that affect caching though?
​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.
I'm not into the technicalities, but to hide ip's entirely on the sites would be the biggest advance in improving privacy I can think of...
regards, Thyge - Sir49
2014/1/13 Marc A. Pelletier marc@uberbox.org
On 01/13/2014 12:19 AM, Tim Starling wrote:
Not as fast as revisions, and we seem to cope with those.
Fair enough.
So you'd implicitly create the user, track it by cookie? With some well designed UX this'd work well and hide IPs entirely (and allow users that do create an account to retroactively rename their contribs).
Wouldn't that affect caching though?
-- Marc
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
marc@uberbox.orgOf 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 13/01/14 20:37, Risker wrote:
marc@uberbox.orgOf 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 _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
I can see it now - a thank link that goes to the user's talkpage and opens a new section edit window, maybe with the header prefilled... but that would force a real interaction, and encourage real discussion...
On Mon, Jan 13, 2014 at 12:37 PM, Risker risker.wp@gmail.com wrote:
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.
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.
Indeed. I see a user's awesome edit, via a diff. I hit "thank". I hit "okay".
I see a user's awesome edit, via a diff. I hit the "talk" link, I hit the "new section" button, I fill in my message, I save my message.
Ultimately, though, this compares apples to oranges; nobody is "technologizing" this kind of user interaction because nobody is removing the ability to leave thankful talk page messages - indeed, I think they still serve a very useful purpose. I tend to thank people when they've made an edit I appreciate; I head over to their talkpage and give barnstars when this is indicative of wider good work on their part, or it's a /really/ great edit. All we've done is added some granularity to the system, reducing the barrier for small amounts of thanks.
On 13 January 2014 14:24, Steven Walling steven.walling@gmail.com wrote:
On Mon, Jan 13, 2014 at 12:37 PM, Risker risker.wp@gmail.com wrote:
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.
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. _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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@wikimedia.org wrote:
Indeed. I see a user's awesome edit, via a diff. I hit "thank". I hit "okay".
I see a user's awesome edit, via a diff. I hit the "talk" link, I hit the "new section" button, I fill in my message, I save my message.
Ultimately, though, this compares apples to oranges; nobody is "technologizing" this kind of user interaction because nobody is removing the ability to leave thankful talk page messages - indeed, I think they still serve a very useful purpose. I tend to thank people when they've made an edit I appreciate; I head over to their talkpage and give barnstars when this is indicative of wider good work on their part, or it's a /really/ great edit. All we've done is added some granularity to the system, reducing the barrier for small amounts of thanks.
On 13 January 2014 14:24, Steven Walling steven.walling@gmail.com wrote:
On Mon, Jan 13, 2014 at 12:37 PM, Risker risker.wp@gmail.com wrote:
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.
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. _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Oliver Keyes Product Analyst Wikimedia Foundation _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Mon, Jan 13, 2014 at 2:57 PM, Risker risker.wp@gmail.com wrote:
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.
I don't view Talk page messages and thanks notifications as competing or detracting from each other, and I think pretty much everyone works on Thanks would agree. They are additive. It's helpful to have different levels and types of ways to engage with each other on the wiki.
On 13 January 2014 15:03, Steven Walling steven.walling@gmail.com wrote:
On Mon, Jan 13, 2014 at 2:57 PM, Risker risker.wp@gmail.com wrote:
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.
I don't view Talk page messages and thanks notifications as competing or detracting from each other, and I think pretty much everyone works on Thanks would agree. They are additive. It's helpful to have different levels and types of ways to engage with each other on the wiki.
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.
On Jan 13, 2014, at 4:18 PM, Oliver Keyes okeyes@wikimedia.org wrote:
we're getting almost 3,000 thanks actions a day, every day
It would be interesting to know if that impacted the number of barnstars....
————————— Philippe Beaudette Director, Community Advocacy Wikimedia Foundation, Inc
On 13 January 2014 20:32, Philippe Beaudette pbeaudette@wikimedia.orgwrote:
On Jan 13, 2014, at 4:18 PM, Oliver Keyes okeyes@wikimedia.org wrote:
we're getting almost 3,000 thanks actions a day, every day
It would be interesting to know if that impacted the number of barnstars....
That would be difficult to track, but we can totally find out if there's been any change in, say, wikilove.
Barnstars mostly use a set of templates, right? (At least, the 80% case). We could ballpark it fairly effectively by checking for that set, no?
pb
*Philippe Beaudette * \ Director, Community Advocacy \ Wikimedia Foundation, Inc. T: 1-415-839-6885 x6643 | philippe@wikimedia.org | : @Philippewikihttps://twitter.com/Philippewiki
On Tue, Jan 14, 2014 at 10:05 AM, Oliver Keyes okeyes@wikimedia.org wrote:
On 13 January 2014 20:32, Philippe Beaudette <pbeaudette@wikimedia.org
wrote:
On Jan 13, 2014, at 4:18 PM, Oliver Keyes okeyes@wikimedia.org
wrote:
we're getting almost 3,000 thanks actions a day, every day
It would be interesting to know if that impacted the number of barnstars....
That would be difficult to track, but we can totally find out if there's been any change in, say, wikilove. _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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@wikimedia.org wrote:
Barnstars mostly use a set of templates, right? (At least, the 80% case). We could ballpark it fairly effectively by checking for that set, no?
pb
*Philippe Beaudette * \ Director, Community Advocacy \ Wikimedia Foundation, Inc. T: 1-415-839-6885 x6643 | philippe@wikimedia.org | : @Philippewikihttps://twitter.com/Philippewiki
On Tue, Jan 14, 2014 at 10:05 AM, Oliver Keyes okeyes@wikimedia.org wrote:
On 13 January 2014 20:32, Philippe Beaudette <pbeaudette@wikimedia.org
wrote:
On Jan 13, 2014, at 4:18 PM, Oliver Keyes okeyes@wikimedia.org
wrote:
we're getting almost 3,000 thanks actions a day, every day
It would be interesting to know if that impacted the number of barnstars....
That would be difficult to track, but we can totally find out if there's been any change in, say, wikilove. _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 01/14/2014 02:18 PM, Oliver Keyes wrote:
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)
And even then that'd give dubious results. Some talk page get archived barnstars et. al., some people (like I do with User:Coren) move them off to a discrete subpage in their userspace, and some people simply remove old sections from their talk pages (which would make the template not show as a transclusion at all).
Add to this the complexity that several barnstars are subst:ed rather than transcluded -- but not all -- and you end up with a completely intractable problem.
-- Marc
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@uberbox.org wrote:
On 01/14/2014 02:18 PM, Oliver Keyes wrote:
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)
And even then that'd give dubious results. Some talk page get archived barnstars et. al., some people (like I do with User:Coren) move them off to a discrete subpage in their userspace, and some people simply remove old sections from their talk pages (which would make the template not show as a transclusion at all).
Add to this the complexity that several barnstars are subst:ed rather than transcluded -- but not all -- and you end up with a completely intractable problem.
-- Marc
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Oliver Keyes, 14/01/2014 20:36:
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.
I'd rather call is a systemic bias which makes us favor standardised technological whizbangs just because we can measure them rather than for an actual effectiveness.
Nemo
So you'd rather measure effectiveness through...the feeling in your water?
On 14 January 2014 12:29, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Oliver Keyes, 14/01/2014 20:36:
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.
I'd rather call is a systemic bias which makes us favor standardised technological whizbangs just because we can measure them rather than for an actual effectiveness.
Nemo
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 14 January 2014 21:20, Oliver Keyes okeyes@wikimedia.org wrote:
On 14 January 2014 12:29, Federico Leva (Nemo) nemowiki@gmail.com wrote:
I'd rather call is a systemic bias which makes us favor standardised technological whizbangs just because we can measure them rather than for an actual effectiveness.
So you'd rather measure effectiveness through...the feeling in your water?
No, he means doing things because they're susceptible to measurement, rather than because they're a good thing to do.
The sort of thinking that leads to lightboxes over pages. "Just look at our response metrics!" Just look at your page.
- d.
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@gmail.com wrote:
On 14 January 2014 21:20, Oliver Keyes okeyes@wikimedia.org wrote:
On 14 January 2014 12:29, Federico Leva (Nemo) nemowiki@gmail.com
wrote:
I'd rather call is a systemic bias which makes us favor standardised technological whizbangs just because we can measure them rather than
for an
actual effectiveness.
So you'd rather measure effectiveness through...the feeling in your
water?
No, he means doing things because they're susceptible to measurement, rather than because they're a good thing to do.
The sort of thinking that leads to lightboxes over pages. "Just look at our response metrics!" Just look at your page.
- d.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Tue, Jan 14, 2014 at 11:32 AM, Marc A. Pelletier marc@uberbox.orgwrote:
Add to this the complexity that several barnstars are subst:ed rather than transcluded -- but not all -- and you end up with a completely intractable problem.
Bah humbug.
*Philippe Beaudette * \ Director, Community Advocacy \ Wikimedia Foundation, Inc. T: 1-415-839-6885 x6643 | philippe@wikimedia.org | : @Philippewikihttps://twitter.com/Philippewiki
On Tue, Jan 14, 2014 at 12:20 PM, Philippe Beaudette philippe@wikimedia.org wrote:
On Tue, Jan 14, 2014 at 11:32 AM, Marc A. Pelletier marc@uberbox.orgwrote:
Add to this the complexity that several barnstars are subst:ed rather than transcluded -- but not all -- and you end up with a completely intractable problem.
Bah humbug.
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_m...
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.
On 01/14/2014 04:07 PM, Tilman Bayer wrote:
but I wouldn't rule out the possibility that they still achieved a good approximation.
I'd wager that what they have gotten might be a poor sample; there is certainly a correlation between being a "power/advanced" user and more intricate talk page archiving -- so the class of users most likely to get some kinds of barnstars would end up being the most underrepresented in the dataset.
I haven't read their paper though - they may well have accounted for that in some manner.
-- Marc
On 13.01.2014 23:57, Risker wrote:
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
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 January 2014 14:42, Yaroslav M. Blanter putevod@mccme.ru wrote:
What does indeed make a difference and creates a sense of human interaction is custom messaging over templated messaging.
It's the human interaction bit. I was *delighted* when I got a "thank you" for an edit, and really wanted to be able to do the same thing for anonymous users - it means "someone has noticed your good edit*, immediate positive feedback. That's why I think we really need to make the "thank you" mechanism work for anons, somehow.
- d.
On 14.01.2014 15:53, David Gerard wrote:
On 14 January 2014 14:42, Yaroslav M. Blanter putevod@mccme.ru wrote:
What does indeed make a difference and creates a sense of human interaction is custom messaging over templated messaging.
It's the human interaction bit. I was *delighted* when I got a "thank you" for an edit, and really wanted to be able to do the same thing for anonymous users - it means "someone has noticed your good edit*, immediate positive feedback. That's why I think we really need to make the "thank you" mechanism work for anons, somehow.
- d.
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
Steven Walling, 13/01/2014 23:24:
On Mon, Jan 13, 2014 at 12:37 PM, Risker risker.wp@gmail.com wrote:
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.
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.
This is technically not true. Gadgets such as the navigation popups or LiveRC can places dozens of message types on talk pages with one or two clicks, including {{thanks}} or {{grazie}} (for IPs) on it.wiki. See screenshot: https://it.wikipedia.org/wiki/File:LiveRC-anteprima.jpg
Nemo
On 01/13/2014 12:01 PM, Thyge wrote:
I'm not into the technicalities, but to hide ip's entirely on the sites would be the biggest advance in improving privacy I can think of...
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 01/13/2014 10:14 PM, Matthew Flaschen wrote:
Without publically displayed IPs for anonymous edits, people couldn't do that.
That has, traditionally, been very much useless in practice. It's extraordinarily rare that abuse teams will even speak to checkusers, and they have some veil of authority.
Honestly, the normal block system would work just as well on those anonymized users (with autoblocks doing their trick doing effectively the same as an IP block for 99% of cases).
-- Marc
On 14/01/14 00:18, Marc A. Pelletier wrote:
On 01/13/2014 12:19 AM, Tim Starling wrote:
Not as fast as revisions, and we seem to cope with those.
Fair enough.
So you'd implicitly create the user, track it by cookie? With some well designed UX this'd work well and hide IPs entirely (and allow users that do create an account to retroactively rename their contribs).
Yes.
Wouldn't that affect caching though?
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 01/13/2014 12:19 AM, Tim Starling wrote:
On 13/01/14 15:35, Marc A. Pelletier wrote:
What you're discussing is an unnamed user account that's implicitly created and lasts as long as the cookie does. Those are going to pile up *really* fast, especially from browsers that do not keep cookies for any reason.
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.
We shouldn't assume linear growth over a ten year period. Nonetheless, the technical scalability problems are probably solvable.
Matt Flaschen
On 14/01/14 14:10, Matthew Flaschen wrote:
We shouldn't assume linear growth over a ten year period.
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 01/13/2014 11:20 PM, Tim Starling wrote:
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.
That's... come /on/ Tim! You know better than to say silly things like that.
The abuse filter alone could very well account for this (the prevented edits and the revert that would have taken place). :-) I used to do a lot of patrol back in those years and - for nostalgia's sake - I tried doing a bit over a year ago. The amount of "surface" vandalism has gone down a *lot* since.
-- Marc
On 14/01/14 15:38, Marc A. Pelletier wrote:
On 01/13/2014 11:20 PM, Tim Starling wrote:
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.
That's... come /on/ Tim! You know better than to say silly things like that.
The abuse filter alone could very well account for this (the prevented edits and the revert that would have taken place). :-) I used to do a lot of patrol back in those years and - for nostalgia's sake - I tried doing a bit over a year ago. The amount of "surface" vandalism has gone down a *lot* since.
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 Mon, Jan 13, 2014 at 8:56 PM, Tim Starling tstarling@wikimedia.org 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
Thanks for these links, which underscore how much work we have left to do. None of these problems are trivial, and concerted efforts on multiple fronts, both technical and social, are the only thing that will make a difference in the long run.
Erik
On 01/13/2014 11:56 PM, Tim Starling wrote:
Reversing the decline in editor population has been a major strategic priority of WMF for many years.
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 14/01/14 16:08, Marc A. Pelletier wrote:
On 01/13/2014 11:56 PM, Tim Starling wrote:
Reversing the decline in editor population has been a major strategic priority of WMF for many years.
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. :-)
Well, obviously I extrapolated a model to the point of absurdity, but I think it's better to derive a model from data than to make predictions based on unsubstantiated hope.
In my post at 05:19 UTC, I assumed a stable edit rate, which I thought was an optimistic upper bound. But Matt thought that it was actually pessimistic? So I gave an example of a model that I consider to be pessimistic, for comparison. I don't think either model is realistic, I think the most likely reality lies somewhere in between.
-- Tim Starling
On 1/14/14, 5:56 AM, Tim Starling wrote:
On 14/01/14 15:38, Marc A. Pelletier wrote:
On 01/13/2014 11:20 PM, Tim Starling wrote:
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.
That's... come /on/ Tim! You know better than to say silly things like that.
The abuse filter alone could very well account for this (the prevented edits and the revert that would have taken place). :-) I used to do a lot of patrol back in those years and - for nostalgia's sake - I tried doing a bit over a year ago. The amount of "surface" vandalism has gone down a *lot* since.
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:
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
On 01/16/2014 05:02 PM, Mark wrote:
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.
+1 Better said than I, but expressed the same substantive argument.
-- Marc
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@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:
On 14/01/14 15:38, Marc A. Pelletier wrote:
On 01/13/2014 11:20 PM, Tim Starling wrote:
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.
That's... come /on/ Tim! You know better than to say silly things like that.
The abuse filter alone could very well account for this (the prevented edits and the revert that would have taken place). :-) I used to do a lot of patrol back in those years and - for nostalgia's sake - I tried doing a bit over a year ago. The amount of "surface" vandalism has gone down a *lot* since.
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:
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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 1/17/14, 3:55 AM, Erik Zachte wrote:
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).
Thanks, that's interesting information!
Edits-that-survived is one baseline definition of productivity, though I'd be interested in data with a higher threshold for productive edit, if there's some way to distinguish them. For example what I really want to know is what the trends are for article-writing activity, e.g. how many editors we have who regularly expand articles with new information. Spot-checking some articles, these edits are by far in the minority, so in edit counts they are typically *completely* swamped by other kinds of editing. For example, picking one random article with a short edit history, here is a manual classification of its 12 edits: - 2 substantial content additions (original author, plus 1 subsequent author who added a paragraph) - 7 bookkeeping/formatting edits (category sorting, maintenance tags, infobox, bot replacing a template, etc.) - 3 copyedit edits
Those are all valuable in various ways (and I do all three kinds of editing myself), but a minority of the edits (2/12) have produced the vast majority of the article content (and all of its references). What I fear with the aggregate edit counts is that minor changes in bookeeping edits swamp even significant changes in the content edits, because the content edits are a relatively small percentage of the total count. So I'd be interested in seeing data on those categories separated out, though it's admittedly difficult to collect.
One mechanically countable statistic might be a count of edits that include a reference. Would miss references not added with a <ref> tag or other easily recognizable pattern, but might produce interesting trends nonetheless.
-Mark
wikimedia-l@lists.wikimedia.org