Thanks, Terry.

I appreciate your clarifications and have responded to some of your comments below.

Overall, it appears that we are on the same page on key objectives, which was the primary purpose of this planning sessions.

I look forward to addressing unresolved action items in coming days. Our goal is to do this in small teams, rather than in a large group discussion. When the small groups have prepared specific recommendations, they can present them to the whole team for discussion, to make the most effective use of everyone's limited time.

I would also like to remind everyone that if we could recruit a new engineer on the E2 team right away, a lot of the hard decisions we are trying to make about which new notifications can be squeezed in this quarter would be reduced, because that person could work on getting a few of these done, working off the templates already built by Kaldari and Benny. To that end, I encourage you all to post about this job description in your community if you haven't already.

To be continued,

Fabrice

On Jan 16, 2013, at 11:56 PM, Terry Chay 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)).

Actually, the purpose of this planning session, as initially proposed by Howie, was unrelated to the quarterly review, which may not happen for a while. Our intent was to get everyone on the same page, ask for ideas from the team and address unresolved issues together. I think we have accomplished that initial goal.

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

These are good action items for when we are invited to prepare for a quarterly review.

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

Thanks for clarifying these points. Howie had already done this last night, as outlined below. I had also included them in my slides, though the wording may not have been as clear as it could have. We are all in agreement on these objectives, even if we are using slightly different words to express them. ;o)

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.

Yes, we have already discussed different ways to make sure that new users are aware that 1) they have a watchlist and 2) there are new items in that watchlist. A first approach is to send a one-time notification 10 days after registration ('did you know you have a watchlist?'), which is really easy to do, because it is triggered by a date, but may not be enough by itself. Another solution is to send a bundled notification if they have not visited their watchlist in a while, informing them there is new activity on that page ("You have x new events on your watchlist'), which is a bit more complex, but appears doable in our time-frame. A third way is to put a little counter next to the watchlist link in the user menu, so they can see there are new items. We have also discussed the idea of automatically adding pages that you start or edit to your watchlist, if you are a new user, which everyone agrees is a good idea, but which we have not scoped out yet from a development standpoint. I had not yet head the idea you propose above, which I look forward to discussing further.

I have a meeting with Steven this afternoon to go over all this in detail, so we can determine how these ideas can integrate with E3's plans for onboarding new users. We also plan to discuss a possible collaboration to make some of these ideas happen this quarter, as well as explore the possibility of E3 taking on development of some new notifications next quarter, if it fits their overall goals.

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

I completely agree with your concerns, which we share with Oliver and others on our team. I also agree with your proposed criteria for selection. I would add one more criteria, which I proposed to Oliver yesterday: make sure that the selected features give us the most bang for the buck, so they can be used by as many power users as possible over a period of time. So this would give a slightly lower priority to notifications that are used infrequently (e.g. one-time notices) or that can only used by a small group of users (e.g. admins only). 

Oliver and I had a long conversation about all this yesterday, and I defer to him to recommend notifications that would generally address these criteria and help him sell this new product to as many experienced users as possible. For example, in yesterday's conversation, we identified a couple useful notifications which would benefit many active editors ('your page was rated or featured', or 'x readers posted useful feedback on your page'). You can see some of the notification ideas we discussed at the end of this Google spreadsheet (in the yellow section). The next step is to boil down all these ideas to a short list, and run them by more editors, so we can identify the best prospects for development later this quarter. Oliver and I will work closely together to make this happen in coming weeks. 

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.

Yes, focusing on positive notifications is a goal which I have advocated repeatedly for several months now, and our entire team is onboard with it. We have been discussing options that could help us serve that goal since November and have already identified a number of positive notification ideas in this 'Positive' section of our feature requirements page. However, a challenge we face is how to give positive reinforcement to a new editor after their first few edits. One possible solution we have discussed is giving new users a bundled notification that '20 people have contributed to this page since your last edit'. While this type of activity is currently handled by the watchlist, this type of 'contributions' notification could have a positive impact in getting the new user to go back to a page they edited earlier (particularly if they don't yet feel motivated to use the watchlist). This is almost certainly better than only sending them negative notifications when their edits are reverted (which is like a slap in the face) -- or sending them no notifications whatsoever after their first edits (which is what we are doing now). This problem can be illustrated by this new editors slide in our planning deck.

When 1-3 is resolved, I think we need to change the slide: https://docs.google.com/a/wikimedia.org/presentation/d/1ps7-i_fISUldycH1LFrJ45dkIF9fwjdJP6dYbV6HaBY/edit#slide=id.g77ef3ac0_1_109

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

I think there is value in having a rough timeline showing when we think the bulk of the development effort will take place.

However, if you prefer simple bullet lists, here is one for next features, and here is one for future features. We also have a preliminary table for new user notifications, which we can adapt to include the other proposed notifications discussed above. 

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

Good point about my error for the third bullet point for Flow. It should have been focused on Q3, not Q4. My apologies.

I am happy to provide more guidance for Q3 on Flow as I get more familiar with this product. The only guidance I can offer for Flow at this early stage is to jointly develop a product plan and design spec for a minimum viable product focused on user-to-user messaging. Both the plan and the design spec should be complete by the end of Q3 at least , so we can start development with a larger team in Q4. So the only milestone I can recommend now would be:

* complete Flow product plan and design spec by March 2013

Sound good?

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>:

Thanks for the improvements!

To reduce visual clutter, I tightened this slide just a bit, for readability, but I totally agree with every item you proposed.

Note that we already have a working definition of defaults by user rights on our feature requirements page.

•  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>