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
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/
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
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 |
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
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)
Boldly forwarding an email that was sent to the Wikimedia Education list.
Pine
---------- Forwarded message ----------
From: Jane Park <janepark(a)creativecommons.org>
Date: Tue, Mar 12, 2013 at 3:05 PM
Subject: [Wikimedia Education] School of Open has launched!
To: Wikimedia Education <Education(a)lists.wikimedia.org>
Hey guys, in case you haven't seen School of Open launched its first set of courses today, including several on Wikipedia/Wikimedia: http://creativecommons.org/weblog/entry/37179.
Sign up for these facilitated courses
this week (sign-up will remain open through Sunday, March 17). These
courses will start the week of March 18 (next week!). To sign up,
simply click the “Start Course” button under the course’s menu
navigation on the left.
Copyright 4 Educators (US) – Sign up if you’re an educator who wants to learn about US copyright law in the education context.
Copyright 4 Educators (AUS) – Sign up if you’re an educator who wants to learn about Australian copyright, statutory licenses and open educational resources (OER).
Creative Commons for K-12 Educators – Sign up
if you’re a K-12 educator (anywhere in the world) who wants to learn
how to find and adapt free, useful resources for your classroom, and
incorporate activities that teach your students digital world skills.Writing Wikipedia Articles: The Basics and Beyond – Sign up
if you want to learn how to edit Wikipedia or improve your editing
skills — especially if you are interested in and knowledgeable about
open educational resources (OER) (however, no background in this area is
required).
All other courses are now ready for you to take
at any time, with or without your peers. They include:
Get a CC license. Put it on your website
– This course is exactly what the title says: it will help you with the
steps of getting a CC license and putting it on your work. It’s
tailored to websites, although the same steps apply to most other works. Open Science: An Introduction
– This course is a collaborative learning environment meant to
introduce the idea of Open Science to young scientists, academics, and
makers of all kinds. Open Science is a tricky thing to define, but we’ve
designed this course to share what we know about it, working as a
community to make this open resource better. Open data for GLAMs
(Galleries, Libraries, Archives, Museums) – This course is for
professionals in cultural institutions who are interested in opening up
their data as open culture data. It will guide you through the different
steps towards open data and provide you with extensive background
information on how to handle copyright and other possible issues. Intro to Openness in Education
– This is an introductory course exploring the history and impacts of
openness in education. The main goal of the course is to give you a
broad but shallow grounding in the primary areas of work in the field of
open education. A Look at Open Video
– This course will give you a quick overview of some of the issues,
tools and areas of interest in the area of open video. It is aimed at
students interested in developing software, video journalists, editors
and all users of video who want to take their knowledge further. Contributing to Wikimedia Commons
– A sister project of Wikipedia, Wikimedia Commons is a repository of
openly licensed images that people all over the world use and contribute
to. This challenge gets you acquainted with uploading your works to the
commons. Open Detective – This course will help you explore the scale of open to non-open content and how to tell the difference.
And more… check out all the courses at http://schoolofopen.org/.
--
Jane Park
Project Manager
Creative Commons
the School of Open, a collaboration with P2PU: http://schoolofopen.org/
Like what we do? Donate: https://creativecommons.net/donate/