Wikimedia Technical Conference/2018/Session notes/Working together to develop our roadmap

Theme: Working together, decision making and responsibilities

Leader(s): Corey, Josh, Kate

Description: Audiences, 3rd parties and WMDE all build on top of MediaWiki. In this session we will work together to build part of a roadmap. We will build a map highlighting dependencies and blockers.

1. MediaWiki Needs for Collaboration: Access control for namespaces -  “As a wiki admin I want to be able to create or designate namespaces that only certain users can access.”
2. Global Curation: Make it easier to localize tools -  “As a semi-skilled technical volunteer on a growing Wikipedia I want to have a localized version of a useful gadget I heard is used on English Wikipedia.”
3. Data into products: Add a data tab to the wikipedias to show wikidata - “As an editor that edits on both a Wikipedia and Wikidata I want a way to access and edit relevant wikidata properties and info from within Wikipedia.”
4. Machine learning: Build JADE - “As a curator I want to be able to ensure ORES is giving optimal judgements for my wiki and give feedback on errors from on wiki.”
5. Choosing install methods: Create a command line status/health report tool - “As a mediawiki admin I want a tool to know if the current installed config and extensions are functional.”
6. Extracting data out:  Provide a structured see also API - “As an API consumer with a conversational agent I want to be able to get just the “See also” links from a Wikipedia article in all languages that have it, in a JSON response.”
7. Parser: Move Parsoid into core and determine if it can serve as the sole parser - “As a visual editor user I want to know the new parser is not going to be slower for opening, saving and seeing my edits published, and as a reader I want to know my pages will load as quickly.”
8. Translation: As a movement leader I want to be able to use the content translation tool to translate documents with visual editing on a sub-page segment

Facilitator Instructions:

