EE

ee@lists.wikimedia.org

502 discussions

Article feedback update: New version on the German Wikipedia!
by Fabrice Florin 26 Mar '13

26 Mar '13

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/

1 1

Re: [EE] Article feedback update: New version on the German Wikipedia!
by Fabrice Florin 26 Mar '13

26 Mar '13

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/

5 8

Article Feedback Tool and inline comments
by Matthew Flaschen 21 Mar '13

21 Mar '13

While looking through https://meta.wikimedia.org/wiki/User:Sue_Gardner/Wikimedia_Foundation_Guidi…, it occurred to me that inline comments would be powerful addition to AFT. Basically something like https://en.wikipedia.org/wiki/Stet_%28software%29 integrated into MediaWiki. I think it would help people make useful comments that could more quickly be acted on/resolved. Matt Flaschen

7 14

Re: [EE] AFTv5 watchlist - Possible issue for Flow too?
by Terry Chay 21 Mar '13

21 Mar '13

On Mar 21, 2013, at 1:35 PM, Asher Feldman <afeldman(a)wikimedia.org> wrote: > > To avoid any misunderstandings, we are not planning to do any watchlist-related notifications for Echo. > > That's unfortunate. But regardless, narrow product roadmaps shouldn't limit how we resuse any product or technology to improve the site or fix a broken feature. To be more specific. I think the gist I got from product is that watchlists are stuff that are "streamlike" in behavior, not directly actionable in themselves. Stream stuff goes in Flow. An analogy would be Facebook Messages vs. Facebook Feed. The former would be in Echo, the latter in Flow. Eventually it is possible that Flow would obsolete the need for the Watchlist page as you mentioned (I'll defer to Brandon). I believe in the meantime the Microdesign team has some planns to update some of the UI of watchlist, but it's UI only, and relatively small <http://www.mediawiki.org/wiki/Micro_Design_Improvements/Watchlist_UI>. Take care, terry

1 0

Today's E3 deployment, and the next phase of GettingStarted
by Steven Walling 21 Mar '13

21 Mar '13

Hi everyone, Earlier today, Editor Engagement Experiments deployed some updates to our Getting Started onboarding experiment, updates that move us in to a a new phase of development that is pretty important. In addition to some changes in the text of the page and interface design, we deployed a new EventLogging schema which will let us know which of the three tasks in the page are more popular with new users. We also enabled a split test, where half of users get the old landing page with no tasks, to be able to figure out whether we're overall helping or hurting new editor engagement with this version. Perhaps most importantly, we switched from relying on User:SuggestBot to generate the tasks, to doing it in the GettingStarted extension itself. The backend for doing this is still very new and somewhat fragile, but now we have the ability to draw from whatever number and type of categories we want, to create a task list. You can see in Special:GettingStarted now on English Wikipedia that we can already generate a new list of articles for every viewer, though imperfectly. *TL;DR *This is a big step forward, for two reasons: 1. it means that we can experiment more easily with what kind of tasks to deliver, and how to present them best 2. we're much closer to being able to roll out GettingStarted to Wikipedias other than English. The main requirement still is that you have to-do items in categories, like Wikipedia:Backlog on English Wikipedia. -- Steven Walling https://wikimediafoundation.org/

2 4

Re: [EE] [Ops] [wikimedia #4785] Email accounts for Echo notifications
by Terry Chay 21 Mar '13

21 Mar '13

TLDR: The ticket sounds much worse than it is. The basic request: Echo (is currently) will be sending e-mails appearing as from four e-mail addresses: * (currently): notifications(a)mediawiki.org (for mediawiki.org notifications) * (currently): no-reply-notifications(a)mediawiki.org (for mediawiki.org notifications) * (April): notifications(a)wikipedia.org (for enwiki notifications) * (April): no-reply-notifications(a)wikipedia.org (for enwiki notifications) Currently, Pre-echo talk-page notifications are sent through the system as from two e-mail address: * from: wiki(a)wikimedia.org * Reply is: reply(a)not.possible If necessary, can ops makes sure the new addresses go down a black hole? :-) If possible, logging the counts of the number of e-mails sent to no-reply-* before deletion would be nice. Outgoing: The RT ticket only covers a confirmation that incoming e-mails are dropped. For outgoing e-mails, right now, e-mails are sent through the current SMTP/Sendmail infrastructure for talk page notifications (pre and post echo) and this is unchanged. The load is in the same ballpark of pre and post echo with some modest increase expected due to (mostly) new user focused notifications. Expectation of load: * Most of echo currently just replaces the existing talk page e-mail notifications, so expect the volume to be relatively unchanged (or a modest increase in traffic) than currently * Features like watchlist notifications do not exist in echo, if they did, they'd not send e-mail notifications due to flood. These "stream" like notifications would be part of "Flow", not "Echo". * Over time, this may increase as Echo becomes a more permanent part of the wiki infrastructure, so some sort of TechOps monitoring (if not already in place) is advisable at some point. * The EE team will give more accurate estimates going forward Process stuff: * Ideally, this would have been caught and requested by a SRE * Until then, in the medium term Luke Welling will substitute as a point of contact in Features with Ops. * For this RT, in the short term Ryan Kaldari will be the engineering point of contact in Features with Ops with Luke assisting. On Mar 20, 2013, at 5:52 PM, Faidon Liambotis <faidon(a)wikimedia.org> wrote: > On Wed, Mar 20, 2013 at 11:44:18PM +0000, Fabrice Florin via RT wrote: >> Dear Wikimedia Operations, >> >> Please set up the following 4 email accounts for the Echo notifications >> project, if they are available: >> >> <snip> >> >> We'd be grateful if you could set these up this week, as we plan to start >> using these addresses widely on our live mediawiki.org and >> wikipedia.orgsites by the week of March 25, 2013. >> >> <snip> >> >> Note that we expect a very high volume of emails to be sent 'from' the >> < notifications(a)wikipedia.org> address this year (e.g. millions of >> emails per month), and a lower volume of responses 'to' the <no-reply> >> addresses (e.g. thousands of emails per month). > > As far as I know, this deployment wasn't announced before in ops@ or > engineering@, it wasn't mentioned on the last (or any previous) project > & deployment meetings and it's not on the roadmap update sent by Greg to > engineering@ earlier this week. I also don't see anything relevant or > clear enough in the engineering roadmap spreadsheet (there's a "[Mar 21] > mediawiki release" entry, but I don't understand what that means). The plan is to roll out a new version of echo on wikimedia.org today (Thursday March 21). Then it would be rolled out (almost) two weeks later on enwiki on April 2nd(?) contingent on no unresolved issues and exchanging release dates with AFTv5 according to plan. I believe the Engineerng Projects Roadmap[1] reflect this, as these dates became more settled (I believe it has been on the Roadmap for months, but the dates were not put in until last week or earlier this week). The need for an e-mail address was not reflected in the above, due to a dropped ball on our part. Partially this is I didn't even know the requirement until yesterday. :-) The requirement has been documented in the Echo Feature's requirements wiki page[2] since at least late November, so I think nobody put 2 and 2 together because it's placement in the sample message on the document (one would have to also know that this is not the e-mail address of existing notifications[3]). Hopefully this sort of shortfall would be caught in the future by a SRE. > I don't think it's reasonable to drop this on ops with two working days > notice and expect this to be implemented in time for such a deadline of > yours. This is valid. I'm not certain myself if this is a requirement for release or as urgent as it appears in the ticket. It is important to note how existing notifications are currently handled[3] (without Echo). Currently Talk Page notifications are sent from "wiki(a)wikimedia.org" with a reply-to being "reply(a)not.possible." The impression I get is that Legal has determined this is needs to be changed going forward: 1) wikimedia.org domain should be reserved for WMF-related stuff 2) the domain of the originating wiki's notification should identify itself as the origin of the notification 3) As for "reply(a)not.possible" I don't want even to know what the legal ramifications are there. ;-) My understanding is that LCA put this into a requirement in Echo early in the process to fix this. Since 90%(?) of echo's e-mail notifications are simply a replacement of the current talk page notification, fixing this technical debt requirement sidecar'd Echo'. > It's also not reasonable in my opinion to *make* such plans and request > the operations group to implement them without ever involving them on > decisions for such a system and without getting those plans vetted by > our architects (unless this has happened; apologies for the > miscommunication if so). My thinking as to what happened was that long ago, someone cheekily put it wiki(a)wikimedia.org and reply(a)not.possible to satisfy the engineering requriements of talk page notification, and the Community team has been dealing with the consequences every since. Since Echo's notifications replace this one, it made sense to request to fix this problem. When the request percolated through the system, it was observed that email notification address creations were always handled by IT, not Ops (because of the wikimedia.org domain name), so the channels request went through there. It was then determined by IT that they control of the MX on mediawiki.org and wikipedia.org domains belongs to Ops and the request was forwarded there. (This kind of makes me wonder if the original choice of using wiki(a)wikimedia.org was designed to avoid making Ops aware of talk page e-mail notifications being used at all.) If necessary, pursuant of LCA approval, leave this technical debt unpaid and go back to the original wiki(a)wikimedia.org and reply(a)not.possible, as these are just configuration changes in LocalSettings.php. Almost all the Echo e-mail traffic volume right now simply replaces the existing Talk page notification system with the current one. > Just to give a few examples: > > You mention "high volume" and "millions" but not much more than that. > How many millions is "millions"? How high volume are we talking about? > At what rate and what about peaks/bursts? We can't "just" create an > alias for those domains if it's high, unless you want all of foundation > staff & list mails to be stuck in two poor old overloaded machines with > queues filed with presumably hundred of thousands of bounces. Or maybe > that's just too far fetched, but again, we can't just plan and deploy > lightly and without numbers. They'll have accurate estimates, but this part of the request is playing a bit loose with the timeline. First, it is important to emphasize that this is sent through the same SMTP/Sendmail that we're using for talk page notifications, the only thing changed is the from and reply to: Currently and for the release Echo is just going to replace the existing talk page e-mail notification so e-mail traffic volume is essentially unchanged delta the following: * echo introduces some new notifications focused on new users (so at the rate of user-registration, we can expect extra e-mails to be sent (~30k/month?) * echo introduces a couple(?) new notifications focused on essential tasks that active editors/admins would like as e-mail notifications instead of checking pages manually. However, very few editors/admins are involved here so I'd expect this to increase ~100/month * echo introduces bundling, so if a user is being e-mailed too much, subsequent e-mails are throttled and bundled. so expect e-mail volume to decrease. This may change over time as Echo becomes more used, so if the current mailservers sending talk page notifications might get loaded at a rate that will increase faster than standard wiki growth. Some monitoring will be important going forward. > > What about the *outgoing* mail relay? What makes you think it's capable > of sustaining the volume you're about to send to it? It might be the > case, but this needs to be considered internally. The outgoing relay is the same as currently for talk page notications. In Mediawiki the PEAR Mail library is identical, the only difference is the payload can support HTML mimetype mail. > You also don't seem to have thought about VERP at all. How are we going > to invalidate non-existing, full or unavailable email addresses? Am I correct, VERP is for fixing broken outgoing e-mails that result in bounces? Echo uses whatever the existing solution is handled for talk page notifications. If there is none, then this is technical debt that Features should be working with Ops to eliminate going forward. > Why do you need the no-reply counts? How are going to use this > information? I don't know, Fabrice, can you field this request? I imagine this is a was introduced by LCA. I don't believe this is a requirement for Echo release. > I think I speak for the team when I say that this needs to be thought > and coordinated more and that we can't just drop everything we're > currently doing to do this within your deadline. I hope an explanation of the RT ticket has helped greatly toward tlowering the burden on ops. Beyond that, I'm sure we can make allowances to make this not be an undue burden on ops. [1]: https://docs.google.com/a/wikimedia.org/spreadsheet/ccc?key=0Aoizbfxc5g6KdE… [2]: http://www.mediawiki.org/wiki/Echo_(Notifications)/Feature_requirements#Ema… [3]: http://en.wikipedia.org/wiki/Help:Email_notification terry chay 최태리 Director of Features Engineering Wikimedia Foundation “Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.” p: +1 (415) 839-6885 x6832 m: +1 (408) 480-8902 e: tchay(a)wikimedia.org i: http://terrychay.com/ w: http://meta.wikimedia.org/wiki/User:Tychay aim: terrychay

