Wikimedia Technology/Annual Plans/ERF OKR: Tech Community Building

= Tech Community Building = FY21/22 Organization Efficacy & Resilience OKR for Wikimedia Technology Department

Accountable: Birgit Müller 

OKR Overview
Our technical community is thriving and has a clear, consistent means to discover, build, and deploy applications that support community workflows, invent new forms of content creation and consumption, and leverage Wikimedia's APIs and data beyond the core wiki experience.

Key Result 1 A single entry point into our technical documentation, combined with accurate landing pages, enables technologists of all levels to discover Wikimedia’s technical areas and engage in communities of practice (acceptance criteria for accuracy defined by Q1, 100% of landing pages meet criteria by end of Q3, launch of developer portal by Q4)

Key Result 2 At least 10 underserved wiki communities have a set of technical skills and capabilities enabled through globally localized partnerships and curated pathways for learning and contribution, in support of scaling the ecosystem of tool developers (10%)

Key Result 3 Users can assess the reliability of tools for adoption, contribution or research based on a system of quality signals (co-maintainers, docs, recent editing usage, published source code, endorsements, etc) within Toolhub (research by Q2, code by Q3, adoption by Q4).



Key Result 1: Discoverable Docs (paths to entry)
A single entry point into our technical documentation, combined with accurate landing pages, enables technologists of all levels to discover Wikimedia’s technical areas and engage in communities of practice (acceptance criteria for accuracy defined by Q1, 100% of landing pages meet criteria by end of Q3, launch of developer portal by Q4)

Audience: Technologists of all levels Pathway to entry and engage

Narrative "Upon arriving on the MediaWiki and Wikitech home pages, I was instantly lost." -- Ashwin Bhumbla

In FY 20/21, WMF started to work on long standing issues in the field of technical documentation. Focus of the first year was to better understand challenges and opportunities, identify key technical documents and use cases we’re serving and prototype the structure of a single entry point (“Developer Portal”) to lower the barriers to find relevant information. This work continues in FY 21/22. Our goal is to move step-by-step towards a future where Wikimedia’s technical documentation is discoverable, cohesive, accurate, standardized, and continuously updated.

In terms of organizational maturity, Wikimedia’s technical documentation is somewhere between ad hoc (no standards, ad hoc efforts), and rudimentary (first practices established). Over the course of FY 21/22, we aim to move more towards organized and repeatable processes, and create the basis to build out a model and practice for technical documentation at WMF.

In FY 21/22, this encompasses:

Related initiative (also led by Technical Engagement):
 * Setting up the organizational basis to address Wikimedia’s needs in the field of technical documentation
 * Designing, implementing, and communicating a single entry point into our technical documentation (“Developer Portal”)
 * Defining requirements for technical documentation, with an initial focus on acceptance criteria for accuracy
 * Reviewing and improving high-level technical documents to meet predefined accuracy standards (“landing pages” into different technical areas)
 * Evolving and introducing a base set of best practices and standards
 * Improving Site Reliability Engineering (SRE) documentation with a focus on end user documents (target group: engineering teams and individual technical contributors) and documentation for Site Reliability Engineers (Q3-Q4)

Metrics KR-Metrics: Additional data & user research to inform next steps
 * 100% of landing pages linked from the Developer Portal meet predefined criteria for accuracy
 * Developer Portal is launched
 * Data on usefulness/clarity of technical documentation from the annual Developer Satisfaction Survey and annual WMCS user survey
 * Feedback-Gadget enabled on landing pages to inform the next round of improvements
 * Audience definitions to foster user-centered thinking within technical documentation communities of practice

Roadmap
 * 1) Define criteria for accuracy of landing pages (Q1)
 * 2) Develop content strategy, design and technical implementation plan for the Developer Portal (by Q1/2)
 * 3) Review and improve key technical documents/landing pages (Q2-Q4)
 * 4) Implement 80% of Developer Portal (Q2)
 * 5) Finalize implementation and launch of Developer Portal (Q4)
 * 6) Evolve and introduce a base set of best practices and standards (Q1-Q4)
 * 7) Gather and review feedback through surveys and feedback gadget to inform next steps and future focus areas (Q2-Q4)

Roles and Responsibilities
 * High-level strategy and organizational basis: Technical Engagement
 * Developer Portal: Multi-functional project group across the fields of Developer Advocacy, Engineering, Technical Writing, Design, User Research
 * Key technical documents, best practices and standards: Technical Writers cohort, other contributors to technical documentation

Material
 * Project Overview on MW.org
 * Workboard in Phabricator



Key Result 2: Curated Pathways (sustainable communities)
At least 10 underserved wiki communities have a set of technical skills and capabilities enabled through globally localized partnerships and curated pathways for learning and contribution, in support of scaling the ecosystem of tool developers (10%)

Audience: Technical contributors (in underserved wiki communities), beginner to intermediate skill level Pathway to learn, contribute, and grow

Narrative Wiki communities need technical contributors to be sustainable, and to grow the Wikimedia projects at scale. Smaller wikis often lack people with technical skills or contacts into the global technical community and ecosystem. We classify these wikis as underserved communities - underserved in terms of people with technical skills, and not enough tooling in place to curate and grow content at scale. The tooling ecosystem is a main driver for content growth and curation. About ⅓ of all edits come from tools and bots. In addition, there are a variety of other technical tasks that are handled by local wiki communities themselves - importing templates, translating software messages, handling site configurations, developing gadgets to bridge workflow gaps and more.

Curated pathways will help us to define technical tasks as a user journey from a brand new technically-minded user to a fully mature developer, and enable us to address needs for skills and capabilities step by step. In FY 21/22, our focus lies on skill development and further evolving capabilities for beginner and intermediate skill levels. While our focus is on underserved communities, investing in capabilities will benefit all users, and help us to strengthen and grow our global technical capacity and community.

Metrics
 * Increase of tool maintainers (10%)
 * At least 10 underserved communities have set of technical skills and capabilities enabled

Projects/Initiatives
 * 1. Capabilities (Quarry/PAWS/Toolforge)
 * Pathway for beginners: Quarry improvements
 * Pathway for beginners/intermediate skills: PAWS improvements
 * Pathway for intermediate skills: Toolforge improvements


 * 2. Skills
 * Need-based technical skill share workshops, defined modules for specific skills and topics (i.e. working with Lua modules, bot development, using Phabricator, querying with pywikibot)


 * 3. Local-global network and community building
 * Expanding the Small Wiki Toolkits partnerships with local/regional groups
 * Network and community building through smaller/larger events (regional workshops/conferences, Coolest Tool Award, Hackathon), and in collaboration with others

Roadmap Q1 Q2 Q3 Q4
 * Capabilities: Quarry, PAWS, Toolforge
 * Quarry improvements
 * Toolforge build service
 * Enable/disable/delete tools from Toolforge
 * Skills: Continue Small Wiki Toolkits workshops
 * Local-global network and community building
 * Wikimania/Hackathon
 * Initiate contacts with local/regional communities to help grow technical capacity
 * Capabilities: Quarry, PAWS, Toolforge (focus will be defined at the beginning of the quarter)
 * Skills: Continue SWT workshops
 * Local-global network and community building: Organize Coolest Tool Award; work with (new) regional partners as part of the Small Wiki Toolkits initiative
 * Capabilities: Quarry, PAWS, Toolforge (focus will be defined at the beginning of the quarter)
 * Skills: Continue SWT workshops
 * Local-global network and community building: work with (new) regional partners as part of the Small Wiki Toolkits initiative
 * Capabilities: Quarry, PAWS, Toolforge (focus will be defined at the beginning of the quarter)
 * Skills: Continue SWT workshops
 * Local-global network and community building: WM Hackathon; work with (new) regional partners as part of the Small Wiki Toolkits initiative

Roles and Responsibilities
 * Capabilities: WMCS (lead), Developer Advocacy, Release Engineering
 * Skills: Developer Advocacy (lead), mentors from other teams and communities
 * Local-global network and community building: Developer Advocacy, local/regional partners and individuals across the movement

Material
 * https://meta.wikimedia.org/wiki/Small_wiki_toolkits
 * https://techblog.wikimedia.org/2021/09/02/digging-deeper-into-quarry/
 * https://meta.wikimedia.org/wiki/Coolest_Tool_Award
 * https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2021 (next edition: date tbd)
 * Quarry Workboard on Phabricator
 * PAWS Workboard on Phabricator



Key Result 3: Informed User Decisions (Toolhub)
Users can assess the reliability of tools for adoption, contribution or research based on a system of quality signals (co-maintainers, docs, recent editing usage, published source code, endorsements, etc) within Toolhub (research by Q2, code by Q3, adoption by Q4).

Audience: Users and Developers of tools Pathway to make informed decisions

Narrative Today users only have word-of-mouth to rely on as to the "quality" of a tool. It is very difficult to determine the level of support and maintenance a tool has. Will it keep up with changes that happen on-wiki (policies, standards)? Will it keep up with infrastructure changes (API updates, hosting platform changes, wiki hosting changes)? Does it even have active maintainers? Is there a "best" way to get help? The work on Toolhub in FY 21/22 will provide more insights in these questions, and increasingly help users assess the quality of tools on multiple levels. Toolhub is planned to be released in October ‘21 (delayed from July ‘21). The new “quality signals” will be implemented in Q3.

Metrics KR-Metrics: Additional data to inform next steps:
 * Delivery dates
 * Adoption
 * User feedback, i.e. via talkpage, sessions, or survey

Projects/Initiatives
 * Toolhub MVP Deployment
 * Research to define quality signals
 * Toolhub 2.0 feature development
 * Driving adoption

Roadmap Q1 Q2 Q3 Q4
 * Continue work on MVP, prepare deployment
 * Research: Quality signals
 * Launch
 * Define user stories and design for the quality signals feature set
 * Technical implementation plan
 * Technical implementation of quality signals
 * Gather user feedback to inform next steps

Roles and Responsibilities
 * Toolhub project team: Product Management, Engineering, Developer Advocacy
 * Advisory council: SRE, Security, Community Relations, volunteers

Material
 * https://meta.wikimedia.org/wiki/Toolhub
 * Workboard on Phabricator
 * https://toolhub-demo.wmcloud.org/