Minutes and slides from Monday's quarterly review meeting of the
Foundation's Wikipedia Zero (Mobile Partnerships) team team are now
available at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
.
On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote:
> Hi folks,
>
> to increase accountability and create more opportunities for course
> corrections and resourcing adjustments as necessary, Sue's asked me
> and Howie Fung to set up a quarterly project evaluation process,
> starting with our highest priority initiatives. These are, according
> to Sue's narrowing focus recommendations which were approved by the
> Board [1]:
>
> - Visual Editor
> - Mobile (mobile contributions + Wikipedia Zero)
> - Editor Engagement (also known as the E2 and E3 teams)
> - Funds Dissemination Committe and expanded grant-making capacity
>
> I'm proposing the following initial schedule:
>
> January:
> - Editor Engagement Experiments
>
> February:
> - Visual Editor
> - Mobile (Contribs + Zero)
>
> March:
> - Editor Engagement Features (Echo, Flow projects)
> - Funds Dissemination Committee
>
> We’ll try doing this on the same day or adjacent to the monthly
> metrics meetings [2], since the team(s) will give a presentation on
> their recent progress, which will help set some context that would
> otherwise need to be covered in the quarterly review itself. This will
> also create open opportunities for feedback and questions.
>
> My goal is to do this in a manner where even though the quarterly
> review meetings themselves are internal, the outcomes are captured as
> meeting minutes and shared publicly, which is why I'm starting this
> discussion on a public list as well. I've created a wiki page here
> which we can use to discuss the concept further:
>
> https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
>
> The internal review will, at minimum, include:
>
> Sue Gardner
> myself
> Howie Fung
> Team members and relevant director(s)
> Designated minute-taker
>
> So for example, for Visual Editor, the review team would be the Visual
> Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker.
>
> I imagine the structure of the review roughly as follows, with a
> duration of about 2 1/2 hours divided into 25-30 minute blocks:
>
> - Brief team intro and recap of team's activities through the quarter,
> compared with goals
> - Drill into goals and targets: Did we achieve what we said we would?
> - Review of challenges, blockers and successes
> - Discussion of proposed changes (e.g. resourcing, targets) and other
> action items
> - Buffer time, debriefing
>
> Once again, the primary purpose of these reviews is to create improved
> structures for internal accountability, escalation points in cases
> where serious changes are necessary, and transparency to the world.
>
> In addition to these priority initiatives, my recommendation would be
> to conduct quarterly reviews for any activity that requires more than
> a set amount of resources (people/dollars). These additional reviews
> may however be conducted in a more lightweight manner and internally
> to the departments. We’re slowly getting into that habit in
> engineering.
>
> As we pilot this process, the format of the high priority reviews can
> help inform and support reviews across the organization.
>
> Feedback and questions are appreciated.
>
> All best,
> Erik
>
> [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
> [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
--
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB
Thanks, everyone who attended mobile web + apps quarterly planning! It was
a marathon session of high-level direction-setting, breakout brainstorming,
technical discussions, and kittens (<3 Kristen). Here's where I think we've
landed:
*Mobile web*
*In the next 3 months*, the mobile web team will focus on *new contribution
mechanisms *via mobile, beyond wikitext editing. Specifically, we'll be
testing a few versions of WikiGrok[1], packaging the feature as a Mediawiki
extension so that it can scale to production, and release it to all logged
in users on the mobile site of English Wikipedia. Before releasing to
stable, we'll take a look at the quality of submissions we get in the beta
period (before the feature pushes data to Wikidata) to decide on whether we
need to implement any quality-control mechanisms (e.g., aggregating data
rather than pushing it immediately).
We may also experiment with a few ways to create more engagement with the
feature (e.g., a persistent menu item that serves people more relevant
Wikipedia articles to tag, a progress bar, leaderboard, etc.) and, if we
have time, start thinking about the logged out user (e.g. reader)
experience.
*Apps*
The apps team will focus on *reader engagement* to build a class of more
engaged Wikipedia app readers who are able to find more of the high-quality
content all our projects offer, faster and easier. First we'll tackle
improvements
to the search experience, building out full-text search and experimenting
with surfacing Wikidata short descriptors along with search results. We'll
spend two sprints working on design and usability improvements aimed at
casual readers who struggle to find the basic information they need in the
app. Finally, the team will begin investigating using native notifications
to bring readers back to the app.
Longer out, *in the next 6-12 months*, this puts both teams on a trajectory
to using Wikidata to generate infoboxes on mobile web and apps, which opens
up both much more intuitive, mobile-friendly design opportunities and new
contribution funnels (not just adding/removing infobox items but
potentially getting readers to sort them for relevance). With a native
notifications framework in the apps, we'll also be able to more actively
funnel users to some of the future big-ticket engagement features we came
up with during brainstorming (e.g., Pinterest-like sharable article
collections, trending articles, alerts when your saved articles have
changed, etc.)
Obviously, Wikidata is a big dependency for both teams – luckily, Lydia,
the PM for Wikidata (cc'ed) is coming to town soon :) so we'll be talking
more with her about how our teams can work together to create amazing
things with Wikidata.
Some other next steps include working with Research & Analytics on a plan
for WikiGrok A/B testing, figuring out our qualitative analysis needs with
the UX research crew, and doing some design boiler room sessions on apps
notifications features and some of the other reader engagement features we
identified as high priority (that won't necessarily make it into the apps
this quarter but will need a lot of prep work). Dan and I will be reaching
out to you all for these things over the next couple of weeks, so stay
tuned...
If you're interested in learning more, check out the notes on our various
etherpads to see the details of what we discussed in each session:
Session 1: (Kickoff) http://etherpad.wikimedia.org/p/Q2_planning_kickoff
Session 2: (Mobile web breakout session)
http://etherpad.wikimedia.org/p/mobile_web_breakout
Session 3: (Mobile apps breakout session)
http://etherpad.wikimedia.org/p/app_breakout
Session 4: (Technical discussion & wrap-up of apps)
http://etherpad.wikimedia.org/p/mobile_Q2_planning
1. https://www.mediawiki.org/wiki/Extension:MobileFrontend/WikiGrok
--
Maryana Pinchuk
Product Manager, Wikimedia Foundation
wikimediafoundation.org
As the zero team starts to think about pre-loaded content the question
of how search will function within an off line environment has come
up. While it'll be up to each individual community to think about the
size of the pre-loaded we should think about these collections being
longer than a user would want to scroll through given only our article
title search.
Thus i'm eager to get a discussion going abut how we would support the
following users story
"As a user who has a Wikipedia pre-loaded device with little or no
internet connectivity, I would like to search by article text, so that
I can find multiple articles that could be relevant to me"
Given this, an article title search is not good enough.
* What would we have to change about our underlying data storage
architecture to do full text search?
* How fast would it be?
* Would it scale to 100's/100's/etc on articles ?
* What would the user experience look like?
...
* ... other bits i haven't thought about ?
This is not at a resourced feature level discussion yet but I'd like
to get some engineering thoughts on it before we get there.
--tomasz
Minutes and slides from last week's quarterly review meeting of the
Foundation's Mobile Contributions team are now available at
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
.
On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote:
> Hi folks,
>
> to increase accountability and create more opportunities for course
> corrections and resourcing adjustments as necessary, Sue's asked me
> and Howie Fung to set up a quarterly project evaluation process,
> starting with our highest priority initiatives. These are, according
> to Sue's narrowing focus recommendations which were approved by the
> Board [1]:
>
> - Visual Editor
> - Mobile (mobile contributions + Wikipedia Zero)
> - Editor Engagement (also known as the E2 and E3 teams)
> - Funds Dissemination Committe and expanded grant-making capacity
>
> I'm proposing the following initial schedule:
>
> January:
> - Editor Engagement Experiments
>
> February:
> - Visual Editor
> - Mobile (Contribs + Zero)
>
> March:
> - Editor Engagement Features (Echo, Flow projects)
> - Funds Dissemination Committee
>
> We’ll try doing this on the same day or adjacent to the monthly
> metrics meetings [2], since the team(s) will give a presentation on
> their recent progress, which will help set some context that would
> otherwise need to be covered in the quarterly review itself. This will
> also create open opportunities for feedback and questions.
>
> My goal is to do this in a manner where even though the quarterly
> review meetings themselves are internal, the outcomes are captured as
> meeting minutes and shared publicly, which is why I'm starting this
> discussion on a public list as well. I've created a wiki page here
> which we can use to discuss the concept further:
>
> https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
>
> The internal review will, at minimum, include:
>
> Sue Gardner
> myself
> Howie Fung
> Team members and relevant director(s)
> Designated minute-taker
>
> So for example, for Visual Editor, the review team would be the Visual
> Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker.
>
> I imagine the structure of the review roughly as follows, with a
> duration of about 2 1/2 hours divided into 25-30 minute blocks:
>
> - Brief team intro and recap of team's activities through the quarter,
> compared with goals
> - Drill into goals and targets: Did we achieve what we said we would?
> - Review of challenges, blockers and successes
> - Discussion of proposed changes (e.g. resourcing, targets) and other
> action items
> - Buffer time, debriefing
>
> Once again, the primary purpose of these reviews is to create improved
> structures for internal accountability, escalation points in cases
> where serious changes are necessary, and transparency to the world.
>
> In addition to these priority initiatives, my recommendation would be
> to conduct quarterly reviews for any activity that requires more than
> a set amount of resources (people/dollars). These additional reviews
> may however be conducted in a more lightweight manner and internally
> to the departments. We’re slowly getting into that habit in
> engineering.
>
> As we pilot this process, the format of the high priority reviews can
> help inform and support reviews across the organization.
>
> Feedback and questions are appreciated.
>
> All best,
> Erik
>
> [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
> [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
--
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB