> Date: Fri, 1 Mar 2013 19:41:20 +0100
> From: Benoît Evellin <benoit.evellin(a)wikimedia.fr>
> To: WMF Editor Engagement Team <ee(a)lists.wikimedia.org>
> Subject: Re: [EE] Marie sent me this
> Message-ID:
> <CAAsxoJqdP2yq_Bqpt0ZYMpxVex8uV8HsMP-3WL0Bn-w=nqTYRg(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 2013/3/1 Steven Walling <swalling(a)wikimedia.org>
>
> >
> > On Mar 1, 2013 10:26 AM, "Terry Chay" <tchay(a)wikimedia.org> wrote:
> > >
> > > http://martinvalasek.com/blog/pictures-from-a-developers-life
> > >
> >
> > I think Terry forgot this isn't a team list anymore. ;)
> >
> I don't think it is a problem : on this list I'm a volunteer, but this link
> perfectly illustrate my (real) job ! ;-)
>
> Benoît
I thought that was hilarious and I forwarded the link to wikitech-l. However, it seems that they have no sense of fun; someone over there said that wikitech-l is "not a place to hangout with your friends and share dumb stuff." Talk about of being hostile to volunteers and people who are trying to foster a positive atmosphere. Needless to say, I don't think I'll be posting there anymore.
Pine
Hey all,
Today, the E3 team rolled out the following software changes to Wikimedia
projects...
- We launched guided tours on Commons, and Vietnamese, Korean, Dutch
Wikipedias. Because they depend on each other, we also added PostEdit to
Commons.
- We ended the week-long A/B test of the 'getting started' tour
delivered to half the new English Wikipedians who chose a task from
Special:GettingStarted after signing up. (Results forthcoming.)
- We enabled the CodeEditor extension on the Schema namespace on Meta,
for all you data nerds and developers to more easily edit schema JSON
on-wiki.
Tomorrow we're also publishing a blog post about the first rather promising
results from our experiments serving tasks to new English Wikipedians right
after they sign up, and what our immediate plans are. Keep an eye out for
it. ;)
All the best,
--
Steven Walling
https://wikimediafoundation.org/
Hello everyone,
I wanted to let you know that I just updated our feature requirements for Echo notifications, based on our recent conversations and your many good insights:
http://www.mediawiki.org/wiki/Echo_(Notifications)/Feature_requirements#Not…
Here's what's new in this version of the document:
* First notifications on top
I moved all the notifications that we plan to develop in the first release into the top sections, and moved the others in the 'under consideration' section. They're all listed in the 'First notifications' section at the beginning, and include:
• Talkpage Message
• Page Review
• Page Link
• Edit reverted
• User Mention
• Welcome (in collaboration with E3)
• Thank you (positive notification)
• How to use your watchlist (with E3)
• User rights (power user feature)
* Notification groups
Notifications are now classified into these main groups, based on their anticipated impact on users -- and on our development plans:
• interactive
• positive
• neutral
• negative
• new user
• power user
• under consideration
* New attributes
Each notification under development now has new attributes that specify its settings for preferences, bundling, dismissing and metrics. Here's an example:
• Web preference default: Enabled for all users
• Email preference default: Enabled for new users, disabled for others
• Web bundling: Disabled
• Email bundling: Disabled
• Dismiss feature: Enabled
• Metrics group: Interactive
• Metrics type: "user-mention"
* Special notes
Most notifications now have notes at the end that identify special requirements or dependencies. I invite you to check them out and flesh them out as needed.
* User mentions
Please let us know ASAP if you have questions about this notification, as Kaldari is working on it right now, picking up on the code originally written by Andrew Garrett and improved by Benny Situ. Be sure to check the notes.
* User rights
This power user feature will be tackled next week, so we would love to flesh it out next. Oliver will add links to the relevant policy pages on English Wikipedia, so we can link to them when notifications are sent. Check the notes for questions about whether or not we should use this notification for autoconfirmed users, blocked users -- or for when you lose any of these rights.
* Thank you
We've fleshed out this notification further, based on suggestions from Brandon, Kadari and Oliver, and would like to start development on it next week, so now is the time to chime in if you have any final comments.
* Features under consideration
I moved all other features we have been considering into their own section (e.g.: watchlist-related features), separate from notifications:
http://www.mediawiki.org/wiki/Echo_(Notifications)/Feature_requirements#Fea…
Some of them will be included in the first release (e.g. Watchlist guided tour, in collaboration with E3), others will be done in future releases.
Thanks again for all your good insights in helping us finalize these specifications. We hope to release most of these notifications in March -- and look forward to testing them with you very soon.
Comments welcome, as always, via email and in the talk pages.
All the best,
Fabrice
_______________________________
Fabrice Florin
Product Manager, Editor Engagement
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
The GettingStarted task order randomization
(https://gerrit.wikimedia.org/r/#/c/49975/) is ready for testing on toro.
When you refresh http://toro.wmflabs.org/wiki/Special:GettingStarted,
the order of the three task categories will be randomized.
This works by using three MediaWiki messages, which currently delegate
to templates.
MediaWiki:gettingstarted-task-1 - Template:Gettingstarted copyediting
MediaWiki:gettingstarted-task-2 - Template:Gettingstarted clarification
MediaWiki:gettingstarted-task-3 - Template:Gettingstarted adding links
Note, it is a known issue that the clarification message shows the
message keys when you click that question mark.
Matt Flaschen
Hello, everyone!
I'm happy to say that we now have a new version of Article Feedback, which is ready for testing on our prototype site:
http://www.mediawiki.org/wiki/Article_feedback/Version_5/Testing_Feb_2013
We invite you to try out some of the new features described on this testing page, then share your thoughts with us.
This new version is expected to greatly reduce the editor workload by providing simpler moderation tools, as well as better filters to surface useful feedback and make the best comments more visible to editors. These new features were developed based on recommendations from many community members on the English Wikipedia and other projects around the world.
I have also posted a general description of the new features on this Request for Comments about the future of this tool on the English Wikipedia:
http://en.wikipedia.org/wiki/Wikipedia_talk:Requests_for_comment/Article_fe…
You are welcome to participate there as well (if you are a staffer, please your WMF account and refrain from voting in this community discussion), as this Request for Comments will close in a week, on February 21st.
Though the majority view is now against Article Feedback on the English Wikipedia, we hope that some participants will find these improvements valuable enough to vote for a compromise, so that this tool can remain available in some form to the many editors who find it useful.
Either way, once these features have been fully tested and debugged on our prototype site, we expect to release them on multiple sites such as the French and German Wikipedias in March 2013. You can view our proposed timeline for this project here:
https://docs.google.com/a/wikimedia.org/spreadsheet/ccc?key=0Aq_75_5y5sKWdG…
I would like to take this opportunity to thank the wonderful team members who have made this improved version possible, including our developer Matthias Mullie, designer Pau Giner, community liaison Oliver Keyes and analyst Dario Taraborelli, to name but a few. It's a true pleasure and honor to be working with such an amazing team!
We look forward to your insights about this new version.
Regards as ever,
Fabrice
P.S.: I would also like to highlight two reports which demonstrate the thoughtful methodologies we used throughout this project.
* Moderation Tools Usability Study - by Pau Giner:
http://meta.wikimedia.org/wiki/Research:Article_feedback/Moderation_Tools_U…
* Feedback Quality Assessment - by Aaron Halfaker and Dario Taraborelli:
http://meta.wikimedia.org/wiki/Research:Article_feedback/Final_quality_asse…
Thanks to this careful work, we were able to develop much better tools and make more informed decisions as a result. We're very grateful for these important contributions to our project.
_______________________________
Fabrice Florin
Product Manager, Editor Engagement
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
Donate to keep Wikipedia free:
https://donate.wikimedia.org/
Hey everyone,
Happy Valentine's Day. :) Today the Editor Engagement Experiments team
deployed the following updates:
- We enabled PostEdit (the confirmation message after saving) to a few
new wikis (the full list is at Extension:PostEdit on MediaWiki.org).
- We enabled GuidedTour on some new wikis as well, including
MediaWiki.org so that developers can test new tours they might build there.
- We added some small design updates to GuidedTour, including removing
the X button per discussions on this list and Bugzilla, and we also fixed
the test tour in Monobook.
- We also fixed the way we bucketed users in the A/B test of the
"getting started" guided tour on English Wikipedia: previously those who
manually went back to Special:GettingStarted had a chance to view the tour
again if they picked another article. Now, people in the control group will
never see the tour, and those who complete the tour or end it won't see it
ever again.
If you have any questions, please don't be shy.
--
Steven Walling
https://wikimediafoundation.org/
Hi everyone,
Thank you for all your good suggestions and comments about positive notifications for Echo, which mean a lot to us!
To sum up our discussion so far, here some of the key points and ideas we have heard in this email thread and in offline conversations.
1. Positive notification ideas
The positive notifications we have discussed so far fall in 7 main categories, based on what triggers them.
Here's a short list of positive notification types (see full list below):
* Contributions ('100 edits to a page you edited.')
* Contributors ('20 people contributed to a page you edited.')
* Mark as useful ('someone marked your edit as useful.')
* Mark as non-problematic ('Cluebot did not find a problem with your edit.')
* Pageviews ('a page you edited was viewed 1,000 times.')
* Visitors ('42 people read the page you edited.')
* Feedback ('10 positive comments were posted on a page you edited.')
While most of these notifications could provide positive reinforcement to new users, some of them are easier to do and more likely to work on all sites, as outlined below.
2. Some ideas are hard to build
Sadly, some of these ideas require a lot more development than we can afford for our first release next month (we are looking for solutions that can be implemented in no more than a week for this release).
For example:
* Mark as non-problematic:
This would require an API, so that tools like Huggle or Cluebot can communicate with Echo. We have pushed back API development to future releases, because it would take significantly more time than we can afford right now -- not to mention the extensive coordination with third-party developers.
* Pageviews/Visitors:
This would require us to create a special database that would make pageview data available in a structured format, so that a program could periodically extract that data on a per-article basis, to determine whether or not a given threshold was exceeded. And visitor counts would be even harder to collect. Sadly, these ideas appear to be out-of-scope for this release.
3. Some ideas may not work for all projects
Here are examples of ideas that may not work on all projects, because they would require features that may not exist on these projects:
* Mark as useful
While the 'mark as useful' idea would provide just the kind of positive feedback we are looking for and could be developed in about a week, not all projects may be willing to add this new feature in their article history or diff pages.
* Feedback
While many positive notifications can easily be provided from the article feedback extension, not all projects may be willing to add this feature on their sites (e.g. the English Wikipedia is now leaning against it).
* Page reviews
Note that our current page review notification ('your page was reviewed') requires Page Curation to be installed, which leaves out most other projects right now. So for all intents and purposes, this notification will only help English Wikipedia users at this time.
4. Some ideas may not match primary user behavior
We are primarily looking for positive notifications about article edits made by a new user, because that primary behavior represents about 74% of their first actions. While notifications about pages they created are nice to have, this only corresponds to about 16% of current user behavior, which makes them less important.
So to sum up, we're looking for ideas that match these criteria:
* makes the new user feel good about participating
* responds to an article edit they made recently
* can be developed in no more than a week
* is likely to be adopted by a number of projects
Given these criteria, the most promising ideas so far appear to be notifications about contributions (or contributors) to a page you edited. We might also consider 'mark as useful' or 'feedback' notifications for projects that seem likely to adopt these new features, but those would have to be viewed as lower priority than the contribution notifications. Other ideas may have to wait until future releases, sadly.
What do you think? Have we missed any ideas that could fit within our criteria? Or do we have information that might shed new light on some of the more challenging ideas we have discussed so far?
Thanks again for your great suggestions so far -- we're trying to solve a difficult but important problem, which will require time and ingenuity from all of us. We hope that with your help, we can develop practical methods for showing appreciation and gratitude to new users in their first steps.
All the best,
Fabrice
_____________________
POSITIVE NOTIFICATION IDEAS
Here is a full list of positive notifications we have discussed so far.
They fall in 7 main categories, based on what triggers them, and are listed below in rough order of feasibility:
1. Contributions:
* New edits to a page you edited:
"'100 edits have been made to this page since your last edit.'"
* New edits to a page you started:
"'100 edits have been made to a page you started.'"
2. Contributors:
* Contributors to a page you edited:
'20 people have contributed to this page since your last edit'
* Contributors to a page you started:
"5 other people have contributed to the page you created."
3. Mark as useful:
* Support in history or diff pages: (manual clicks)
'Kaldari marked your edit as useful'
… or: (alternative wordings)
'Kaldari thanked you for your edit'
'Kaldari liked your edit'
4. Mark as non-problematic:
* Manual evaluations in tools like Huggle:
'Okeyes did not find a problem with your edit'
* Automated evaluations by bots like Cluebot:
'Cluebot did not find a problem with your edit'
5. Pageviews:
* Pageviews on a page you edited:
"A page you edited was viewed 1,000 times"
* Pageviews on a page you started:
"A page you started just reached its first 1,000 page views"
6. Visitors:
* Visitors to an article you edited:
"30 people have looked at your article since you made your edit."
* Visitors to a page you started:
"42 people have read the page you started.'"
* Visitors to your user page:
"20 people have visited your user page this week"
7. Article feedback
* Your useful feedback
"HowieF found your comment useful"
* Positive feedback for a page you edited:
"10 positive comments were posted on a page you edited."
* Useful feedback for a page you edited:
"10 useful comments were posted on a page you edited."
* Feedback satisfaction for a page you edited:
"85% of readers found what they were looking for on a page you edited."
The most promising ideas will soon be added to our feature requirements page:
http://www.mediawiki.org/wiki/Echo/Feature_requirements#Features_under_cons…
On Feb 2, 2013, at 5:03 AM, Oliver Keyes wrote:
>
>
> On 2 February 2013 12:43, Benoît Evellin <benoit.evellin(a)wikimedia.fr> wrote:
> Hi everybody
>
> I have various observations for all of your ideas.
>
> * Useful edit notification : this idea may be a good one, if the wording illustrates a Jedi/padawan relation instead of an editor-in-chief/freelance relation. We want equality between all editors. We all know that is not true, so we mustn't dig the trench deeper.
>
> * Contributions since the last edit : I completely agree with Chris experience and Liam suggestions. Be careful again in the wording : articles are the property of no one.
>
> * positive notifications and bot notifications : how will it work on Wikipedias without theses features ?
>
> The idea is that instead of hooking it into specific services (ClueBot, Huggle) we'll have a "silent" notification - something that exists but is not triggered by MediaWiki, and can instead be triggered through the API. So, when ClueBot finds an edit does not meet its standards for reverting it, it would poke the API to send $notification to $userwhomadeedit. Because it's not service-specific, other wikis with their own automated or semi-automated tools could also hook in using the same process.
>
> The problem with tying the notification to something in MediaWiki is that MediaWiki itself really doesn't have a way of recognising edits as 'good' or 'bad' - that's always been handled through bots and user extensions.
>
> (I'd actually argue that this is a good illustration of why a decade of correcting for MediaWiki's flaws by way of the TS, bots, API calls, etc has substantially harmed the efficacy of our product(s) - but this is an essay-sized rant for another day :))
>
> Benoît
>
>
> 2013/2/2 Sage Ross <ragesoss+wikipedia(a)gmail.com>
> On Sat, Feb 2, 2013 at 6:18 AM, Oliver Keyes <okeyes(a)wikimedia.org> wrote:
> >
> >
> > On 2 February 2013 03:33, Liam Wyatt <liamwyatt(a)gmail.com> wrote:
> >>
> >> I'd like to give a giant +1 to Chris's suggestion - telling (potential)
> >> editors how many other people have read the article is a big motivator. It's
> >> logical really, we know this from the Education outreach projects and also
> >> from all the GLAM content donations: people REALLY are motivated by the fact
> >> that *their* writing and multimedia is being seen by lots of people.
> >>
> >> Currently that information is rather hidden away in a link to the
> >> toolserver via the History tab. If you could bring that information more to
> >> the fore it could be really satisfying. For example:
> >> "30 people have looked at your article since you made your edit." or,
> >> "350 people have seen this article in the last month" or even "6 other
> >> editors have changed this article and 500 people have read it since you last
> >> helped edit it". Perhaps you could even give some more complex breakdowns
> >> with pageviews by continent?
> >>
> > The problem with this (or potential problem) is twofold: first, with a large
> > number of pages it could get spammy. Second, to my knowledge the toolserver
> > and stats.grok.se sites are not run off any kind of live data; they're
> > reliant on database dumps. We'd either be plugging into third-party services
> > of unknown viability or need to make a request to analytics for them to make
> > this kind of data more internally available and transparent, which could be
> > a pile of work.
> >
>
> The traffic dumps have been running pretty reliably on a daily basis,
> so it's close enough to live for this purpose.
>
> Making that more internally available and transparent would be well
> worth a modest pile of work, as this is data that we know is very
> powerful motivation for many contributors (new and experienced alike).
>
> It would take some experimenting to see what kinds of traffic-related
> data are effective in Echo notifications, but the basic concept has a
> lot of potential. (And getting article-level traffic data integrated
> into our internal infrastructure would be an important step forward
> even beyond usage in Echo.)
>
> -Sage
>
> _______________________________________________
> On 2 February 2013 08:38, Chris McMahon <cmcmahon(a)wikimedia.org> wrote:
>
>
> On Fri, Feb 1, 2013 at 1:02 PM, Fabrice Florin <fflorin(a)wikimedia.org> wrote:
> Hi guys,
>
> We would be grateful for your advice on how to give more positive notifications to new users after their first edits.
>
> We're looking for notification ideas that could lead new editors towards a "happy path" to encourage further contributions.
>
> What about "20 people have visited your user page at User:Yourname this week" or similar? I think it points up the interconnectedness of wiki users.
>
> In general, I think notifications about people and what people do will be more welcome than notifications about pages and what is done to them. This is true of the suggestions I've read, but I think it is worth noting specifically.
>
> _______________________________________________
On Feb 2, 2013, at 3:17 AM, Oliver Keyes wrote:
>
>
> On 2 February 2013 00:20, Steven Walling <swalling(a)wikimedia.org> wrote:
>
> On Fri, Feb 1, 2013 at 2:26 PM, Oliver Keyes <okeyes(a)wikimedia.org> wrote:
> So, I feel strongly that Huggle and ClueBot integration is frankly all the positive notification we need for edits alone. I can gather some data on it, but I'm pretty sure they cover the vast majority of incoming edits. I'm also wary of sticking another interface element in page histories or diffs (already crammed), since it increases the footprint of Echo and the chances people might grumble about it.
>
> I think Oliver is probably correct that hooking in to these pre-existing queues is the right approach. The one question I'd have is: what volume of edits are actually being marked as helpful?
>
> I can get some numbers on this - I'll poke the Huggle and Cluebot teams today. I think it's less 'mark as helpful' and more 'mark as non-problematic' at the moment, but they're for all intents the same (An edit that does not need reverting).
> I would say focusing on one method where we know users are getting positive feedback, and then iterating on that, is a good approach. Also: am I correct in assuming that we have the "marked as patrolled" notification for page creators?
>
> I would say that adding the "mark as helpful" button is a larger change than you think, and likely to cause a stir. I would proceed with caution there, because in addition to the noise you'll generate from putting _anything_ new on histories and diffs, we need to build a positive feedback mechanism that is going to work in the long term, and which we think experienced users will actually use in a large scale way. This is not a trivial ux problem, as you can see from the tale of the MoodBar/Feedback Dashboard story: we can always get newbies to generate a new queue of activity. But changing the habits of experienced editors with lots to do is hard.
>
> --
> Steven Walling
> https://wikimediafoundation.org/
On Feb 1, 2013, at 12:15 PM, Luke Welling WMF wrote:
> Article Feedback integration, ie "A page you edited 'List of Ancient Jedi' was rated 4* for trustworthiness"
>
> "5 other people have contributed to the page you created 'The Wombles'"
>
> I think the best positive vanity metric would be "42 million people have read the page you created 'Dr Who'" but getting the data would be difficult.
>
>
> On Fri, Feb 1, 2013 at 3:02 PM, Fabrice Florin <fflorin(a)wikimedia.org> wrote:
> Hi guys,
>
> We would be grateful for your advice on how to give more positive notifications to new users after their first edits.
>
> We're looking for notification ideas that could lead new editors towards a "happy path" to encourage further contributions. Many studies have shown that positive reinforcement plays an important role in increasing a user's productivity, and we would like to provide at least one or two good solutions to support that goal in the first release of Echo at the end of March.
>
> Here are some of the ideas which we have brainstormed to date, on our Echo feature requirements page:
>
> http://www.mediawiki.org/wiki/Echo/Feature_requirements#Positive_notificati…
>
> They include:
>
> * Useful edit notification
> This feature would add a 'Mark as useful' button in article history and/or diff pages, to invite experienced editors to mark edits they find useful, so they can send positive feedback to new editors. This could be done through a simple text link next to each edit (e.g. next to 'Undo'): 'Mark as useful' (or 'Useful' for short). When an editor clicks on that link, this notification would be sent to the new editor: 'Kaldari marked your edit as useful on Golden-crowned Sparrow. <View your edit>'
>
> * Huggle/Cluebot Notifications
> This feature would hook into third-party anti-vandalism tools like Huggle or ClueBot. Some of these tools could be adapted to provide an "approve of edit" button (Huggle already has such a feature), which could send a notification to the user who made the 'good' edit saying something like "this was good! Keep it up".
>
> * Contributions since your last edit
> Another feature we discussed is giving new users a bundled notification that '20 people have contributed to this page since your last edit'. While this type of activity is currently handled by the watchlist, this type of 'contributions' notification could have a positive impact in getting the new user to go back to a page they edited earlier (particularly if they don't yet feel motivated to use the watchlist).
>
> * Positive notifications for active new users
> We have already identified a number of positive notification ideas for active new users, which include: WikiLove, Page Link, or Page added to WikiProject. While these positive notifications are likely to motivate active new users, a challenge we face is how to give positive reinforcement to new editors immediately after their first few edits, before they become active enough to start new pages or be noticed for a WikiLove message.
>
>
> What do you think of these first ideas? None of them may be perfect in their current formulation, but with your help, we could be improve them to provide a practical solution that helps engage new users to participate more productively. With everyone's guidance, we can do better than only send them negative notifications when their edits are reverted (which is like a slap in the face) -- or sending them no notifications whatsoever after their first edits (which is what we are doing now).
>
> Do you have other ideas for positive notifications we could be sending to new users?
>
> You are welcome to respond in this email thread, or add your comments or suggestions on this Echo talk page.
>
> Thanks for any tips or ideas you can provide to help us with this important editor engagement goal!
>
> All the best,
>
>
> Fabrice
>
>
> _______________________________
>
> Fabrice Florin
> Product Manager, Editor Engagement
> Wikimedia Foundation
>
> http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
>
_______________________________
Fabrice Florin
Product Manager, Editor Engagement
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
Donate to keep Wikipedia free:
https://donate.wikimedia.org/