GuidedTour is up on piramido again, with the latest getting started
tour. Now that the i18n jqueryMsg support is in core, it should be in
for good this time.
I also put up the latest version of the Special:GettingStarted page
(mostly Munaf's work, but with some JS I wrote), with everything except
for the images. Be sure to click on the question marks. In *addition*
to guided tours, GuidedTour can also be used for single-page tooltips
1. Go to http://piramido.wmflabs.org/wiki/Special:GettingStarted .
2. Click "List of Google Stuff". This will register it as a "task".
3. Go to
step will be made easier once the gettingstarted tour is finalized and
we decide whether to use querystring or cookie here).
4. Go through the tour (wording is not final).
Let me know what you think.
Just an FYI:
Kim Schoonover (who goes by Isarra on-wiki and IRC) is my intern for our Outreach Program for Women. She's working with me on Flow and learning about being devious (I'm planning to teach her all the dirty tricks).
She's in town for the week. We're going to lunch on Tuesday. You can come if you like.
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Starting on the 10th, we added a tag to English Wikipedia edits made via
the Special:GettingStarted interface. (It looks like "Tag: new editor
Dario has kindly added this to his dashboard of revision tags flowing from
RecentChanges, which includes mobile and VisualEditor as well.
Wanted to send this to we because people like Aaron may have ideas especially re happy path.
Tl;dr Howie would like to shift focus of default Echo notifications to ones that generate positive messages.
Sent from my <free corporate advertising removed at the request of the owner>
Begin forwarded message:
> From: Oliver Keyes <okeyes(a)wikimedia.org>
> Date: January 17, 2013, 8:01:25 AM PST
> To: Terry Chay <tchay(a)wikimedia.org>
> Cc: Fabrice Florin <fflorin(a)wikimedia.org>, Howie Fung <hfung(a)wikimedia.org>, Ryan Kaldari <rkaldari(a)wikimedia.org>, Benny Situ <bsitu(a)wikimedia.org>, Luke Welling <lwelling(a)wikimedia.org>, Matthias Mullie <mmullie(a)wikimedia.org>, Brandon Harris <bharris(a)wikimedia.org>, Vibha Bamba <vbamba(a)wikimedia.org>, Erik Moeller <erik(a)wikimedia.org>, Steven Walling <swalling(a)wikimedia.org>, Maryana Pinchuk <mpinchuk(a)wikimedia.org>, Dario Taraborelli <dtaraborelli(a)wikimedia.org>, James Forrester <jforrester(a)wikimedia.org>
> Subject: Re: E2 Planning Meeting Notes
> On 17 January 2013 07:56, Terry Chay <tchay(a)wikimedia.org> wrote:
>> Thanks for this summary.
>> I believe the purpose was to prepare for the E2 quarterly review (with respect to the Echo project, in particular, so this is excepting Flow (which hasn't been started) and AFTv5 (which is on another thread and will be heading toward completion)). Given that I think there were three outcomes we need to focus on with the realization that we'll have to present this to Erik and Sue:
>> 1. To note some unresolved action items
>> 2. To discuss what has been done for last quarter (for Echo and AFTv5, we should probably note that this is the first quarter of E2 team development for Echo because PageTriage ran over, and we note that AFTv5 lost Matthias for 1 month to WIkiVoyage)
>> 3. To give the plan for the next quarter
>>> We also discussed developing a few more notifications, if time allows, once core features are done. This small set of new notifications would be selected in consultation with the E3 team, Oliver and community members and be spread out between these user groups: new members, new editors and active editors.
>> With respect to (1) unresolved actions , there were three action items we need to resolve before the quarterly review. I think Fabrice is confusing these three in the sentence above (no worries, sometimes I can't read my notes either).
>> In my notes they are:
>> 1. Watchlists for E3
>> 2. Placeholder for power users
>> 3. Happy Path
>> Now I may have been too drunk to rattle that off the top of my head last night but I believe this means:
>> 1. Watchlists are a notification in plan but what this means was not specificed. Some of this sounds overlapping with E3's onboarding experiment ("did you know you have a watchlist?"), and some of it may be done in notifications (for instance, the first n times a click on watchlist (default off for experienced editors) could pop a notification saying there are new events in the watchlist until the user builds a habit. It makes sense to actually resolve with E3 team what that is since "n" at least and other things are probably best determined as an experiment and implemented by E3 (using the hooks already provided in Echo). We should sync up with them on what "watchlist notifications" mean.
>> 2. I'd like to find one or two low-risk power-editor notifications to be done for March as long as they can added under the following criteria
>> - will not delay the release
>> - are feasible, low effort in engineering (Kaldari and Benny approved)
>> - will be seen positively by the editor community (a feature they would actually want)
>> My thinking is If we don't do this, I'm worried that Echo will end up becoming a ghetto like MoodBar, or be seen by the editor community as being a thing that no real editor could use.. However, Echo is not LiquidThreads—our notifications system is widely perceived as ad hoc and broken. There should be some notifications that would give Echo a modest amount of utility to the power user, and they will welcome. I could be wrong so if Oliver can't find anything that Kaldari doesn't think is too much work, I'm not married here. (Suggestions for Oliver: 1) userrights notifications; 2) someone blocked has left a note on talk page (currently handled by editor habit of watchlist the talk pages of people they've blocked)).
> If Kaldari can verify they're not too much of a pain we can go with these - I'd like it if we could throw a core group of suggestions at editors and see what sticks.
>> 3. Howie has pointed out the current way MediaWiki interacts with the user are negative in nature (you've been reverted, etc.). A lot of studies have shown that it takes 5 positive reinforcements to make up for one negative one. Howie would like us to have that ratio or better in the notifications we send which he calls the "Happy Path." Notifications that provide a positive reinforcement should be added to the spec. Some thought on what those are needs to be discussed and spec'd.
> One idea I had for this yesterday; so, the main thing kicking us in the arse is that MediaWiki doesn't really have a way of registering that an edit is good. However: MediaWiki doesn't really register that edits are bad, either: a lot of that is done through third-party plugins like Huggle or bots like ClueBot - things patrolling for vandalism. When they see a good edit, they've got no way of saying anything and are silent. When they've got a bad edit, they warn/revert/whatever.
> What we might want to do is build a "your edit was fine! $thing reviewed it! Great job!" notification that can be kicked through the API. We can then hook into a lot of the third-party development that's been done on anti-vandalism tools. So, in this world, instead of "approve of edit (silently), disapprove (revert and warn)", Huggle/ClueBot/so on send a notification to the user who made the 'good' edit saying "this was good! Keep it up". We'd need to make puppy eyes at the third-party people to implement, but it's actually a lot less work than building the notification and also finding some trigger in MediaWiki for it to take its cues off, and has a better signal:noise ratio than any trigger I've yet heard discussed.
>> When 1-3 is resolved, I think we need to change the slide: https://docs.google.com/a/wikimedia.org/presentation/d/1ps7-i_fISUldycH1LFr…
>> (BTW I think this shouldn't be a GANTT chart (neither should the echo features slide before it). It makes engineering look like a factory. It should simply be a list of notifications for Q3 release (with a short description/example/mockup of what they mean/might look like), followed by a list (with no description) of features that might be considered later. Same goes for the echo features slide.
>>> Specific milestones for this quarter include:
>>> * Launch Echo first release on English Wikipedia by March 2013
>>> * Deploy Article Feedback to 100% on English Wikipedia by March 2013
>>> * Release first beta for Flow on MediaWiki by June 2013
>> As for (3) give guidance for Q3. The point is a list of stuff we want to do for the March release on enwiki in end of Q3. The idea here is to free up the team for continued development on Echo or transition to starting Flow in Q4 (with the target of end of Q4 release of Flow on mediawiki.org). (So milestones for this quarter are the first two, not the third.)
>> With respect to the first specifically, I modified/cleaned up the slide <https://docs.google.com/a/wikimedia.org/presentation/d/1ps7-i_fISUldycH1LFr…>:
>> • focus on new users (but make it usable by active editors)
>> • complete core features (flyout, "archive", prefs/userrights, job queue, bundling, metrics, HTML email)
>> • add a few more notifications (for new members/editors. active editors, "happy path")
>> • deploy limited release on en-wiki (default preferences depending on new/exisitng editor (new editor focused notifications (ex. pagelinks) default off))
>> • fix bugs + critical feature tweaks (as needed, prioritized by urgency)
>> • provide in-house developer support (through hooks, i18n and dev guidelines for teams like E3)
>> estimate maintenance + i18n support (2013-2014 plan)
>> [My changes:
>> - "archive" is in quotes because it is not persistent
>> - added "userrrights" to preferences (Kaldari)
>> - moved HTML e-mail to end of core features because it's a non essential deliverable (though it's almost done anyway)
>> - moved Howie's Happy Path into "few more notifications"
>> - merged new members/editors from new members and new editors
>> - changed the default preferences to note that some defaults actually dependent on who (for instance, if userrights gets it, that should be default on for existing users, not off, but things like e-mail notifications on pagelinks better be default off)
>> - explained what "in-house developer support" actually means (mediawiki hooks)
>> - changed localization (which is a translation task) to internationalization (which is a programming one)]
>> I question whether Flow should be mentioned in guidance since this is supposed to be a review meeting. So while it's a summary of prep, we shouldn't be presenting it until next quarter.
>> If anyone cares, here are my notes from the meeting:
> The notes align with my recollection of what was discussed.
> Oliver Keyes
> Community Liaison, Product Development
> Wikimedia Foundation
I saw this over vacation and have been meaning to respond.
I think Thehelpfulone raises a very important point. Echo does rely in
email notifications. Also, email is where users actually are and until new
users get into the habit of coming to our sites directly, email is a way to
draw them back in.
Does anyone have the answer to question #1 below (why email is optional in
the first place?).
On Sat, Dec 29, 2012 at 12:59 AM, Thehelpfulone <thehelpfulonewiki(a)gmail.com
> Hi guys,
> Sending this to the main EE list as I imagine E2 may also have some useful
> input. I just watched one of the account creation videos from the
> UserTesting.com dashboard which Steven also published at
> https://commons.wikimedia.org/wiki/File:ACUX_user_test_2.ogv and an
> interesting point that the tester made was that she was happy that the
> email address was optional, because that meant that she didn't have to give
> it, and that she never gave optional information.
> A couple of questions:
> 1) Does anyone know why we made email optional in the first place - was it
> because it wasn't a core part of the wiki functionality given that it was
> previously only used for password resets, or was it something to do with
> storing the least amount of data about our users as possible?
> 2) With Echo and Flow and all the new notification stuff that is planned,
> and given Email notifications <https://www.mediawiki.org/wiki/Echo/Feature_requirements#Email_notifications>still
> play a big part of it, should we be considering trying to actually get *more
> *email addresses for users who sign up and so either make it less clear
> that email is optional (probably not so good from a usability standpoint?)
> or even go so far as to make email required?
> As an alternative to this we could give reasons why providing your email
> address is a good, but I worry that putting too much detail on the new
> account creation page would cause a TL;DR like the tester made quite clear
> at https://commons.wikimedia.org/wiki/File:Account_creation_test_2.ogv.
> If this discussion has already been had, apologies - I've just joined this
> list and couldn't find anything from a brief skim of the archives.
> ee mailing list
On 01/10/2013 01:36 PM, Ryan Kaldari wrote:
> I'm fine with either of these choices, but we have to actually reach
> some kind of consensus on this.
>From where I'm standing, I think there should be sane defaults, but each
notification type should be separately configurable.
If not, you risk people turning everything off, or worse, using the wiki
Thanks to those of you who are helping spread the word about our software engineer job for the E2 editor engagement team!
If any of you use Facebook, I encourage you to share this post, which Jimmy Wales just shared on his page:
Or use other social channels, as you see fit: tweet about it (see links below), email friends who know good engineers, post it on good job boards you know about, etc.
It's really important that we find a new team member soon, if we want to accomplish all the goals now on our plate for Echo, Flow and other editor engagement projects.
Thanks in advance for getting the word out!
On Jan 10, 2013, at 10:47 AM, Fabrice Florin wrote:
> Hi guys,
> As you may have heard, we're looking to hire a new software engineer for the E2 team.
> If you know anyone who's interested and would be a good fit, we'd love to hear from you. Please contact Kaldari or Terry with any leads.
> We also encourage you to spread the word in your community. My experience is that the best hires often come through word of mouth.
> If you use Twitter, you are welcome to retweet one of the posts below, or send your own, with this shortcut link: http://ur1.ca/cep55
> We have a lot of work ahead for us on projects like Echo and Flow -- and could really use another engineer on the team.
> TWITTER POSTS ABOUT E2 JOB
> Job opening for #Wikipedia: We're looking for a web engineer to build new tools with us. Help us share free knowledge! http://ur1.ca/cep55
> We're looking for a software engineer to build new tools for#Wikipedia. Great team, fascinating work, wonderful cause!http://ur1.ca/cep55
> Fabrice Florin
> Product Manager
> Wikimedia Foundation
> Donate to keep Wikipedia free:
Donate to keep Wikipedia free: