Wiki Experiences (WE) Draft Key Results
[
Draft Objectives
]
|
Key Result shortname
|
Key Result text
|
Key Result context
|
Owner
|
WE1.1
Discussion
|
Develop or improve one workflow that helps contributors with common interests to connect with each other and contribute together.
|
We think community spaces and interactions on the wikis make people happier and more productive as contributors. Additionally, community spaces help onboard and mentor newcomers, model best practices of contributing, and help address knowledge gaps. However, the existing resources, tools, and spaces that support human connection on the wikis are subpar and do not meet the challenges and needs of the majority of editors today. Meanwhile, the work of the Campaigns team has demonstrated that many organizers are eager to adopt and experiment with new tools with structured workflows that help them in their community work. For these reasons, we want to focus on encouraging and promoting a sense of belonging among contributors on the wikis.
|
Ilana Fried
|
WE1.2
Discussion
|
Constructive Activation: #% YoY increase in the percentage of newcomers who publish ≥1 constructive edit in the main namespace on a mobile device.
|
Current full-page editing experiences require too much context, patience, and trial and error for many newcomers to contribute constructively. To support a new generation of volunteers, we will increase the number and availability of smaller, structured, and more task-specific editing workflows (E.g.
Edit Check
and
Structured Tasks
).
Note: Baselines will only be established towards the end of Q4 current FY, after which our KR target metric percentage will also
be established
.
|
Peter Pelberg
|
WE1.3
Discussion
|
Increase user satisfaction in 4 moderation products by X%.
|
Editors with extended rights make use of a wide range of existing features, extensions, tools, and scripts to perform moderation tasks on Wikimedia projects. This year we want to focus on making improvements to this tooling, rather than undertaking projects to build new functionality in this space. We're aiming to touch a number of products over the course of the year, and want to make impactful improvements to each. In doing so we hope to improve the experience of moderating content overall.
We will define X% upon measuring baselines for some common moderator tools that we may target with this workstream.
The Community Wishlist will be a substantial contributor to deciding on the priorities for this KR.
|
Sam Walton
|
WE2.1
Discussion
|
By the end of Q2, support organizers, contributors, and institutions to increase the coverage of quality content in key topic areas [TBD] by X articles through experiments.
|
This KR is about improving topic coverage towards reducing existing knowledge gaps. We’ve established that communities benefit from effective tools paired with campaigns targeted at increasing the quality of content in our projects. This year we want to focus on improving existing tools and experimenting with new ways of prioritizing key topic areas that address knowledge gaps.
Our target X% increase in coverage will be determined by looking at existing baselines of quality content creation. Also, the topic areas we’ll be focusing on with communities and institutions will be determined by next quarter.
|
Purity Waigi
&
Fiona Romeo
|
WE2.2
Discussion
|
By the end of Q2, implement and test two recommendations, both social and technical, to support languages onboarding for small language communities, with an evaluation to analyze community feedback.
|
There are editions of Wikipedia in about 300 languages. And yet, there are many more languages that are spoken by millions of people, in which there is no Wikipedia and no Wiki at all. This is a blocker to fulfilling our vision: that every single human being can freely share in the sum of all knowledge. The Wikimedia Incubator, is where potential Wikimedia project wikis in new-language versions can be arranged, written, tested and proven worthy of being hosted by the Wikimedia Foundation.
The Incubator
was launched in 2006 with the assumption that its users would have prior wiki editing knowledge. This problem is exacerbated by the fact that this process is supposed to be mostly performed by people who are the newest and the least experienced in our movement.While editing on Wikimedia wikis has significantly improved since then, the Incubator hasn't received these updates due to technical limitations. Currently, it takes several weeks for a wiki to graduate from the Incubator and
only around 12 wikis are created each year
, showing a significant bottleneck.
Existing research and materials
reveal technical challenges in every phase of language onboarding: adding new languages to the Incubator, complexities in developing and reviewing content, and slow process in creating a wiki site when a language graduates from Incubator.
Each phase is slow, manual, and complex, indicating the need for improvement. Addressing this problem will allow creating wikis in new languages more quickly and easily, and allow more humans to share knowledge. Various
stakeholders
, existing research and resources have highlighted
proposed recommendations
both social and technical. This key result proposes testing two recommendations both social and technical and evaluating the community feedback.
|
Satdeep Gill
&
Mary Munyoki
|
WE2.3
Discussion
|
By the end of Q2, 2 new features guide contributors to add source materials that comply with project guidelines, and 3-5 partners have contributed source material that addresses language and geography gaps.
|
To grow access to the quality source material that’s needed to close strategic content gaps, we will:
- Partner with the Biodiversity Heritage Library; AfLIA; and the Wikisource Loves Manuscripts learning network.
- Support the acquisition and retention of content partners through more accessible reuse metrics.
- Guide contributors to add images and references that comply with project guidelines and increase trust in content, for example, by flagging potential issues during their upload/addition.
|
Fiona Romeo
&
Alexandra Ugolnikova
|
WE2.4
Discussion
|
By the end of Q2, enable Wikifunctions calls on at least one smaller language Wikipedia to provide a more scalable way to seed new content.
|
To reduce our knowledge gaps effectively, we need to improve workflows that support scalable growth in quality content, especially in smaller language communities.
|
Amy Tsay
|
WE3.1
Discussion
|
Release two curated, accessible, and community-driven browsing and learning experiences to representative wikis, with the goal of increasing the logged-out reader retention of experience users by 5%.
|
This KR focuses on increasing the retention of a new generation of readers on our website, allowing a new generation to build a lasting connection with Wikipedia, by exploring opportunities for readers to more easily discover and learn from content they are interested in. This will include explorations and the development of new curated, personalized, and community-driven browsing and learning experiences (for example, feeds of relevant content, topical content recommendations and suggestions, community-curated content exploration opportunities, etc).
We plan on beginning the fiscal year by experimenting with a series of experiments of browsing experiences to determine which we would like to scale for production use, and on which platform (web, apps, or both). We will then focus on scaling these experiments and testing their efficacy in increasing retention in production environments. Our goal by the end of the year is to launch at least two experiences on representative wikis and to accurately measure a 5% increase in reader retention for readers engaged in these experiences.
To be optimally effective at achieving this KR, we will require the ability to A/B test with logged-out users, as well as instrumentation capable of measuring reader retention. We might also need new APIs or services necessary to present recommendations and other curation mechanisms.
|
Olga Vasileva
|
WE3.2
Discussion
|
50% increase in the number of donations via touch points outside of the annual banner and email appeals per platform.
|
Our goal is to provide a diversity of revenue sources while recognizing our existing donors. Based on feedback and data, our focus is on increasing the number of donations beyond the methods the Foundation has relied upon in the past, specifically the annual banner appeals. We want to show that by investing in more integrated donor experiences, we can sustain our work and expand our impact by providing an alternative to donors and potential donors that are unresponsive to banner appeals. 50% is an initial estimate based on the decreased visibility of the donate button on Web as a result of Vector 2022, and the increase in the number of donations from FY 2023-2024's pilot project on the Wikipedia apps to enhance donor experiences (50.1% increase in donations). Evaluating this metric by platform will help us understand trends in platforms and if different tactics should be deployed in the future based on a difference in behavior based on platform audience.
|
Jazmin Tanner
|
WE4.1
Discussion
|
Provide a proposal of 3 countermeasures to harassment and harmful content informed by data and in accordance with the evolving regulatory environment by the end of Q3.
|
Ensuring user safety and well-being is a fundamental responsibility of online platforms. Many jurisdictions have laws and regulations that require online platforms to take action against harassment, cyberbullying and other harmful content. Failing to address these may expose platforms to legal liability and regulatory sanctions.
Right now we do not have a very good idea about how big these problems are or the reasons behind them. We rely heavily on anecdotal evidence and manual processes which leave us exposed both to legal risks as well other far-reaching consequences: underestimation of the problem, escalation of harm, reputational damage and erosion of user trust.
We need to build a strong culture of measuring the incidence of harassment & harmful content and proactively implement countermeasures.
|
Madalina Ana
|
WE4.2
Discussion
|
Develop at least two signals for use in anti-abuse workflows to improve the precision of actions on bad actors by the end of Q3.
|
The wikis rely heavily on IP blocking as a mechanism for blocking vandalism, spam and abuse. But IP addresses are increasingly less useful as stable identifiers of an individual actor, and blocking IP addresses has unintended negative effects on good faith users who happen to share the same IP address as bad actors. The combination of the decreasing stability of IP addresses and our heavy reliance on IP blocking result in less precision and effectiveness in targeting bad actors, in combination with increasing levels of collateral damage for good faith users. We want to see the opposite situation: decreased levels of collateral damage and increased precision in mitigations targeting bad actors.
To better support the anti-abuse work of functionaries and to provide building blocks for reuse in existing (e.g. CheckUser, Special:Block) and new tools, in this KR we propose to explore ways to reliably associate an individual with their actions (sockpuppetting mitigation), and combine existing signals (e.g. IP addresses, account history, request attributes) to allow for more precise targeting of actions on bad actors.
|
Kosta Harlan
|
WE4.3
Discussion
|
Reduce the effectiveness of a large-scale distributed attack by 50% as measured by the time it takes us to adapt our measures and the traffic volume we can sustain in a simulation.
|
The evolution of the landscape of the internet, including the rise of large-scale botnets and more frequent attacks have made our traditional methods of limiting large-scale abuse obsolete. Such attacks can make our sites unavailable by flooding our infrastructure with requests, or overwhelm the ability of our community to combat large-scale vandalism. This also puts an unreasonable strain on our high privilege editors and our technical community.
We urgently need to improve our ability to automatically detect, withstand, and mitigate or stop such attacks.
In order to measure our improvements, we can't rely solely on frequency/intensity of actual attacks, as we would be dependent on external actions and it would be hard to get a clear quantitative picture of our progress.
By setting up multiple simulated attacks of varying nature/complexity/duration to be run safely against our infrastructure, and running them every quarter, we will be able to both test our new countermeasures while not under attack, and to report objectively on our improvements.
|
Giuseppe Lavagetto
|
WE4.4
Discussion
|
Launch temp accounts to 100% of all wikis.
|
Temporary accounts are a solution for complying with various regulatory requirements around the exposiure of IPs on our platform on various surfaces. This work involves updating many products, data pipelines, functionary tools, and various volunteer workflows to cope with the existence of an additional type of account.
|
Madalina Ana
|
WE5.1
Discussion
|
By the end of Q3, complete at least 5 interventions that are intended to increase the sustainability of the platform.
|
The MediaWiki platform sustainability is an evergreen effort important for our ability to scale, increase or avoid degradation of developer satisfaction, and grow our technical community. This is hard to measure and depends on technical and social factors. However, we carry tacit knowledge about specific areas of improvements that are strategic for sustainability. The planned interventions may help increase the sustainability and maintainability of the platform or avoid its degradation. We plan to evaluate the impact of this work in Q4 with recommendations for sustainability goals moving forward. Examples of sustainability interventions are: simplify complex code domains that are core to MediaWiki but just a handful of people know how it works; increase the usage of code analysis tooling to inform quality of our codebase; streamline processes like packaging and releases.
|
Mateus Santos
|
WE5.2
Discussion
|
Identify by the end of Q2 and complete by the end of Q4 one or more interventions to evolve the MediaWiki ecosystem’s programming interfaces to empower decoupled, simpler and more sustainable feature development.
|
The main goal of KR 5.2 is to improve and clarify the interaction between MediaWiki's core platform and its extensions, skins, and other parts. Our intent is to provide functional improvements to MediaWiki’s architecture that enable practical modularity and maintainability, for which it is easier to develop extensions, and to empower the requirements from the wider MediaWiki product vision. This work also aims to inform what should exist (or not) within core, extensions, or the interfaces between them. The year will be divided into two phases: a 5-month research and experimentation phase that will inform the second phase where specific interventions are implemented.
|
[TBD]
|
WE5.3
Discussion
|
By the end of Q2, complete one data gathering initiative and one performance improvement experiment to inform followup product and platform interventions to leverage capabilities unlocked by MediaWiki’s modeling of a page as a composition of structured fragments.
|
The primary goal here is to empower developers and product managers to leverage new MediaWiki platform capabilities to meet current and future needs of encyclopedic content by making possible new product offerings that are currently difficult to implement as well as improve performance and resiliency of the platform.
Specifically, at a MediaWiki platform level, we want to shift the processing model of MediaWiki from treating a page as a monolithic unit to treating a page as a composition of structured content units. Parsoid-based read views, Wikidata integration, and Wikifunctions integration into wikis are all implicit moves towards that. As part of this KR, we want to more intentionally experiment with and gather data to inform future interventions based on these new capabilities to ensure we can achieve the intended infrastructure and product impacts.
|
[TBD]
|
WE5.4
Discussion
|
By the end of Q2, execute the 1.43 LTS release with a new MW release process that synchronizes with PHP upgrades.
|
The MediaWiki software platform relies on regular updates to the next PHP version to remain secure and sustainable, which is a pain point in our process and important for the modernization of our infrastructure. At the same time, we regularly release new versions of the MediaWiki software, which e.g. translatewiki.net depends on, the platform used to translate software messages for the Wikimedia projects and many other open source projects.
There’s an opportunity to improve the MediaWiki release process, including technical documentation and synchronization with PHP upgrades in alignment with the MediaWiki product strategy before the next release, which will be a long term support version (LTS). This work is part of our strategic investment in the sustainability of the MediaWiki platform (see also: 5.1) and aims to improve developer experience and infrastructure management.
|
Mateus Santos
|
WE6.1
Discussion
|
Resolve 5 questions to enable efficiency and informed decisions on developer and engineering workflows and services and make relevant data accessible by the end of Q4.
|
“It’s complicated” is a frequent response to questions like “which repositories are deployed to Wikimedia production”. In this KR we will explore some of our “evergreens” in the field of engineering productivity and experience - recurring questions that seem easy but are hard to answer, questions that we can answer, but the data is not accessible and require custom queries by subject matter experts, or questions that are cumbersome to get a response on for process gap or other reasons. We will define what “resolve” means for each of the questions: For some this may just mean to make existing, accurate data accessible. Other questions will require more research and engineering time to address them. The overarching goal of this work is to reduce the time, workarounds and effort it takes to gain insights in key aspects of the developer experience and enable us to make improvements to engineering and developer workflows and services.
|
[TBD]
|
WE6.2
Discussion
|
By the end of Q4, enhance an existing project and perform at least two experiments aimed at providing maintainable, targeted environments moving us towards safe, semi-continuous delivery.
|
Developers and users depend on the Wikimedia Beta Cluster (beta) to catch bugs before they affect users in production. Over time, the uses of beta have grown and come into conflict?the uses are too diverse to fit in a single environment. We will enhance one existing alternative environment and perform experiments aimed at replacing a single high-priority testing need currently fulfilled by beta with a maintainable alternative environment that better serves each use case's needs.
|
Tyler Cipriani
|
WE6.3
Discussion
|
By the end of Q2, introduce a sustainability scoring system for the Toolforge platform across a variety of technical and social factors. By the end of Q4, improve one of its key technical factors by 50%.
|
Toolforge, the key platform for Wikimedia’s volunteer-built tools, plays a crucial role from editing to anti-vandalism. Our goal is to enhance Toolforge usability, lower the barriers to contribution, improve community practices, and promote adherence to established policies. To this effect, we will introduce a scoring system by the end of Q2 to evaluate the Toolforge platform sustainability, focusing on technical and social aspects. Using this system as a guide, we aim to improve one of the key technical factors by 50%.
|
Slavina Stefanova
|