Fabrice, 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

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)). 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.

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.

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_fISUldycH1LFrJ45dkIF9fwjdJP6dYbV6HaBY/edit#slide=id.g77ef3ac0_1_256>:

• 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: <2013-01-15 E2 Q3 review.html>

From: Oliver Keyes &lt;okeyes(a)wikimedia.org&gt; Date: January 17, 2013, 8:01:25 AM PST To: Terry Chay &lt;tchay(a)wikimedia.org&gt; Cc: Fabrice Florin &lt;fflorin(a)wikimedia.org&gt;rg>, Howie Fung &lt;hfung(a)wikimedia.org&gt;rg>, Ryan Kaldari &lt;rkaldari(a)wikimedia.org&gt;rg>, Benny Situ &lt;bsitu(a)wikimedia.org&gt;rg>, Luke Welling &lt;lwelling(a)wikimedia.org&gt;rg>, Matthias Mullie &lt;mmullie(a)wikimedia.org&gt;rg>, Brandon Harris &lt;bharris(a)wikimedia.org&gt;rg>, Vibha Bamba &lt;vbamba(a)wikimedia.org&gt;rg>, Erik Moeller &lt;erik(a)wikimedia.org&gt;rg>, Steven Walling &lt;swalling(a)wikimedia.org&gt;rg>, Maryana Pinchuk &lt;mpinchuk(a)wikimedia.org&gt;rg>, Dario Taraborelli &lt;dtaraborelli(a)wikimedia.org&gt;rg>, James Forrester &lt;jforrester(a)wikimedia.org&gt; Subject: Re: E2 Planning Meeting Notes On 17 January 2013 07:56, Terry Chay &lt;tchay(a)wikimedia.org&gt; wrote: Fabrice, 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 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. 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_fISUldycH1LFrJ45dkIF9fwjdJP6dYbV6HaBY/edit#slide=id.g77ef3ac0_1_256>: • 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