Wikimedia Foundation Annual Plan/Quarterly check-ins/TPG Reading Comm-Tech April 2017
Notes from the Quarterly Review meeting with the Wikimedia Foundation's TPG, Reading, and Community Tech teams, April 25, 2017.
Please keep in mind that these minutes are mostly a rough paraphrase of what was said at the meeting, rather than a source of authoritative information. Consider referring to the presentation slides, blog posts, press releases and other official material
Note-taker: Michael Holloway
Appendix containing readership metrics for the same time period can be found here: https://commons.wikimedia.org/wiki/File:Wikimedia_Foundation_Reading_metrics_Q3_2016-17_(Jan-Mar_2017).pdf
Slide 1
editSlide 2
editKL: TPG didn't have programmatic work last Q, so we'll be discussing workflows
Slide 3
editTPG's values.
Slide 4
editBig picture goal is to provide ... team support at the foundation.
Meet people at the context they're in: (e.g. team maturity)
Also, work with core team at the foundation to develop shared objectives for our engagements.
Slide 5
editWe were working with teams in an embedded way, as well as doing "light engagements." Also 2 offsites, 4 org functions.
Slide 6
editSlide 7
edit-Collab jam: Came out of last year's annual plan retro. Req was to have more time focused on working with teams cross-org in a collaborative way.
TPG designed a 3-day event that was a point in the annual planning cycle.
What we expected to happen: people would have the ability to have more aligned plans, reduce redundancies, leverage skills. Have a heads-up across teams about what expectations were for the fiscal year. Also, an opportunity to engage with how we do collaboration.
Slide 8
editImpact of collab jam: Need more info to determine but initial feedback was mostly positive. We're writing a blog post about it.
Maggie: Did you poll people who were not able to attend, or those who were present? Some people weren't invited and others couldn't come.
KL: We'll catch those groups in the annual plan retro activities for the process overall. We want to get some targeted questions on things like participation.
Slide 9
editSlide 10
editDESIGN: Working with Design to create a Design Statement of Purpose. And now that it exists, what are the next steps? TPG will transition off this when the new design director arrives. Arthur will stay involved as needed.
Slide 11
editWe helped facilitate movement strategy discussions for Track A (WMF Staff). (Some sessions may still have open slots if you want to participate.) Happening now.
Slide 12
editWIKILEAD: Arthur has been helping out T&C, selecting balanced cohort, thinking about where people are in their careers. Helped with logistics (venue) and program.
Benefit of TPG's involvement is sustainability. Not just a one-off training, but TPG can help support and sustain via its cross-org involvment.
Slide 13
editKey takeaways: We'd like to work more directly with the C-Team. The collab jam has potential to be a v. important part of the annual planning process and communication wasn't as great as it could have been.
One thing that came out of the survey is a desire to have sr. leadership there and participating. Tricky balance but people were wanting more engagement.
Another: having budget projections in hand would have been helpful. Possibly a waste of time to make plans we don't have the budget for.
Slide 14
editHighlights of embedded work with teams...
Slide 15
editMax and Natalia work with Reading. Highlights were reading vert. offsite and reading web offsite. Feedback was really good. Face time is v. valuable for remote teams, esp as we discuss big projects and strategy.
Slide 16
editEditing: Joel started workign with VE, then moved to working with Trevor more on whole vertical issues. Annual planning, support for specific teams. Helped with burnups, burndowns. Talk to Joel about it!
Next Q: more best practice sharing, with customizations as needed.
Toby: What were the metrics?
Joel: Doing standard scrum burnups. Team lost some members, how much was the team's work affected? Helped with prioritization.
Slide 17
editKevin works with Discovery. big objective is planning the May offsite. there's a lack of clarity about how it will play out going forward.
Slide 18
editGrace works with Design Research. There's some new editors work that abby is transitioning to from new readers; we developed a more efficient meeting sched. (time in mtgs cut in half)
Helped with dependency planning, timelines.
Slide 19
editSlide 20
editSlide 21-22
editInfo on light engagments.
Slide 23
editSlide 24
editSlide 25
editSlide 26
editSlide 27
editSlide 28
editSlide 29
editSlide 30
editSlide 31
editSlide 32
editSlide 33
editSlide 34
editSlide 35
editSlide 36
editSlide 37
editJK: Reading is the team that serves the people (and machines) that consume wikipedia.
Takehomes
Slide 38
editSlide 39
editWikipedia is not dying. We said so last Q and another Q's worth of data bears it out.
Slide 40
editSlide 41
editPageviews are up but there is a slow desktop decline. see chart. Even with seasonality, rising YoY. Mobile rising, desktop shrinking slower than mobile is rising. No patterns by country that we could find. We tried to filter out some bot artifacts.
Slide 42
editOrg level updates:
Light reorg: Corey Floyd manger of apps now, and PO of reading infrastructure
We're consolidating code and leveraging each other's work better.
Revisited our strategy, and found we didn't want to revise it for the most part. Josh put together an apps strategy; not a major deviation but much more holistic and thought out.
We had an experimental portion of our strategy which was making interaction with the sites more interactive. We learned that we need to focus on helping out with moderation effects.
Kicked off the structured data grant -- working on hiring and onboarding people coming over from Discovery to work on this.
Last Q we also had two product setbacks. They were unique in that we did things "right" (documented, publicized things) but things got pulled anyway.
Toby: This is worth a broader discussion with other C-levels. Particularly the pushbacks against Wikidata in enwiki -- very significant in that the plans for Wikidata are very explicit about being the structured data backbone for all the other projects. Need to be ahead of that.
Slide 43
editleanings
2 things that got better: We have a QA person now! Also using usertesting.com which is making user testing smoother.
Community consultations continue to be a huge investment. We don't have a great template and
? from Katherine: (paraphrasing, can't see the original...) Getting blocked by 1 or 2 people?
JK: we're not OK with that. 1 or 2 people drum up opposition and things get pulled.
Joel: VE had a similar experience. One person's rationale was simply opposing everything the foundation does.
JK: Analytics infra also continues to be a challenge.
Toby: Though Analytics has done lots of valuable work for us.
Quim: Important not to imagine that there will be a magic formula that makes every feature rollout work perfectly every time. Working with the community is an iterative process.
Slide 44
editSlide 45
editSlide 46
editSlide 47
editSlide 48
editWeb team:
Slide 49
editWeb team: rolled out page previews to the first 6 wikis that they'd done a/b testing on; this Q will roll out to all except en and de. Biggest change to the reader experience in 6-7 years.
Slide 50
editWorking on better print styles for both New Readers as well as the desktop web. We're sunsetting OCG and trying to do it responsibly. Figuring out who is using it and how.
Slide 51
editSlide 52
editNew print style examples.
Slide 53
editSlide 54
editCorey: Reading Infra working on planning, developing 4 key features to benefit all our platforms.
1) Feed services: in use on iOS and Android apps. There to increase engagment and retention. We expanded featured article support from just en to 14 langs. Added an "on this day" endpoint as well. This Q we'll ship a real-time trending API. iOS will be the first platform to integrate.
2) Push notification service: Something we haven't done before but expect to increase engagement. This will also allow us to decrease battery usage and bandwidth in certain contexts. Put together a tech plan last quarter and implementation begins this Q. Should land Q2.
3) Page content services: Effort to unify our page rendering infra on top of the Parsoid stack developed by Editing. We'll be able to provide better offline support and... Landing date TBD.
4) Reading list service: Our first foray into syncing user data. A lot of work with product on the UI/UX and work in progress on the backend. Hope to roll out this Q.
Slide 55
editSlide 56
editJosh: ioS worked last Q on a new experience with geolocation and search called Places. Old Nearby feature was very limited, just showed articles with locations near the user. Android added a map-based Nearby last fall. Last Q, iOS was working on a map-based feature that added the ability for advanced searches.
Was mostly complete, in beta testing found a few things we wanted to polish. Another setback was that an important volunteer objected to the use of Apple Maps. Could have done a better job in previous documentation in emphasizing that Apple Maps was the only functional choice for the feature.
This Q, next step is to integrate the real-time trending edits API. It's based on watching unusual volumes of editing activity.
Toby: I want to call out Product, Design, Engineering working as coequal partners. This is an example of that.
Slide 57
edit[Places demo] Josh: A great thing about this feature is that it's very curiosity/rabbit-hole inducing, like our other best features.
Slide 58
editSlide 59
editAndroid has been working on the offline experience in response to user feedback and research. Will continue on this path next Q by supporting the zim file format that allows loading large collections of offline content.
Slide 60
edit[reading lists current state demo]
Slide 61
editSlide 62
editAdam: We're continuing to work on the TemplateStyles extension. Purpose is to make it possible for template authors to make templates render nicely on both desktop/mobile. Currently in security review. It's a multi-Q effort. Want to get it into prod soon, will need more work even after rollout. Hope to present on it at Wikimania.
Slide 63
editSlide 64
editSlide 65
editAnne: Usage and knowledge of WP in the countries we're studying is very low.
Slide 66
editTo give an overview, the idea here is that we're trying to approach through access (affordability) and awareness.
Awareness: Working with reading web on branding on mobile site. Awareness efforts in Iraq via a WP0 launch. ... Access: Foundation looked at research ~2010 and made the decision to work on Zero. Not much since then. We're looking at more recent industry/research developments on this front. Also looking at supporting Zero more as well.
Slide 67
editEasiest low-hanging fruit on awareness was to better brand the mobile web. People thought they were searching on google but were actually on WP. Nirzar is working on branding.
Nirzar: Got branding in place, next step is working on wordmarks for all languages.
Slide 68
editSlide 69
edit[wordmark examples]
We're in the process of documenting that searches per session are still holding up since we intro'd the workmark which reduced the search bar real estate.
Slide 70
editOffline: built out some concepts in the fall and testing the past few months. Hired an agency to do some testing in India. As a result we're working on print styles. Should go out this Q.
Slide 71
editSlide 72
editDecided NOT to pursue an offline web app but to leverage some of the underlying tech to do things like provide better support for intermittent connections.
Slide 73
editSlide 74
editJosh: This section could really be called something like "microcontributions."
Android app added the ability to edit Wikidata descriptions in-app. Previously in three languages, more were added this week.
Slide 75
edit[demo] Josh: Want to call out guidance we give users about things like licensing, etc. Trying to lower barriers to entry to contribute to the knowledge base.
Slide 76
editPrelim results:
Although the feature is geared to new/casual users, active edtors also contribute significantly. The % of [manual] WD descriptions edits via the Android app: 60% in he.
Slide 77
editSlide 78
editSlide 79
editJK: OCG (PDF rendering tool) -- this is the same slide as last Q. We're doing another community consultation.
Slide 80
editAdam: With the coop of the editing vertical, the multimedia engineers have transitioned into reading. We're in the process of recruiting for a number of roles. W/r/t work for q3/q4, working on 3D model file support. Was the #11 most requested feature on the 2015 comm. wishlist. Will be doing some heuristic eval, and take that and community feedback, iterate and release to production. First, need to talk on Commons village pump (esp. about potential issues with models of patented objects).
[wrong slide-->]
We did some in-depth user research to find out how real users use the app. Followed them around for 2 weeks. Results will be up soon.
Also working with JMo on an altenative content recommendation system. Currently we use morelike: search. Ellery developed an alternative earlier but it turned out that morelike was better. This quarter will continue work with Jonathan.
Slide 81
editSlide 82
editSlide 83
editSlide 84
editSlide 85
editSlide 86
editSlide 87
editDanny: We ended Q1 (3?) with community wishlist survey. As a product team we collect the top 10 and then begin working on them all...
This was the second time we've worked around the wishlist concept, really the first with a full team.
We investigated all 10 as a team and chose 2 projects that would get shipped by the end of Q. Idea is to do that again next Q and beyond.
In Q3, worked on warning on unsuccessful login attempts and a bot fix.
Slide 88
editSlide 89
edit[illustration] Mr. Z-Bot's popular pages bot: provides a report of popular pages within a given category or topic. Helps editors know which pages are most important to improve. Example: https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Spiders/Popular_pages Niharika: The bot died because it was parsing old dumps, and the old maintainer wasn't around. Danny: We'll make sure it's working well for a month, then announce.
Slide 90
edit[illustration] Login attempt warnings: we have them now! Triggers on login attempts from an unfamiliar (device?). (--i missed the tech explanation)
Slide 91
editCookie blocking Niharika: Helps prevent people evading blocks via a cookie in the browser. That way they can't just change IPs. Toby: This is an example of a "two-foot wall": not effective against an experienced attacker, but will help stem abuse by casual vandals. Danny: Analogy: closing the door to stop zombies from getting in your house. Closing the door won't stop them in the end but you should still probably do it. [chart shows cookie-blocked login attempts per day]
Slide 92
editLearnings: Last year started with 2 devs. This year we had 4. We figured out that people scattered a bit, started work on Q4 stuff before Q3 stuff (login attempt notifications) was quite finished. Still struggling with cross-wiki watchlists. It's a thing we can do, just hard. Requires big database changes. We're keeping at it, it's a promise we made. We may get a new dev who will help us tackle this.
Slide 93
editGoals for this Q: -Improving and releasing wiki syntax highlighting -Modernize/stabilize the X-Tools suite -User rights expiration: already done by a volunteer!
Supporting community engagement:
We'll build a grant metrics tool to help simplify their reporting system.
Slide 94
editSlide 95
editAnti-Harassment team: Four focus areas: -Detection -Reporting - take the onus off the recipient -Evaluation - make investigations shorter; software should do the heavy lifting -Blocking
Slide 96
edit[new hires]
Slide 97
editSo far: Hired people; evaluated AbuseFilter and identified potential improvements; began research an a user interaction history tool and per-page blocking.
Slide 98
editFor next Q: need to hire and onboard 2 devs. Goal is to influence and equip community leaders to enforce policies. They'll make needed improvements to trust and safety tools.
Will begin community consultations on the same.
Slide 99
editSlide 100
editQuestions Josh: Which editor(s) will the syntax highlighter target?
Danny: Old editor first. Will be a beta feature initially. It's fast (at least on good connections). Based on CodeMirror(?) which was done a lot of good work on performance. Ryan will then work on new wikitext editor JamesF: new editor is done