1 0

Re: [EE] AFT Deployment going on right now - let me know when you're done
by Greg Grossmeier 21 Mar '13

21 Mar '13

Just pinging the e2 list so everyone knows. <quote name="Greg Grossmeier" date="2013-03-21" time="10:03:46 -0700"> > We have an emergency need to get wmf12 redeployed (it was rolled back > last night due to a crappy bug). > > Let me know when you're done with AFT deploy this morning, we want to > squeeze in between that and E3. > > Thanks. > > Greg > -- > | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | > | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D | -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

3 3

Wikipedia notifications by email
by Benoît Evellin 21 Mar '13

21 Mar '13

Hello ! On French Wikipedia, email notifications not enabled by default. So new users do not know when their talk page is modified, or when something change on their watchlist. On English Wikipedia, email notifications enabled by default, right ? How did you do that ? Is there a good feedback from new users ? Do whey complain about flooding ? Thanks for your answers, -- Benoît Evellin / User:Trizek Wikimédia France Volunteer www.wikimedia.fr

3 2

Possibly Relevant to Our Interests
by Brandon Harris 14 Mar '13

14 Mar '13

http://techcrunch.com/2013/03/14/mozilla-launches-open-badges-1-0-a-new-sta… --- Brandon Harris, Senior Designer, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

2 2

New article experience from @NYTimes
by Fabrice Florin 13 Mar '13

13 Mar '13

Here's some inspiration in our quest to modernize Wikipedia ... The New York Times is redesigning its Web site — starting with the article experience. Check out some of their elegant solutions for finding, viewing and talking about articles: http://nyti.ms/13TQxOH I like the simpler look and feel, with large photos, easy navigation and conversation space. This general direction and some of these ideas would seem appropriate for Wikipedia as well, to create a more inviting experience that encourages people to stay and help out. The NYTimes designers also broke new ground last year with Snowfall, if you haven't seen it already: http://nyti.ms/13TQzpC This cool montage of text, photos, graphics and videos engages the mind and the heart, and helps you learn faster, in different ways. I would love to see this type of multimedia integration in future versions of Wikipedia … Enjoy … Fabrice _______________________________ Fabrice Florin Product Manager, Editor Engagement Wikimedia Foundation http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)

7 7

← Newer
1
...
42
43
44
45
46
47
48
...
51
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

EE