1. [15 minutes] Josh presents
2. [5 minutes] Find a story - session leaders first. There are no grouping rules, and no size constraints except you need at least two people, and max out on the two pizza rule; but please try not to clump.
3. [2 minutes] Identify a goal owner - this person will facilitate and stay with the roadmap through the session, and summarize key points at the end. If the session leader is in the group they have preference.
4. [5 minutes] Decide whether to accept  or rewrite the goal and core story as currently written. You can rewrite them to anything that can get a consensus in the group, but the goal should ideally be in the form of [make/build/fix/replace][system or feature]. The story should be in the form “As a [stakeholder] I want to [perform some task] (with [detail or constraint] or so that I can [goal or outcome]” It's fine to change them, but remember it needs to be direct, not comprehensive and perfect.
5. [30 minutes] Using the basic reverse roadmapping process described in the opening, and thinking back to the ideal process discussions, work back from the goal and initial story and identify:
   1. Milestones
   2. Blockers
   3. Dependencies (changes required outside core goal)
   4. Research and unknown areas
   5. Social risks, community choices or feedback required
6. [15 minutes] Everyone but the owner takes a break and can look at the other groups’ work. Anyone can leave post-its in the Talk section of the paper. Owners should stay at their station to answer clarifying questions but should try not to get into detailed conversations or immediately respond to posted comments.
7. [10 minutes] Everyone should head back  to their original story. The owner should summarize the other participants feedback, reading the Talk cards and reporting any relevant conversations. The group should decide how to incorporate the feedback. Also, consider changes from having had more time and thought. Have any breakthroughs during the break? Change your minds? Change the map.
8. [10 minutes] Move to the wall poster that says RESOURCES. Looking at the map you’ve drawn, what teams, communities or machines will need to do something to move the plan forward? What full time staff or functions are needed? These can be in staff count, machine cost estimates, etc or just general statement (eg. “some machines with all the GPUs” is fine ).
   1. Write them directly on the poster. No need to group or order them.
   2. Review the map again, and confirm that all the steps, including things like  research, data analysis and community needs are reflected in the resource list.
   3. Now place a dot next to any that are “maintenance” or perpetual costs. That is, once the goal is met, what costs or commitments will still be needed? If the costs are reduced, but still continue (ie. a team goes from 8 to 2 in maintenance mode) please break them out as separate items (put a cost of 6 engineers with no dot, and 2 with a dot).
9. [5 minutes] Find the other poster, which has a two dimensional scale of risk and impact. Each group member should, knowing only what they know now, place a dot to vote where this plan falls on two dimensions:  

Vertical:  how risky the goal is - how probable is it that in 3 years the story will be true? How plausible is the plan as drafted? Does it seem likely the budget and resources will be provided? Can it be executed without major negative consequences?

Horizontal: how impactful will a successful outcome be on our strategic goals of knowledge equity and knowledge as a service? Does this advance the architecture goals? A product theme? At what scale?

1. [15 minutes] Owner shares out a summary of the plan and key issues, points of contention, trade offs, or other things to know moving forward.
2. Wrap up statement, and what’s next for roadmapping.

Presentation & Setup (30m) 1:30 - 2:00

General presentation about roadmapping (20m)

• Roadmapping is not about schedules and calendars and deadlines. It is about identifying  the actual work that we believe (at the time) will be needed to meet a goal. Its a road map not a road calendar.
• No one can predict the future, but it is irresponsible not to plan for it. Think of everything in terms of probabilities and not certainties. It is okay to have goals and steps to reach them, even while acknowledging the vast unknowns. In general the Audiences PM rule of thumb is that you should know with great specificity what you are doing this quarter, have basic ideas about next quarter, and a basic notion of 3 and 4 quarters from now. The cone of uncertainty is real.
• Longer roadmaps don’t correlate with more effective outcomes or better collaboration. If you’re on a roadtrip and you can’t even make it to your first stop you don’t solve that by planning a longer road trip. You communicate about the obstacles and goals, you integrate this new information and understanding, then drive to the next goal.
• You gotta do it regular like. You need to readjust and communicate again on a regular cadence. Roadmaps are living team documents, not edicts from on high.
• In our context, many of our dependencies and risks are not technical. Not “can this be done with software?” but “will we be allowed to do it?”, “will it be effective?”, “can we get enough money and patience to do it right?”, etc. Roadmapping has to take more than technical preliminaries into account. We do it collectively not because we make product-by-committee, but because there is so much to our socio-technical world that we have to account for we need to think plans through together.
• We have the resources and skills to get to 2-3 year plans with delivery windows that we hit. We are not there. We need to build that the same way you build any trust: be honest but respectful, do what you say you will do, and start with the small stuff and build up from there.

Activity Preparation

Pre-conference

Materials

• Selecting them to provide clear structure/common language to the activity
  • Agree on meaning of colors and shapes for roadmap pieces
    • Circles are goals/features
    • Diamonds are decisions
    • Development
    • What else??
      • Tests?
      • Research?
      • Community?
      • Process?
      • Blockers?
      • Dependencies?
      • Feedback loops?
      • Iterations?
• Practical questions
  • Post it notes? Do they stick?
  • What about arrows, how do we do this?
    • More complicated things like dependencies, feedback loops and iterations
  • Wall space, do we have enough. Can we stick things on them?
  • Do we need “rolls” of background paper? (to stick post it notes on) so we can move whole maps around?

Structuring session output / notes to be input to this session

• Current session outputs are:
  • Answers to key questions
  • New questions (with owners and rationale)
  • New action items / next steps (with owners and rationale)
• Proposed new session outputs
  • Key decisions (with owners and rationale)
  • One user facing feature/goal that we should aspire to
  • Summary

During conference

Gathering input

We need to gather the input throughout the conference to support this session

• Features/Goals that we should aspire to
• Decisions
• Actions
• Questions
• Ask Session Leaders to nominate a feature for roadmapping

From process session: WMDE/WMF feature delivery (process, responsibilities and gaps) Volunteer driven project (no staff)

3rd Party Feature Delivery Your processes will be used as the score card for roadmaps Planning and maintenance

NOTES from Josh's talk:

• A pitch is not a plan
• Account for human factors - community and other stakeholders have some rights and responsibilities - As we work thru plans today, even if they're simple to do, editors or board will often need to agree to plans.
• Use frequent communication to adjust regularly
• [... missed this …]
• Risks, costs, impact - will address that later
• Step 1: Pick a story

Readouts from groups

See sticky-note photos at phab:T206085#4696219 and/or commons:Category:Wikimedia Technical Conference 2018

Santhosh et al.

• Ticket created 5 years back
• Task is to make ‎<translate> tags use Visual Editor
• We discussed challenges
• Key decision: whether we need to get rid of translate tags, b/c they’re a horrible hack - Needs research.
• Then, build a VE plugin with help from UI design
• Difficulty: is a two-team project also involving …?
• Resources:
  • Research + Engineers - 1
  • Design - 1
  • PM - 1
  • QA (at least volunteer)
  • Product analyst
• Medium impact, low risk

Aaron Halfak

• Goal is to have people actually use JADE, the proposed ORES auditing system
• So that JADE fills up with judgements about pages and revisions
• I want to talk about the resources and impact graph
• JADE is a fairly standard extension that helps people understand whether ORES is helping or hurting their wikis - Helps prevent redundant patrolling efforts
• Couple of eng, design, couple of comm liasons, eng mgr, releng,
• Problem that we don’t have the ability to store the number of revs we want to, when we do there will be hardware concerns
• Risk and Impact: Range of med to high impact, and med risk - high risk assumed by ppl not familiar with JADE.  I see it as low risk but I’m biased.

Brion (or Brandon?):

• Finish porting Parsoid to PHP
• Once we’ve done the port, we can start deploying as a replacement for node.js Parsoid
• Then do extension compataibility fixes for things integrate to MW before implemeting in core.
• Coord with 3rd party users to make sure their tools are compatible.
• Resourcing: dedicated parsing team will take on most. Coord with Core Platform team, i18n, SRE for deployment, many teams who own related extensions.
• We’re pretty sure it will be finished within 3 years
• Risk: moderate-to-low, high impact
• Will improve maintainability, be at least performance neutral.  Most of the scary bits are done with for VE, the rest should be tractable.

Alexia

• Implementation for access control
• Ability to lockdown viewing article within certain namespace, as starting point
• We came up with two goals:
  • (Easy-to-moderate) Viewing of namespaces and access control for that
  • Completely hide the existence of an article (if no permissions)
    • This seems impossible? But we remain hopeful
• Resources: 6 months Eng. Lots of testing to ensure no leaks.
• Beta period needed for pen-testing.
• Community consultation, to ensure it meets all use-cases for 1st and 3rd parties
• Risks: we were split.  Those in the enterprise realm consider it high impact and high risk, those not in enterprise consider it high risk and low impact. [? confirm order here]
• Will require some refactoring of code, some of which may be happening already.

Daren

• Standalone Wiki health-status reporting tool
• Should it run on its own or within MW - Research and design question
• Scale: Start with testing basic core functionality. Then Services, then extensions.
• Once you start opening it to extensions, how do you keep a registry so that communities can enter/find their status info
• Need a couple of engs and a designer, prob not much hardware.
• Costs - An advocate to work with authors of extensions. Then 3rd party devs.
• Maintaining the long term goal of evolving testing as the product evolves.
• Medium to high impact, pretty high risk.

TheDJ

• Making it easier to localize gadgets. Descoped from "tools".
• As a volunteer, I want to reuse gadgets without rebuilding them, in my own project and my own language.
• Research with community needed, on how it would work for them, and how governance would work.
• Need to create a prototype in which we decide where gadgets would be stored and where their definitions will be
• Determine if that fits all use-cases, and then build prototype.
• Build gadget repository, perhaps searchable?
• Update most/all gadgets to use it.
• At the same time, deal with translations issues -- where to store them, how to allow as many as possible to edit, try to standardize use by gadgets
• Resources: 1-1.5 years to work with community engagement. 6months of Eng time.
• Concerns: perhaps not big enough for WMF approval. Resourcing perhaps from Platform Evolution or CommTech Wishlist.

Joaquim

• Didn’t touch much the proposition we were given
• Getting "see also" section in json format. For API users, e.g. Alexa, googlebot, siri, etc.
• For the roadmap, we ended up at the same level of abstraction
• One (?) is about finding structured content
• Another is about being able to edit the found content to allow curation
• Resources: standard product team - pm, eng, design, CRS, qa, ops
• Consulting with the API consumer client companies
• Pizzas, cake for shipping, lot of servers, cake in case someone cries
• Long-term - SRE, client companies, and dot?
• Impact: product thinks low impact low risk, engineers think higher impact and higher risk.

Lydia

• 2 year old task!
• Allow editing Wikidata data from other wikis
• The story we got, turned into looking at the existing prototype - integrating this into VE's template editing dialogue.  Allows editing all data for the item in Wikidata from within the VE window.
• Steps: Prototype already been through some community consultations, needs refinement. Need users to markup infobox templates to map them to wikidata properties, to show connections between data and where it is used.
• Thinking about difficulty of going from nothing editable to everything editable.  
• We need to allow viewing the data, letting people see what wikidata has, vs what is on wikipedia already.
• Allow editing some of the well-used - from the mental model perspective to allow editing - we could enable editing low-hanging fruit
• Start with small-to-mid size wikipedias.  Enwiki last because highest-risk.
• Risks: mostly in Enwiki deployment. And expected interwiki edit warring that we need to deal with, and need to develop strategies for preventing vandalism.