Hi folks,
We would appreciate your views on the current version of the Dismiss feature, as described here:
http://www.mediawiki.org/wiki/Echo_(Notifications)/Feature_requirements#Dis…
This 'Dismiss' tool enables users to turn off notifications categories they don't want to see in the flyout or the all-notifications page, so they don't have to go to the preferences page if they don't want to.
If you haven't already, you can test this feature here on MediaWiki:
http://www.mediawiki.org/wiki/Special:Notifications
Krinkle and a couple other folks have raised concerns about this feature here on Bugzilla:
https://bugzilla.wikimedia.org/show_bug.cgi?id=46587
What do you think? Is this feature useful to you in its current form?
Note that currently it only lets you turn off an entire notification category (instead of just removing individual notifications). In that sense, it is similar to Facebook's 'User Opt-Out' feature, which lets you turn off notifications from an application or group, as described here:
https://developers.facebook.com/docs/concepts/notifications/
Would you prefer to have the 'X' button simply close that individual notification? (without the option to turn off all notifications from that category?)
Or would you prefer this compromise solution which lets you do both, as proposed earlier by Brandon:
Hover over the notification and there's an "(x)" that appears on the right side.
Click that and it dismisses the notification but also asks "Do you want to hide all notifications of this kind?"
[y/n control]
- if "n/cancel", dismiss/hide current element, do nothing else.
- if "y" set "hide this type" preference for the user. show message about "you can set your preferences [[here]]"
We are debating whether to change the current version of Dismiss before we deploy to en-wiki, or remove it entirely, or try it out in its current form to get more community feedback.
Look forward to your recommendations! I have also attached below earlier email threads on this topic.
All the best,
Fabrice
_____________________________________
On Mar 6, 2013, at 9:25 AM, Fabrice Florin wrote:
> Thanks for all your good insights about this proposed feature, which we had planned to tackle after the first release.
>
> I find Facebook's approach to be pretty intuitive. It seems to be working well for people I know, and I have never heard anyone complain about it.
>
> With Echo, we also limit the number of notifications shown in the flyout based on your screen size, and support limited scrolling up to about 10 notifications. After that, you are encouraged to go to the 'All notifications' page, where you can find at least a week's worth of notifications (we currently support an infinite number of notifications on that archive page, but may have to cut back to a month's worth or so).
>
> Currently, we highlight new notifications in the flyout, so it's easy to tell them apart from old notifications, which seems effective. We then un-hilight them after you have viewed the flyout, which is also consistent with Facebook's approach. An argument could be made that perhaps we should only un-hilight that notification if you have actually clicked on it, but I believe we can wait on this until we have done a usability study.
>
> Since we are already using an 'X' button to dismiss notification types which you don't want to see anymore, it would be awkward to add on additional functionality to that button for dismissing just that particular notification, because it would clutter the user interface.
>
> So a 'Mark all as read' button might be a more effective way to address requests like Antoine's, as described in this proposed feature:
> http://www.mediawiki.org/wiki/Echo/Feature_requirements#Mark_all_as_read
>
> Though I would argue that the current UI provides a practical solution by automatically un-highlighting notifications you have seen in the flyout, as well as limiting the number of notifications in that flyout.
>
> Either way, I recommend that we wait on this feature until after the first release on Enwiki, which will generate a lot of user feedback which may provide more insights from our community.
>
> I do not support the second suggestion to enable viewing all notifications in the flyout, which would seem highly impractical to me. That's what the "All-notification" page is for, and it's only a click away.
>
> My 2 cents,
>
>
> Fabrice
>
>
> On Mar 6, 2013, at 8:47 AM, Luke Welling WMF wrote:
>
>> The Facebook approach is nice. The number they show initially varies with screen resolution and their scrolling and lazy loading work well.
>>
>> Most of it would be relatively easy to copy, although I suspect a lot of testing (or a lot of bug reports) have gone into correctly guessing the number of elements to show based on screen size.
>>
>> The best thing imho about their approach is that they react to all page visits, and very clearly show a bold notification for a notification sent after you visited that page and a more subtle version for a notification that you have already seen the triggering change for.
>>
>> That's how they solve the feeling of being overwhelmed by notifications. It keeps the new number down and means that a new notification should only refer to a change you have not seen.
>>
>> Sadly most people (including us) compromise and show notifications as "new" if you have not seen the notification before, and clear their new status before you click through rather than maintaining the relationship between trigger and notification to give a more accurate version of "new".
>>
>> The Quora compromise on the same UI feature is different but silly. They keep notifications marked new until you manually clear them. I rarely use Quora and have a completely useless readout that tells me I have 200 new notifications.
>>
>> Unfortunately I think adding "untriggers" alongside all the notification triggers is significant work, so it should remain a potential future enhancement.
>>
>> Luke Welling
>>
>>
>> On Tue, Mar 5, 2013 at 9:13 PM, Erik Moeller <erik(a)wikimedia.org> wrote:
>> On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari <rkaldari(a)wikimedia.org> wrote:
>> > Both Antoine (hashar) and Reedy have mentioned that they want the ability to
>> > remove individual notices after they are read (or clear all read
>> > notifications) from the flyout.
>>
>> One thing I'm wondering about is whether the high number of notifs
>> that are immediately displayed when you click may be contributing to
>> that - the feeling of being overwhelmed by old notifs + desire to make
>> some disappear. FB/web has a pretty sophisticated approach:
>>
>> 1) On first click you have a smaller window of notifications (4-5).
>> 2) Once you attempt to scroll the notifs list expands vertically to
>> accommodate a longer list.
>> 3) Scrolling supports dynamic loading of additional notifs for roughly
>> a week's of backlog (which seems to be identical to what's available
>> in "See all").
>>
>> --
>> Erik Möller
>> VP of Engineering and Product Development, Wikimedia Foundation
>>
>> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>>
>> _______________________________________________
>>
> On Mar 5, 2013, at 5:51 PM, Steven Walling wrote:
>
>>
>> On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari <rkaldari(a)wikimedia.org> wrote:
>> Both Antoine (hashar) and Reedy have mentioned that they want the ability to remove individual notices after they are read (or clear all read notifications) from the flyout.
>>
>> This I definitely agree with. You see this pattern in notifications in several contexts (Android ICS has it, Quora, FB I think?).
>>
>>
>> I'm not sure this is a great idea. If someone really wants to focus on viewing and responding to all unread notifications, asking them to go to a queue of it is likely the simplest and best UX choice IMO.
>>
>>
>> --
>> Steven Walling
>> https://wikimediafoundation.org/
>> _______________________________________________
>
>
On Jan 11, 2013, at 11:59 AM, Fabrice Florin wrote:
I agree with Kaldari on this point.
We need to keep this feature simple - and make it easy for users to turn it on or off.
We already have a user preference for it here:
http://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-echo
Currently, it disables email notifications only. But given that Wikipedians may want more control, a case could be made that these preferences could apply to both onsite and email. Or we could have separate checkboxes for these options, for even more granularity, as Google does (see screenshot).
Another option is to provide the dismiss option in the flyout, which we discussed in a separate thread, as Facebook does (see screenshot). This would enable users to completely remove notification types they don' want, both onsite and by email.
I propose we discuss this with Vibha during our meeting with her on Monday and reach a resolution then. If the solution is simple, we can push it in our next deployment on Thursday.
Until then, please turn off the user preference for this feature if it really bothers you.
Thanks,
Fabrice
On Jan 10, 2013, at 1:50 PM, Brandon Harris wrote:
On Jan 10, 2013, at 1:46 PM, Matthew Flaschen <mflaschen(a)wikimedia.org> wrote:
I agree. Not just, "dismiss this one", but "Don't show this type of
notification again" right on the notification itself (not necessarily
those phrasings).
Hover over the notification and there's an "(x)" that appears on the right side.
Click that and it dismisses the notification but also asks "Do you want to hide all notifications of this kind?"
[y/n control]
- if "n/cancel", dismiss/hide current element, do nothing else.
- if "y" set "hide this type" preference for the user. show message about "you can set your preferences [[here]]"
---
Brandon Harris, Senior Designer, Wikimedia Foundation
On Thu, Jan 10, 2013 at 1:33 PM, Fabrice Florin <fflorin(a)wikimedia.org> wrote:
I agree with Matt and Oliver as well.
I don't think we can avoid giving people individual control of which notifications they receive.
But I definitely think that adding a dismiss option in the flyout is an effective way to give people that control, so they don't have to go to the preferences page if they don't want to.
I also think that bundling can help in a number of ways, as outlined in my feature list below (I am including the entire thread, to make sure nobody feels left out from that discussion)
I will create a feature requirement stub for both options (and a few more) in coming days, and we can prioritize them as a team in next week's planning session.
But this discussion is touching upon the central challenge for this product: how to make sure that we inform people without spamming them.
It will take us a while to completely solve this challenge, but we should not ship anything that doesn't have some good solutions to this difficult problem, IMHO.
Cheers,
Fabrice
On Tue, Jan 8, 2013 at 10:35 PM, Erik Moeller <erik(a)wikimedia.org> wrote:
On the "easy to disable" front, I'm not sure if this is on the roadmap
already, but having an inline way to dismiss notifications of a
certain type would IMO be nice, e.g. a simple "Disable this type of
alert" link within the actual notification itself.
On 9 January 2013 11:35, Oliver Keyes <okeyes(a)wikimedia.org> wrote:
On 9 January 2013 06:47, Steven Walling <swalling(a)wikimedia.org> wrote:
Great idea! Giving people an immediate touch point means they feel like they have control, like swatting a fly.
Forwarding this to the list because Jake was having some problems with
Mailman. - THO
---------- Forwarded message ----------
From: Jacob Orlowitz <jorlowitz(a)gmail.com>
Date: 29 March 2013 23:43
Subject: Re: [EE] The Wikipedia Adventure as a GuidedTour
To: ee-owner(a)lists.wikimedia.org
Hey folks :)
I'm super excited about this project. I think you've created a great tool
in guided tours and I'm looking forward to utilizing it to its full
potential and in some new and perhaps unexpected ways. I'm going to pop
into IRC next week to introduce the concept a bit more fully and look
forward to sharing ideas. Just for clarity, I'm well aware that this
project has to happen independent of EE involvement... That said, I know
you're a great resource of experience and knowledge about attracting new
editors, and I hope to pick up some tricks and guidance as I move forward.
Best,
Jake Orlowitz (Ocaasi)
>
> On Fri, Mar 29, 2013 at 6:51 PM, Matthew Flaschen <mflaschen(a)wikimedia.org
> > wrote:
>
>> On 03/07/2013 07:23 PM, Siko Bouterse wrote:
>> > This newest grant proposal is actually to use the existing functionality
>> > of Guided Tours and add a narrative and gamification elements on top of
>> > it using simple on-wiki tools in order to build The Wikipedia Adventure
>> > on-wiki (eliminating the need for separate dev or hosting).
>>
>> Ocaasi's proposal was just approved as an Individual Engagement Grant.
>> https://meta.wikimedia.org/wiki/Grants:IEG/The_Wikipedia_Adventure
>>
>> Congratulations! :)
>>
>> Matt Flaschen
>>
>
>
>
--
Jake Orlowitz
Wikipedia: Ocaasi <http://enwp.org/User:Ocaasi>
Facebook: Jake Orlowitz <http://www.facebook.com/jorlowitz>
Twitter: JakeOrlowitz <https://twitter.com/JakeOrlowitz>
LinkedIn: Jake Orlowitz<http://www.linkedin.com/profile/view?id=197604531>
Email: jorlowitz(a)yahoo.com
Skype: jorlowitz
Cell: (484) 684-2104
Home: (484) 380-3940
--
Thehelpfulone
https://meta.wikimedia.org/wiki/User:Thehelpfulone
Hi all,
This week the "Getting Started" feature by the Editor Engagement
Experiments team has been on hold while we work on future designs, data
analysis, and Echo notifications to go with it, but we did deploy a few
significant updates today...
*Account creation and login redesign: *We turned off the experimental
implementation of the new account creation interface on English Wikipedia.
S Page, Munaf, and the rest of the team have been hard at work prepping a
version of both the account creation and login redesign for MediaWiki core,
and we need to turn off the previous version to make way.
Commits for this are undergoing review, and after they're merged and the
next biweekly MediaWiki release happens, you'll be able to test it out and
give us feedback on an opt-in basis locally, before it's made the default
everywhere. Look for another announcement about that in the coming weeks. :)
*Guided tours: *We added GuidedTour to Portuguese Wikipedia, bringing it to
a total of about 15 communities where you can build and use tours.
*Last but not least: *We removed Extension:LastModified (the experiment
with adding a timestamp of the last change, linking to the history). This
was an experiment that we decided not to make a permanent feature since it
didn't really lead to any gains in active contributors to articles. Some
community members have expressed interest in the feature, so if you're
looking for a side project that needs some love and care, this extension is
ripe for cleanup and redeployment.
--
Steven Walling
https://wikimediafoundation.org/
> On 26 March 2013 18:37, Steven Walling <swalling(a)wikimedia.org> wrote:
>
> On Tue, Mar 26, 2013 at 11:34 AM, Oliver Keyes <okeyes(a)wikimedia.org> wrote:
> I got one too. My question (asked on IRC, but throwing out here for wider discussion): what's the rationale with directing people to the non-secure site? Did Ops object to https?
>
> For reference: our current emails direct to vanilla HTTP, e.g. non-Echo stuff. It might be a more general request to make of Ops.
>
> On Tue, Mar 26, 2013 at 9:00 PM, Fabrice Florin <fflorin(a)wikimedia.org> wrote:
>
> On Mar 26, 2013, at 5:43 PM, Oliver Keyes wrote:
>
>>
>>
>> On 27 March 2013 00:37, Fabrice Florin <fflorin(a)wikimedia.org> wrote:
>> Thanks, Oliver.
>>
>> I would give the 'HTTPS' feature a lower priority than getting Echo deployed on time. This is something we can revisit after we are deployed, I don't view it as a blocker for now.
>>
>> Sure, I don't think it's a blocker at all. But it's not a particularly big change, either ;p.
>
> Cool. I just want us focused on the most important features first, so we can ship on time ;o)
On Mar 26, 2013, at 7:49 PM, Luke Welling WMF <lwelling(a)wikimedia.org> wrote:
> The easy way of changing to https looks to be adding a single character to the definition of $wgServer in LocalSettings.php.
$wgServer is used everywhere, I believe even for reader access, so I vote strongly against this change. ;-)
Normally the correct way of handling this is WebRequest::detectServer() which uses the protocol of the user's browsing state (if https, then https). I take this is a problem because the messages are decoupled between the event trigger and the recipient?
BTW, this sort of mediawiki discussion should probably be on a lis where much more experienced mediawiki devs can answer, so I'm moving it there.
>
> That would change it in a few other places though, so sounds like 1 second of editing and 1 day of testing.
>
> We could hack it in just for Echo, but that would either be hacky and specific to targeted installations or break on installs that don't have identical http and https urls.
BTW, my opinion is I'm okay with using http://... ($wgServer) right now for release and just capturing this request as a bug in bugzilla or in Trello for now.
Hi all,
I've been playing around with Echo on MediaWiki.org and noticed that in my
preferences I can configure a number of different notifications. (See
https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-echo)
I've also tested the User Right notifications that were just deployed and
whilst you receive an email when you have a user right *added *to your
account, you don't currently get one when a user right is *removed *from
your account.
That's probably an oversight, but from what I've been told the option to
opt out from any email notifications intentionally isn't available so as to
reduce the number of preferences for users to configure. Another
justification is that a user is unlikely to have their user rights changed
too often, so email traffic should be minimal.
This seems reasonable, but for future notifications, how are we going to
decide whether something is worth a preference or not? I'm thinking that
anything that technically affects your editing, e.g. a notification that
you've been blocked or renamed (if Echo supports that in the future) would
be something that probably shouldn't be opt-out-able.
Can anyone think of any other notifications that should not be opt-out-able
(or does anyone think that all notifications should be individually
opt-out-able?)
--
Thehelpfulone
https://meta.wikimedia.org/wiki/User:Thehelpfulone
Hello everyone,
We'd like to give you a quick update on Echo and let you know about today's deployment on MediaWiki.org.
The project is coming along nicely, and we keep adding new features every week. Here are some highlights.
1. Today's deployment
Benny and Kaldari just deployed a couple new features on MediaWiki.org today:
• Dismiss (turn off notification types from the flyout or all-notifications page)
• Web Preferences (control which notification types to include on your flyout or all-notifications page)
These features are not in their final form yet, but already provide a lot more control over which notifications you receive on the web or via email. Stay tuned for more …
If you experience any issues, please file a bug here on Bugzilla, or post a note on this talk page.
For detailed instructions on how to test the current version of Echo, check out this updated testing page:
https://www.mediawiki.org/wiki/Echo_(Notifications)/Testing
2. Next features
Our next Echo deployment is now scheduled for the week of March 4th.
The team is now working on these features for that deployment:
• Bundling
• JobQueue
• Metrics
• HTML Email
Learn more on our feature requirements page:
https://www.mediawiki.org/wiki/Echo/Feature_requirements#Metrics
3. Next notifications
We aim to develop these notifications for our first release:
• User Mention
• Welcome (in collaboration with E3)
• How to use your watchlist (in collaboration with E3)
• Thank you (positive notification)
• User rights (power user request)
Here's a short list of notifications planned for our first release:
https://www.mediawiki.org/wiki/Echo/Feature_requirements#First_Notifications
4. Project Goals
We are on track for a first limited deployment on the English Wikipedia in late March/early April, if all goes according to plan.
Here are our goals for this quarter (January-March 2013):
• focus on new users (but make it usable by experienced editors)
• complete core features (flyout, "archive", prefs, job queue, bundling, metrics, HTML email)
• add a few more notifications ("happy path" for new users, useful notices for power users)
• deploy limited release on en-wiki (different defaults for new and experienced users)
• fix bugs + critical feature tweaks (as needed, prioritized by urgency)
• provide in-house developer support (through hooks, i18n and dev guidelines)
• estimate maintenance + i18n support (for 2013-2014 plan)
Find out more in this short-term timeline and longer-term roadmap, as well as these project slides.
Enjoy!
Fabrice and the Echo team
_______________________________
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/
Hi folks,
I am happy to report that we deployed an updated version of Article feedback v5 on the German Wikipedia yesterday, at long last. :)
This new version includes these new features:
• Better feedback filters
• Simpler moderation tools for editors
• Separate reader moderation tools
• Discuss on talk page / contact post author
The release went well and the tools are now being tested by German community members. You can see these new features in action on this central feedback page for the German Wikipedia, where feedback from about 13,000 articles is being collected:
https://de.wikipedia.org/wiki/Spezial:Artikelr%C3%BCckmeldungen_v5
If you would like to test the new features on the German Wikipedia, please restrict your posts and moderations to this minor test page:
http://de.wikipedia.org/w/index.php?title=Spezial:Artikelr%C3%BCckmeldungen…
If you prefer to test in English on our prototype site, visit this testing page on MediaWiki:
http://www.mediawiki.org/wiki/Article_feedback/Version_5/Testing
We've updated our help pages on MediaWiki to describe all the new features that are being deployed:
http://www.mediawiki.org/wiki/Article_feedback/Version_5/Help/Editors
Next, we are planning to deploy Article feedback to French Wikipedia next Tuesday, March 26 (starting with just a few articles, then going up to 42,000 articles a few weeks later). We will also be releasing this new tool on the English Wikipedia next Tuesday (that release is being delayed so we can complete the feedback data conversion -- as well as disable the 'feedback from watched pages' feature, which is causing database cache issues). Note that AFT will only be enabled on an opt-in basis on the English Wikipedia, as requested by the community in last month's RfC; but many editors have already started to re-enable AFT5 for articles they are watching, and we hope the tool will continue to help them and others improve Wikipedia based on reader feedback in coming months.
To track this multi-site release, visit this Etherpad page, which is being updated every day and includes a list of known issues:
http://etherpad.wikimedia.org/AFT5-release
This will be our final release for AFT this fiscal year. Our current plan is to complete these three deployments, then monitor activity on the English, French and German Wikipedias in the next couple months and wait for their communities to vote on a wider release. If these pilots are successful, we will consider supporting a few more deployments this summer, for projects that have reached consensus for a wide release of the tool (so far, we've received a variety of requests from the Chinese, Hungarian, Kannada and other Wikipedias, as well as Commons). A more detailed roadmap for this product is outlined on this 2013 release plan:
http://www.mediawiki.org/wiki/Article_feedback/Version_5/Release_Plan_2013
I would like to take this opportunity to give a big round of applause to lead developer Matthias Mullie for this major milestone, as well as thank Benny, Kaldari, Luke, S Page, Aaron and Asher for carefully reviewing all his new code -- and Chris, Oliver and others for helping test it. Special thanks as well to our partners at the German Wikipedia: Denis Barthel, Sebastian Peisker and Raimond Spekking, who have worked beyond the call of duty to make this release possible -- as well as to Benoit Evellin, who is spearheading the French deployment. Last but not least, we are very grateful to all other colleagues who contributed to this final phase: Dario, Philippe, Roan, Howie, Terry and Erik, to name but a few. It's a true pleasure to be working with you all!
I will send another update after we deploy the new features on the French and English Wikipedias.
Onward!
Fabrice
_______________________________
Fabrice Florin, Product Manager
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
Donate to keep Wikipedia free:
https://donate.wikimedia.org/
Hi SJ,
Thanks so much for your kind words -- and for your thoughtful recommendations on the English Wikipedia RfC, which were really appreciated ;o)
I also forgot to thank one more team member, designer Pau Giner, who streamlined the user interface to make it a lot easier to moderate feedback.
Some of the first comments we are getting on the German Wikipedia talk pages have noted this improvement -- and a former critic of the tool just said that "the new system is much better, clearer, faster".
Kudos to all who made this possible!
Fabrice
On Mar 20, 2013, at 5:04 PM, Samuel Klein wrote:
> This is great. Thanks for the update, Fabrice, and for shepherding
> this through many different community discussions.
>
> SJ
>
> On Wed, Mar 20, 2013 at 6:19 PM, Fabrice Florin <fflorin(a)wikimedia.org> wrote:
>> Hi folks,
>>
>> I am happy to report that we deployed an updated version of Article feedback v5 on the German Wikipedia yesterday, at long last. :)
>>
>> This new version includes these new features:
>> • Better feedback filters
>> • Simpler moderation tools for editors
>> • Separate reader moderation tools
>> • Discuss on talk page / contact post author
>>
>> The release went well and the tools are now being tested by German community members. You can see these new features in action on this central feedback page for the German Wikipedia, where feedback from about 13,000 articles is being collected:
>> https://de.wikipedia.org/wiki/Spezial:Artikelr%C3%BCckmeldungen_v5
>>
>> If you would like to test the new features on the German Wikipedia, please restrict your posts and moderations to this minor test page:
>> http://de.wikipedia.org/w/index.php?title=Spezial:Artikelr%C3%BCckmeldungen…
>>
>> If you prefer to test in English on our prototype site, visit this testing page on MediaWiki:
>> http://www.mediawiki.org/wiki/Article_feedback/Version_5/Testing
>>
>> We've updated our help pages on MediaWiki to describe all the new features that are being deployed:
>> http://www.mediawiki.org/wiki/Article_feedback/Version_5/Help/Editors
>>
>> Next, we are planning to deploy Article feedback to French Wikipedia next Tuesday, March 26 (starting with just a few articles, then going up to 42,000 articles a few weeks later). We will also be releasing this new tool on the English Wikipedia next Tuesday (that release is being delayed so we can complete the feedback data conversion -- as well as disable the 'feedback from watched pages' feature, which is causing database cache issues). Note that AFT will only be enabled on an opt-in basis on the English Wikipedia, as requested by the community in last month's RfC; but many editors have already started to re-enable AFT5 for articles they are watching, and we hope the tool will continue to help them and others improve Wikipedia based on reader feedback in coming months.
>>
>> To track this multi-site release, visit this Etherpad page, which is being updated every day and includes a list of known issues:
>> http://etherpad.wikimedia.org/AFT5-release
>>
>> This will be our final release for AFT this fiscal year. Our current plan is to complete these three deployments, then monitor activity on the English, French and German Wikipedias in the next couple months and wait for their communities to vote on a wider release. If these pilots are successful, we will consider supporting a few more deployments this summer, for projects that have reached consensus for a wide release of the tool (so far, we've received a variety of requests from the Chinese, Hungarian, Kannada and other Wikipedias, as well as Commons). A more detailed roadmap for this product is outlined on this 2013 release plan:
>> http://www.mediawiki.org/wiki/Article_feedback/Version_5/Release_Plan_2013
>>
>> I would like to take this opportunity to give a big round of applause to lead developer Matthias Mullie for this major milestone, as well as thank Benny, Kaldari, Luke, S Page, Aaron and Asher for carefully reviewing all his new code -- and Chris, Oliver and others for helping test it. Special thanks as well to our partners at the German Wikipedia: Denis Barthel, Sebastian Peisker and Raimond Spekking, who have worked beyond the call of duty to make this release possible -- as well as to Benoit Evellin, who is spearheading the French deployment. Last but not least, we are very grateful to all other colleagues who contributed to this final phase: Dario, Philippe, Roan, Howie, Terry and Erik, to name but a few. It's a true pleasure to be working with you all!
>>
>> I will send another update after we deploy the new features on the French and English Wikipedias.
>>
>> Onward!
>>
>>
>> Fabrice
>>
>>
>> _______________________________
>>
>> Fabrice Florin, Product Manager
>> Wikimedia Foundation
>> http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
>>
>> Donate to keep Wikipedia free:
>> https://donate.wikimedia.org/
>>
>
>
>
> --
> Samuel Klein @metasj w:user:sj +1 617 529 4266
_______________________________
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/