Plano Anual da Fundação Wikimedia/2025-2026/Produto e Tecnologia/OKRs
Outdated translations are marked like this.
O Ano à Frente
Mesmo com as mudanças no mundo, a Fundação Wikimedia continua certa de que queremos que nossa missão – criar e manter informações úteis dos projetos Wikimedia disponíveis gratuitamente na internet – seja um esforço multigeracional: queremos que o conhecimento livre continue disponível para muitas gerações futuras.
A internet está mudando rapidamente. As novas gerações estão obtendo informações por meio de experiências com vídeos nas redes sociais e IA e, em comparação com as gerações mais antigas, menos pessoas conhecem a Wikipédia. Estamos observando um declínio no número de pessoas que acessam nossos sites e no número de pessoas que editam. Enquanto isso, plataformas em toda a internet dependem do conteúdo da Wikimedia para sustentar suas ofertas de IA e pesquisa. Essas dinâmicas são grandes desafios, mas deixam claro por que o conhecimento gratuito e confiável que criamos juntos é tão importante. O mundo precisa mais do que nunca de uma fonte de conhecimento confiável e revisada por humanos, e os projetos da Wikimedia continuam mostrando que podem fornecê-la.
Para enfrentarmos esses desafios no ano vindouro, construiremos caminhos para utilizar o conteúdo Wikimedia sustentavelmente, e traremos o conteúdo Wikimedia para espaços sociais online onde gerações mais novas estão passando tempo. Melhoraremos nossos próprios sites para que as pessoas leitoras queiram voltar, engajar-se profundamente e contribuir de maneiras que tenham significado para elas. E investiremos em nossa capacidade de experimentar rapidamente novas tecnologias, de modo que nosso ritmo de desenvolvimento possa alcançar o ritmo com que o mundo se transforma.
The infrastructure goal is how the platform and user experience will support addressing these challenges and reaching the majority of the participants in the movement. It is not a list of projects, but instead, a set of directions to fuel volunteer growth, enable volunteers to build trustworthy encyclopedic content, fund our mission, and evolve our offering to shape the changing internet. You can read more about those four strategic pillars.
Alimentar o crescimento do voluntariado
A comunidade de pessoas voluntárias é o motor único por trás do sucesso dos projetos da Wikimedia, e precisamos que ela seja saudável e continue crescendo. Mas, no último ano, vimos um declínio contínuo no número de pessoas novas e antigas que editam os projetos. Para entender melhor e responder de forma mais eficaz às necessidades de nossos voluntários e voluntárias atuais, a Fundação reformulou a Lista de Desejos da Comunidade, que era uma pesquisa anual, transformando-a em um processo de recepção sempre aberto, no qual as necessidades das usuárias e dos usuários e as ideias para projetos podem ser incorporadas ao trabalho de várias equipes da Fundação. Reunimos os desejos em “Áreas de Foco” e integramos três dessas Áreas de Foco aos resultados-chave do plano anual. Também iniciamos um Conselho Consultivo de Produtos e Tecnologia piloto para complementar as inúmeras conversas que as equipes da Fundação têm com membros da comunidade dentro e fora da wiki ao longo do ano. Além disso, identificamos oportunidades para trazer novas gerações para nossos projetos, como o fato de que os jovens estão participando ativamente de outros espaços sociais online, onde têm maneiras fáceis e compatíveis com dispositivos móveis de se conectar por meio de temas de interesse comum.
No próximo ano, vamos incentivar o crescimento do voluntariado, tornando a contribuição mais fácil e atraente para as novas gerações através da expansão do mobile-first, novas formas de edição (“tarefas estruturadas”) e adicionando fluxos de trabalho inteligentes que facilitam a edição construtiva em dispositivos móveis para novas pessoas que querem contribuir (“verificações de edição”). Para envolver e reter mais as pessoas que já são voluntárias, vamos oferecer ações e tarefas recomendadas e disponibilizá-las em um hub central que facilita a organização das atividades na wiki. Usaremos a IA de forma cuidadosa para fortalecer o trabalho das pessoas voluntárias, sempre mantendo os seres humanos no centro e priorizando a transparência. Tanto para pessoas voluntárias novas quanto experientes, criaremos maneiras de se conectarem e trabalharem juntas em nossos sites — inspiradas em campanhas e WikiProjetos de sucesso —, permitindo que encontrem pessoas editoras com ideias semelhantes e melhorem o conteúdo relacionado aos seus interesses (alinhado com esta área de foco da Lista de Desejos).
Entregar conteúdo enciclopédico confiável
À medida que o material gerado por IA se multiplica na internet, o mundo precisa mais do que nunca de conteúdo enciclopédico confiável. Queremos aumentar a capacidade das pessoas voluntárias de criar novos conteúdos, garantir que os conteúdos existentes continuem confiáveis e fornecer conteúdos confiáveis a uma nova geração de pessoas leitoras com novas necessidades e preferências.
Para ajudar as voluntárias e voluntários a criar novos conteúdos, vamos desenvolver as ferramentas e fluxos de trabalho guiados existentes (como a Ferramenta de Tradução de Conteúdo), para que comunidades grandes e pequenas possam cobrir conteúdos essenciais. Para garantir que o conteúdo existente permaneça confiável, ajudaremos as pessoas voluntárias experientes a gerenciar melhor suas crescentes cargas de trabalho, ampliando as ferramentas que elas usam para encontrar tarefas que precisam de atenção – facilitando a atualização de artigos e a reversão de edições inadequadas (alinhado com esta área de foco da Lista de Desejos).
Também ajudaremos os funcionários a defender nosso conteúdo, revelando novos sinais (além de endereços IP) que identificam agentes mal-intencionados, permitindo que as pessoas sejam bloqueadas de forma a minimizar o bloqueio errôneo de pessoas editoras de boa-fé.
Para fornecer conteúdo enciclopédico a uma nova geração, criaremos recursos que ajudem novos tipos de pessoas leitoras a compreender os artigos com facilidade, encontrar informações de seu interesse e participar ativamente enquanto leem. Essas mudanças têm como objetivo incentivar novas pessoas leitoras da Wikipédia a se tornarem leitoras dedicadas e, algumas delas, doadoras (em alinhamento com esta área de foco da Lista de Desejos).
Fornecer conteúdo confiável também significa apoiar um modelo de “conhecimento como serviço”, no qual toda a internet utiliza o conteúdo da Wikimedia. Nesse modelo, nossa infraestrutura não é apenas um recurso valioso para as pessoas que acessam nosso site, mas também para empresas de pesquisa e inteligência artificial, que acessam nosso conteúdo automaticamente como entrada e saída fundamental para seus produtos. Esse tipo de empresa representa apenas um dos muitos usos que cada vez mais sobrecarregam nossa infraestrutura de forma insustentável. No último ano, um aumento significativo no volume de solicitações provenientes de ferramentas de scraper e bots tornou ainda mais urgente a necessidade de corrigirmos essa tendência. Precisamos estabelecer caminhos sustentáveis para que desenvolvedores e reutilizadores tenham acesso ao conteúdo de conhecimento, de forma que os seres humanos tenham prioridade sobre os bots.
Financiar o futuro do ‘livre’
O departamento de Produto e Tecnologia desempenha um papel importante para garantir que nosso movimento seja sustentável. No próximo ano, trabalharemos em estreita colaboração com a equipe de Captação de Recursos para que nossas pessoas doadoras tenham uma experiência cada vez mais clara e gratificante. Em nossos sites e aplicativos para dispositivos móveis, criaremos oportunidades para que as pessoas leitoras expressem sua gratidão pela Wikipédia por meio de doações e desenvolveremos novas maneiras de fazer com que as pessoas doadoras se sintam reconhecidas, para que continuem doando ano após ano.
Moldar uma internet em transformação
Para levar conhecimento gratuito a todas as pessoas do mundo, precisamos encontrá-las onde elas estão, com as experiências que as ajudam a aprender. Pessoas entre 18 e 24 anos têm menos conhecimento e uso da Wikipédia do que as gerações anteriores. Elas aprendem principalmente com plataformas de vídeos curtos, personalidades confiáveis on-line, experiências com jogos sociais e, cada vez mais, aplicações de IA. Este ano, disponibilizaremos a Wikipédia para esses públicos nos locais onde passam o tempo on-line, para que conheçam a Wikipédia como uma fonte de conhecimento confiável e criada por pessoas. Aumentaremos nossa presença em plataformas de vídeo populares, divulgando o conteúdo da Wikipédia e gerando comunidade nesses espaços. E exploraremos ideias para levar o conhecimento da Wikipédia para plataformas de jogos e redes sociais.
Dentro da Infraestrutura, isso é dividido em três portfólios de trabalho (chamados de “categorias”): Wiki Experiências, Sinais e Serviços de Dados e Públicos Futuros. Essas categorias são as mesmas do ano passado e do ano anterior.
Em conjunto, acreditamos que este plano surge num momento crucial da história da Internet, preparando-nos para garantir que os conteúdos de conhecimento livre continuem acessíveis e moldados por todas as gerações. Os nossos objetivos e resultados-chave apresentam a estrutura e o conteúdo deste plano com mais detalhe, e aguardamos com interesse as perguntas e ideias da comunidade em geral.
Construir, melhorar e manter a infraestrutura para os projetos e pessoas voluntárias da Wikimedia, com base nos nossos valores
"A Fundação disponibilizará e manterá informações úteis dos seus projetos na Internet gratuitamente, para sempre."
As equipes de Produto e Tecnologia dedicam prioridade permanente, durante todo o ano, à construção, melhoria e manutenção da infraestrutura que serve aos projetos Wikimedia. Investimos na hospedagem dos projetos Wikimedia, no desenvolvimento de software de código aberto e sistemas de design, e na manutenção e melhoria da infraestrutura para produtos de dados e modelos de IA.
Parte do nosso trabalho essencial foca nos fundamentos do desenvolvimento e hospedagem de um site popular de grande porte. Hospedamos nossos projetos Wikimedia em centros de dados, em servidores e hardware que adquirimos, instalamos e mantemos, conectados entre si e ao resto da Internet por meio de uma rede de alta velocidade. Monitoramos e adicionamos capacidade quando necessário, e atualizamos os equipamentos quando ficam muito antigos. Por exemplo, este ano, prevemos expandir nossa capacidade e atualizar nosso hardware em nossos centros de dados em Ashburn, Virgínia, e Carrollton, Texas.
Nós projetamos e desenvolvemos software de código aberto (principalmente MediaWiki). Também usamos e implantamos muitos aplicativos, bibliotecas e estruturas de código aberto de terceiros já existentes. Bugs importantes em nosso software são priorizados e corrigidos. A manutenção de software de código aberto requer trabalho altamente qualificado de pessoas com especialização em desenvolvimento de software de código aberto, engenharia de confiabilidade de sites (SRE), gerenciamento de produtos, gerenciamento de programas, design e muito mais. Nossa equipe trabalha para garantir que nosso software e nossos sistemas estejam atualizados e se adaptem a um ambiente em constante mudança. Isso inclui modernizar nosso código para continuar a obter benefícios das correções de segurança e para funcionar bem com novos softwares de terceiros. Por exemplo, o MediaWiki é escrito em PHP e, no ano passado, migramos do PHP 7.4 para o 8.1, o que exigiu alterações tanto no código quanto na infraestrutura onde hospedamos nossos sites e serviços. Este ano, daremos continuidade a esse esforço e migraremos para a versão 8.3, usando as lições aprendidas e as ferramentas desenvolvidas na atualização para a versão 8.1. A atualização tornará nossos sistemas mais rápidos para as pessoas leitoras, mais fáceis de usar para a equipe e pessoas voluntárias e mais seguros para todo mundo. Também economizará tempo de desenvolvimento futuro, graças às melhorias de segurança, desempenho e suporte que vêm com as atualizações de linguagem.
Para garantir que nossos projetos e conteúdos permaneçam disponíveis na Internet, tanto hoje como no futuro, nossas equipes dedicam um esforço significativo para garantir a alta disponibilidade de nossos sites e serviços. Um aspecto desse trabalho concentra-se na recuperação de desastres causados por eventos catastróficos ou maliciosos. Por exemplo, garantimos o backup de dados importantes e a capacidade de recuperá-los. Da mesma forma, duas vezes por ano, testamos nossa capacidade de alternar nossos sites entre nossos centros de dados de forma automatizada e corrigimos quaisquer problemas encontrados. Outro aspecto desse trabalho se concentra em identificar e nos adaptar às tendências em evolução nos tipos e volumes de tráfego que recebemos. Por exemplo, com o crescimento sem precedentes de scrapers automatizados, estamos priorizando o trabalho para garantir que nossos sites e serviços permaneçam acessíveis a usuários humanos, adotando uma abordagem sistemática para estabelecer normas sobre o uso responsável de nossa infraestrutura.
Nem todo o trabalho é planejado com antecedência. Também respondemos a eventos e incidentes inesperados, como interrupções no site, relatórios de segurança ou incidentes de segurança, ou ataques de vandalismo em grande escala aos nossos projetos. Monitoramos nosso desempenho e barreiras à acessibilidade em todo o mundo (incluindo problemas de conectividade com a Internet ou bloqueios por censura) e investigamos quaisquer anomalias que encontrarmos. Alguns desses eventos inesperados ou padrões repetitivos de problemas fazem com que a equipe priorize projetos de acompanhamento de curto prazo que visam mitigar ou prevenir completamente impactos negativos adicionais. Por exemplo, esses tipos de esforços foram cruciais para permitir que nossos projetos Wikimedia resistissem a picos de tráfego global devido a grandes eventos noticiosos (por exemplo, mortes de celebridades de alto perfil), por meio de uma combinação de otimização de desempenho, redesenho arquitetônico de áreas com gargalos e aumentos de capacidade. Da mesma forma, melhorias recentes na usabilidade de nossas ferramentas e sistemas para gerenciar o tráfego que recebemos nos permitiram reagir de forma mais rápida e eficaz às mudanças nas condições. Esse tipo de trabalho de adaptação é essencial para nossa capacidade de responder a eventos emergentes, muitas vezes em prazos curtos, e garantir que nossos projetos e conteúdo permaneçam disponíveis.
Objetivos de Produto e Tecnologia
Os objetivos apresentados aqui estão em estado de esboço e estão abertos para comentários e discussões.
- Os Objetivos representam uma direção de nível alto.
- Os "Resultados-Chave" (KRs, na sigla em inglês) representam um meio mensurável de monitorar o sucesso de seus objetivos.
- As "Hipóteses" subjacentes para cada KR representam o trabalho real que estamos fazendo para tentar atingir os resultados-chave associados. Elas serão atualizadas neste documento e nos projetos relevantes ou páginas wiki das equipes conforme percepções são obtidas ao longo do ano.
-
é para o trabalho que a Fundação está priorizando conforme a Lista de Desejos da Comunidade.
Wiki Experiências (WE)
Experiências de Pessoas Contribuidoras (WE1)
- Objetivo: Contribuições aumentam porque se oferece ao voluntariado oportunidades atraentes e ele entende o seu impacto.
- Contexto: Este objetivo será a fundação para entregar a nova estratégia da pessoa contribuidora com seus 3 pilares: 1) oferecer ao voluntariado um meio centralizado de organizar suas atividades dentro da wiki, 2) fornecer tarefas menores e mais discretas para criar mais clareza e ajudar o voluntariado a atingir seu potencial, e 3) dar mais significado ao ato de contribuir. No ano fiscal 25/26, planejamos entregar a infraestrutura básica para ajudar o voluntariado a organizar suas atividades na wiki de uma maneira centralizada, começando com intervenções especificamente focadas em pessoas editoras e moderadoras experientes. Em anos subsequentes, acrescentaremos intervenções por todos os papéis de contribuição e incluiremos mais espaços de problemas. Além disso, continuaremos a investir em Checagem de Edições e Tarefas Estruturadas, construindo uma fundação para como usar IA de modo escalável, tanto como orientação durante o processo de edição quanto como um meio de dirigir o voluntariado a oportunidades atraentes. E por último, investiremos em tornar mais visível o impacto que o voluntariado causa para criar uma experiência que tenha mais significado para ele.
- Resultado-chave WE1.1: Aumentar edições construtivas [i] em X% para pessoas editoras com menos de 100 edições cumulativas, conforme medido por experimentos ao final do segundo trimestre.
- i. "Edições construtivas" = edições que não são revertidas dentro de 48 horas após a publicação
- ii. T389403#10960480
- Pessoas voluntárias (mais) novas têm dificuldade para começar a editar com sucesso. Particularmente, pessoas usando dispositivos móveis em que o espaço de tela é limitado e a atenção é frequentemente fragmentada.
- Algumas pessoas se cansam do contexto, da paciência e da tentativa e erro necessários para contribuir construtivamente. Outras ainda não encontraram uma oportunidade atraente para tentar.
- WE 1.1 lidará com essas questões:
- Revelando sugestões de edição
- Oferecendo orientações acionáveis durante as edições
- Construindo fluxos de trabalho de edição mais específicos no que diz respeito às tarefas
- No centro desses esforços está a necessidade de meios escaláveis para detectar como edições em andamento e conteúdo existente poderiam ser melhorados. Para aumentar essa capacidade, nós continuaremos a experimentar com aprendizagem de máquina para aprender como a IA pode nos ajudar a identificar problemas de políticas na Wikipédia.
- Proposed KR scoring methodology: On a per platform basis, we will calculate the proportion of interventions we deployed and evaluated through controlled experiments that met and/or exceeded the constructive edit target we set at the outset of this year. See phab:T379285#10782051 for thinking.
- Note: as June 30, 2025, WE 1.1 has two controlled experiments planned.
- Contexto: Este objetivo será a fundação para entregar a nova estratégia da pessoa contribuidora com seus 3 pilares: 1) oferecer ao voluntariado um meio centralizado de organizar suas atividades dentro da wiki, 2) fornecer tarefas menores e mais discretas para criar mais clareza e ajudar o voluntariado a atingir seu potencial, e 3) dar mais significado ao ato de contribuir. No ano fiscal 25/26, planejamos entregar a infraestrutura básica para ajudar o voluntariado a organizar suas atividades na wiki de uma maneira centralizada, começando com intervenções especificamente focadas em pessoas editoras e moderadoras experientes. Em anos subsequentes, acrescentaremos intervenções por todos os papéis de contribuição e incluiremos mais espaços de problemas. Além disso, continuaremos a investir em Checagem de Edições e Tarefas Estruturadas, construindo uma fundação para como usar IA de modo escalável, tanto como orientação durante o processo de edição quanto como um meio de dirigir o voluntariado a oportunidades atraentes. E por último, investiremos em tornar mais visível o impacto que o voluntariado causa para criar uma experiência que tenha mais significado para ele.
- Resultado-chave WE1.2: Aumento do número de colaborações nas wikis em 55% ao ano até o final do quarto trimestre.
- Pessoas contribuidoras costumam ter dificuldade em encontrar oportunidades para colaborar umas com as outras, especialmente nos tópicos e tarefas com que elas se importam. Isto pode levar a um sentimento de solidão nas wikis para pessoas novas, e isso pode levar a burnout para pessoas editoras experientes. Além disso, o impacto de atividades colaborativas costuma não ser claro, o que pode levar a menos pessoas querendo entrar, organizar ou apoiar a colaboração nas wikis.
- Queremos tornar o valor da colaboração mais claro fazendo o seguinte:
- Criando novos meios de compartilhar o impacto de atividades colaborativas nas wikis
- Começando a coletar dados de todo o movimento sobre o impacto de atividades colaborativas
- Montando a infraestrutura básica para monitorar contribuições colaborativas, para que possamos prover novas formas inovadoras de reconhecer e recompensar contribuições no futuro
- Colaborações serão medidas pelas novas atividades criadas por meio do Event Registration na extensão CampaignEvents. O objetivo é que, ao final deste KR, nós tenhamos mais pessoas usuárias das ferramentas de extensão e novas maneiras de revelar o impacto da colaboração. Isto nos colocará numa boa posição para conectar nossa infraestrutura existente a outros meios de reconhecer e recompensar o trabalho nas wikis (como o módulo de impacto, agradecimento, etc.).
- Área focal da Lista de Desejos: Lista de Desejos da Comunidade/Áreas focais/Conectando Pessoas Contribuidoras
- Key result WE1.3: By the end of Q3, 10% of contributors who were presented with a homepage aimed towards new moderators visited it two weeks in a row.
- We believe that we can do a better job of surfacing contribution opportunities to volunteers. Long-term we believe a homepage can be helpful for any editor to organize their work, find new opportunities, and understand their impact. Our goal in FY25/26 is to surface new opportunities to experienced editors to take on moderation tasks they otherwise wouldn't necessarily have been exposed to.
- We will test this theory first by understanding how much experienced editors would engage with a homepage, similar to what newcomers have access to.
- We will then surface specific moderation activities (details to be determined) to contributors who are new to that type of moderation action, with the goal to help reduce the burden on experienced editors through reduced backlogs (under a new KR).
- If successful with the homepage concept, we plan to make this page modular to cater to the needs of communities. These modules could include things such as making it easier for editors to understand their impact.
- Notes about the methodology:
- We will have a hypothesis to define our audience, which will be part of WE1.3.1.
- "Moderators" will follow the definition started in Research:Develop a working definition for moderation activity and moderators, though followup work would be needed to narrow down the quantitative definition.
- Second week will be defined relative to the timing of each user's first visit. In this case, we'd review all new moderators who visited the homepage during a specified timeframe and then made at least one more repeat visit (7 to 14 days) later.
- Área focal da Lista de Desejos: Lista de Desejos da Comunidade/Áreas focais/Priorização de tarefas
- We believe that we can do a better job of surfacing contribution opportunities to volunteers. Long-term we believe a homepage can be helpful for any editor to organize their work, find new opportunities, and understand their impact. Our goal in FY25/26 is to surface new opportunities to experienced editors to take on moderation tasks they otherwise wouldn't necessarily have been exposed to.
- Key result WE1.4: Improve the % of unique visitors to watchlist and/or recent changes that click to view an edit.
- Our goal is to help editors with 100+ edits to more efficiently find and open edits that relate to their interests. We will explore the Task Prioritization Focus Area, deliver wishes in this area, and solicit additional feedback from volunteers on how to improve these surfaces. We can measure success by improving the efficacy of each page at "finding work", defined by the indicator metric of click-though rates.
- Key result WE1.5: Define and operationalize seven high priority metrics [1] needed for tracking progress towards achieving the goals outlined in the contributor strategy by the end of Q4, by creating a dashboard and operationalizing Monthly Active Moderator metrics.
[1] Retained editors, constructive activation, constructive edits, account registrations retained newcomers, active editors by tenure, active editors by experience level.- The contributor experience strategy envisions a 3-5 year effort to “fuel volunteer growth” and “increase retention and activation” of both new and existing contributors through three main areas of activities:
- Streamlining how volunteers can receive recommendations, manage their tasks and interests, see what’s happening on the wikis, and understand their impact
- Offering appropriately structured tasks to create more clarity and help volunteers achieve their potential by optimizing the workflows we send them to, including a continued investment in providing structured guidance and automating repetitive tasks, with a special focus on the mobile web experience
- Making contribution meaningful by showing volunteers their impact and by investing in avenues for human connection and an environment based on positive feedback
- A measurement strategy project then sketched out an extensive network of metrics for tracking this theory of change. It concluded that the primary measure of success (“core metric”) should be a count of retained editors, complemented by narrower indicator metrics like the constructive activation and contributors’ intention to return and broader “downstream” metrics like active editors and quality content. We need to ensure that we have these metrics operationalized and visible in a dashboard, so that we can track our progress towards delivering on the strategy.
Conhecimento Vital (WE2)
- Objetivo: Disponibilizar e ilustrar mais conhecimento vital em várias línguas e tópicos.
- Contexto do objetivo: Este objetivo guiará o crescimento de conteúdo que é responsável pelo interesse de pessoas contribuidoras em tópicos e línguas em particular e pela demanda das pessoas leitoras por conhecimento vital que seja bem ilustrado. Conhecimento vital é um conjunto de artigos que entregam a amplitude de tópicos necessários para uma versão utilizável da Wikipédia. Ele é definido por comunidades com referência a notoriedade, relevância, pessoas leitoras previstas e conexões entre artigos.
- Faremos uma abordagem sociotécnica, melhorando a efetividade de funcionalidades, ferramentas e processos sociais. Construiremos sobre funcionalidades de produto de alto impacto como tarefas sugeridas, busca de mídia e tradução de conteúdo mas também facilitaremos o processo de integração e o desenvolvimento de Wikipédias de línguas menores. Nós apoiaremos as pessoas organizadoras da Wikimedia que recrutam, treinam e apoiam as pessoas contribuidoras para trabalhar em metas de conteúdo compartilhadas por meio de instrumentos colaborativos como WikiProjetos e campanhas. (Estimamos que ao menos 300 pessoas organizadoras são ativas a cada trimestre.) Também desenvolveremos relações com as editoras mais relevantes para remover barreiras a materiais que sirvam de fonte. (Atualmente temos parcerias com mais de 100 dos maiores bancos de dados acessíveis somente por assinatura do mundo.)
- Para garantir que nossas intervenções tenham um impacto positivo em conhecimento vital, mediremos o aumento de conteúdo priorizado pela comunidade e a qualidade desse conteúdo, observando fatores como taxas de reversão e o número de referências e imagens.
- Resultado-chave WE2.1: Ao final do segundo trimestre, implementar e avaliar 3 intervenções que ajudem as pessoas contribuidoras a melhorar o estado do conteúdo vital em suas Wikipédias.
- Este KR destacará lacunas de conteúdo em mecanismos de edição, como a descoberta de imagens na Wikipédia, tradução de conteúdo e criação orientada de novos artigos. Nós também implementaremos e testaremos uma intervenção sociotécnica para apoiar atividades de criação de conteúdo para pequenas comunidades linguísticas. O sucesso será medido dentro de cada hipótese.
- Key result WE2.2: By end of Q4, build the platform capabilities needed to validate that we can support the Abstract Wikipedia vision at scale. We’ll know we’re successful if we show the system outputs rich, multi-lingual encyclopedic content using Wikidata and natural language generation, is controlled by the Wikimedia community, and remains performant in broad rollouts.
- Now that we can use Wikidata to output basic, plain text content on Wikipedias, the next step is to continue building platform capabilities that can support Abstract Wikipedia at scale. The platform will need to support rich, multilingual content that can be controlled by the community and stay performant at scale. This is a milestone KR as we are going from 0-1.
- Key result WE2.3: By the end of Q4, deploy an initial form of the new wiki for early community creation of Abstract articles.
- This KR sets us up to test the platform capabilities of an Abstract wiki next year. The new, standalone wiki will host the library of abstract articles built on Wikifunctions, and provide the platform capabilities necessary to later integrate abstract articles into Wikipedia in the future.
- Key result WE2.4: Align WMF and WMDE on the definition of success for the improvements to the technical infrastructure supporting a Wikidata critical use case by the end of Q2, including metrics and goals through 25-26 FY.
- The WMF Wikidata Platform (WDP) team was established and staffed - one Product Lead and one Tech Lead - in August 2025. As a new addition to a program with years of development by technical and product owners in WMF and WMDE, respectively, this goal reflects our intention of transitioning ownership through alignment on use cases, dependencies, and key success criteria. This KR will build the foundation of mutual understanding of the problem space, which we will build off of through the rest of the fiscal year (May 2026).
- Resultado-chave WE2.1: Ao final do segundo trimestre, implementar e avaliar 3 intervenções que ajudem as pessoas contribuidoras a melhorar o estado do conteúdo vital em suas Wikipédias.
Experiências de Pessoas Consumidoras (WE3)
- Objetivo: Pessoas leitoras de múltiplas gerações se engajam, e permanecem engajadas, com a Wikipédia, levando a aumentos mensuráveis de retenção e atividades de doação.
- Contexto do objetivo: Este objetivo focará em reter novas pessoas leitoras por meio de formatos inovadores de conteúdo, públicos centrais por meio do fortalecimento de experiências de leitura familiares e garantindo sustentabilidade a longo prazo aprofundando conexões de pessoas leitoras e diversificando doações. Isso incluirá uma continuação do nosso trabalho em tornar o conteúdo mais fácil de ser descoberto por meio de funcionalidades novas e mais experimentais como resumos de IA ou tocas de coelho personalizadas. Incluirá também trabalho na retenção e melhoria da qualidade da experiência de leitura mais profundamente no funil de leitura e na exploração da curadoria de leitura por meio de listas de leitura e outras participações fora do mundo da edição. Para pessoas doadoras, este trabalho continuará focando em diversificar processos de receita de dentro da plataforma.
- Resultado-chave WE3.1: Ao final do segundo trimestre, demonstrar um aumento significativo na prática de retenção de pessoas leitoras deslogadas, conforme medido por testagem A/B de uma funcionalidade por plataforma
- Este KR focará em continuar a investir em experiências que otimizam para novos meios de navegar em e aprender com conteúdo, geralmente por meio do uso de novas tecnologias e formatos - apresentando conteúdo existente de formas novas e engajantes. Neste ano fiscal, gostaríamos de continuar a experimentar com novas funcionalidades enquanto também focamos em aumentar experimentos bem sucedidos pelas wikis e plataformas. Este trabalho no KR acontecerá nas versões móvel e desktop do site, bem como os aplicativos para iOS e Android e focará na descoberta de conteúdo (navegando pontos e recomendações de verbetes) e em formatos de aprendizagem adaptáveis (resumos auxiliados por máquinas, remixagem de conteúdo).
- Área focal da Lista de Desejos: Novas experiências de pessoas consumidoras
- Resultado-chave WE3.2: Aumentar o número de doações por meio de métodos que não sejam banners ou e-mails em 5% ao ano por plataforma, por meio de intervenções no produto que promovam conexões mais profundas e reduzam o atrito para as pessoas doadoras até o final do segundo trimestre.
- Neste KR, continuaremos a explorar novos pontos de entrada para doações e outras oportunidades de converter pessoas leitoras para doadoras e retê-las por meio do aprofundamento de suas conexões com as wikis, incluindo mais conteúdo personalizado. Este KR focará em apresentar novos pontos de entrada e interagir com pontos de entrada existentes nos apps e na web, em colaboração com a equipe de captação de recursos
- Resultado-chave WE3.3: Ao final do segundo trimestre, demonstrar um aumento significativo na prática de retenção de pessoas leitoras logadas, conforme medido por testagem A/B de uma funcionalidade por plataforma
- Este KR focará em melhorar a experiência de leitura e aprendizagem para pessoas leitoras existentes e experientes, com a meta de reter nosso público atual e aprofundar sua conexão com o site para que ele possa aprender mais, bem com estar pronto e aberto para dar passos em direção à doação e à edição. O trabalho aqui focará em melhorar a experiência de leitura na web e nos apps (melhorias em leiturabilidade, melhor navegação e descoberta), bem como em construir e iterar em nossa oferta de curadoria e personalização (Lista de leitura, sugestões personalizadas, histórico de usuário e de artigo, etc)
- Resultado-chave WE3.4: Ao final do terceiro trimestre, implementar um site de cache de pequena escala que atenda nossa atual qualidade de serviço e padrões de segurança conforme nossas atuais implementações de sites de cache
- Este KR focará em provar o conceito de que nós podemos melhorar o desempenho do site e reduzir a latência para quem nos lê simplificando nossa infraestrutura de cache e melhorando o s processos para uma implementação de site de caching reduzindo o tempo de implementação de bases de cerca de um ano na média para um trimestre no máximo. O foco aqui será completar a simplificação, implementar uma PoC (sigla em inglês para Prova de Conceito), conduzir uma revisão de segurança e completar um resumo sobre proceder ou não com a implementação de nossos edge caches em nuvens públicas. Diminuir a latência pode levar a um aumento comprovado em visualizações de páginas e uma base de pessoas leitoras mais geograficamente diversa.
- Resultado-chave WE3.5: Melhorar a identificação de pessoas doadoras — garantindo que todas as pessoas leitoras conectadas que deram consentimento possam ser identificadas pelo status de pessoa doadora para uma experiência personalizada — até o final do quarto trimestre.
- Implementaremos estratégias de identificação de pessoas doadoras para garantir que todas as pessoas leitoras conectadas que deram consentimento possam ser identificadas pelo status de pessoa doadora, possibilitando uma experiência mais personalizada e engajadora. Os esforços de identificação de pessoas doadoras serão priorizados até o quarto trimestre para apoiar iniciativas de personalização e ativação mais eficazes no futuro.
- Resultado-chave WE3.6: Finalizar, publicar e comunicar uma estratégia para a experiência de pessoa leitora e consumidora da Wikipédia em todas as plataformas ao final do quarto trimestre, com metas e métricas de referência definidas, desenvolvidas em colaboração com partes interessadas e a comunidade, para guiar nosso trabalho até 2030.
- Trabalho na estratégia da pessoa consumidora continuará, com foco em construir e comunicar a estratégia internamente bem como com a comunidade e em definir e estabelecer métricas centrais para pessoas consumidoras, e suas respectivas referências.
- Contexto do objetivo: Este objetivo focará em reter novas pessoas leitoras por meio de formatos inovadores de conteúdo, públicos centrais por meio do fortalecimento de experiências de leitura familiares e garantindo sustentabilidade a longo prazo aprofundando conexões de pessoas leitoras e diversificando doações. Isso incluirá uma continuação do nosso trabalho em tornar o conteúdo mais fácil de ser descoberto por meio de funcionalidades novas e mais experimentais como resumos de IA ou tocas de coelho personalizadas. Incluirá também trabalho na retenção e melhoria da qualidade da experiência de leitura mais profundamente no funil de leitura e na exploração da curadoria de leitura por meio de listas de leitura e outras participações fora do mundo da edição. Para pessoas doadoras, este trabalho continuará focando em diversificar processos de receita de dentro da plataforma.
Segurança (WE4)
- Objetivo: Nossos sistemas protegerem melhor as contas e informações privadas de nossas pessoas editoras por padrão, enquanto oferecem mais caminhos para pessoas editoras e usuárias com direitos estendidos prevenirem e responderem a atividades abusivas.
- Resultado-chave WE4.1: Implementar um sistema de denúncias de incidentes viável e em funcionamento em todas as wikis, que seja usado e aceito por suas comunidades, até o final do segundo trimestre.
- Garantir a segurança e o bem-estar da pessoa usuária é uma responsabilidade fundamental da nossa plataforma. Muitas jurisdições têm regulações que exigem que plataformas on-line como a nossa tomem medidas contra assédio, cyberbullying e outros conteúdos prejudiciais em suas plataforma. O não cumprimento disso pode expor plataformas a responsabilidades legais e sanções regulatórias.
- Queremos empoderar nossas pessoas usuárias para poderem denunciar ameaças imediatas de prejuízo por meio de um mecanismo de denúncias facilmente encontrável e intuitivo para garantir que possamos aprender sobre tais incidentes e agir prontamente quando necessário. Isto é um paço em direção a fazer nossas pessoas usuárias se sentirem seguras ao contribuir para nossa plataforma. Faremos isso implementando um Sistema de Denúncia de Incidentes em nossas wikis.
- Resultado-chave WE4.2: Fortalecer a precisão e a eficácia das ferramentas antiabuso, implementando 2 melhorias até o final do segundo trimestre, e mais 2 até o final do quarto trimestre.
- Nós e nossa comunidade precisamos detectar e prevenir melhor atividades não autênticas e maliciosas nas wikis. Faremos isso aumentando o número e a qualidade de sinais disponíveis na plataforma, combinando esses sinais em ferramentas que disponibilizamos para pessoas usuárias com direitos estendidos e identificando one podemos fazer, com segurança, restrições automáticas em atividades suspeitas.
- Vemos também oportunidades para melhorar a acessibilidade da Wikipédia e nossos outros projetos ao mesmo tempo. Por exemplo, um projeto é substituir o CAPTCHA muito convencional e autogerido das wikis, que impede que uma pessoa usuária logue até resolver um desafio, com um serviço de pontuação de risco que raramente desafia a pessoa usuária. Em vez disso, ele marcaria silenciosamente contas com um nível de suspeitabilidade que podemos usar para desabilitar funcionalidade, e tornar este status visível para pessoas moderadoras com altos privilégios para ajudar com seu trabalho.
- Mais geralmente falando, projetos Wikimedia dependem muito do bloqueio de endereços de IP para mitigar abusos de maus agentes. Isto é cada vez mais ineficaz para deter o abuso e impacta negativamente pessoas usuárias de boa fé que são impactadas por bloqueios de IP e de faixas de IP. Neste KR, buscamos melhorar capacidades existentes e entregar novas ferramentas que possibilitem bloqueios mais precisos e eficazes de maus agentes e que diminuam o dano colateral causado por bloqueios de IP e de faixas de IP.
- Para medir nossa efetividade, olharemos para feedback qualitativo do voluntariado engajado em trabalho antiabuso e indicadores quantitativos como a taxa de bloqueios de IP sendo implementados, a adoção de mitigações baseadas em sinal de reputação de IP e de navegador, a taxa de interações provavelmente humanas quando uma pessoa usuária é bloqueada e a adoção de novos sinais em ferramentaria antiabuso.
- Trabalho neste KR envolve detecção e mitigação de fantoches e evasão de bloqueios melhoradas, revelação de informações sobre o potencial para danos colaterais, fortalecimento da detecção de robôs, revelação de sinais ao voluntariado antiabuso, eficiência melhorada em interfaces de ferramentaria antiabuso, melhoria de métricas relacionadas a abusos e fornecimento de sugestões de atividade suspeita de contas para investigação a pessoas verificadoras.
- Resultado-chave WE4.3: Reduzir o número de ataques em larga escala que requerem intervenção humana de SRE (sigla em inglês para Engenharia de Confiabilidade do Site, ou para profissionais do ramo) em 50% (comparando ano fiscal a ano fiscal) até o final do quarto trimestre.
- A evolução do cenário da Internet, incluindo o surgimento de botnets em grande escala e ataques mais frequentes, tornou obsoletos nossos métodos tradicionais de limitação de abusos em larga escala. Esses ataques podem tornar nossos sites inacessíveis por meio da inundação da nossa infraestrutura com solicitações, ou sobrecarregar a capacidade da nossa comunidade de combater o vandalismo em grande escala. Isso também coloca uma pressão excessiva sobre nossas pessoas editoras com privilégios de nível alto e em nossa comunidade técnica.
- Precisamos urgentemente melhorar nossa capacidade de automaticamente detectar, suportar e mitigar ou parar tais ataques.
- Neste ano nós focaremos principalmente em automatizar a detecção de endereços e redes IP que regularmente realizam ataques contra nós, ou reduzir o tamanho da carga que essas entidades persistentemente danosas podem colocar em nossos sistemas.
- Resultado-chave WE4.4: Implementar contas temporárias em 100% dos nossos projetos de modo que a exposição de informações pessoalmente identificáveis de nossas pessoas editoras não registradas fique disponível para menos de 0,1% das pessoas usuárias registradas, até o final do segundo trimestre.
- Contas temporárias buscam melhorar a privacidade e, consequentemente, a segurança de nossas pessoas editoras não registradas ocultando suas informações pessoais identificáveis (endereços IP) da visualização pública e limitando o acesso a apenas as pessoas que precisam delas para fins de patrulhamento. Além de ser uma grande melhoria para a segurança das pessoas usuárias, este projeto também é importante para cumprir com muitas obrigações regulatórias.
- Resultado-chave WE4.5: Avaliar o impacto da IA generativa em confiança e segurança e determinar intervenções de produto para tirar proveito de oportunidades e prevenir ameaças a projetos Wikimedia até o final do terceiro trimestre.
- O uso da IA e em particular IA generativa está aumentando rapidamente pela internet. Existem oportunidades de confiança e segurança bem como ameaças que emergem com a IA se tornando onipresente. Por exemplo, conteúdo fica mais fácil e barato de gerar, mas a moderação é mais desgastante. Similarmente, pesquisas podem ser realizadas com muito menos esforço, mas alucinações de IA são mais difíceis de identificar.
- Este projeto busca construir sobre a Avaliação de Impacto em Direitos Humanos de aprendizagem de máquina/IA avaliando o impacto da IA em aspectos de confiança e segurança do ecossistema Wikimedia. Isto inclui:
- Consultar pessoas usuárias com direitos estendidos.
- Identificar exemplos de abuso assistido por IA generativa e potenciais mitigações.
- Identificar oportunidades de aprendizagem de máquina para diminuir o fardo de pessoas usuárias com direitos estendidos.
- Realizar experimentos para entender em que devemos focar, de modo a realizar o maior impacto.
- Resultado-chave WE4.6: Fazer valer tecnicamente que 100% dos privilégios que permitem a pessoas usuárias tomarem medidas de segurança ou delicadas do ponto de vista da privacidade possam ser realizadas apenas por contas que tenham habilitado autenticação em dois fatores até o final do quarto trimestre.
- Precisamos fortalecer a segurança das contas de pessoas usuárias em nossas wikis, particularmente para pessoas usuárias com permissões delicadas. Um foco-chave é exigir que qualquer ação delicada possa apenas ser tomada por pessoas usuárias que habilitaram autenticação em dois fatores. Construiremos um sistema mais extensível para fiscalização de privilégios que dispensará a necessidade de auditorias e fiscalização manual de autenticação em dois fatores, e expandiremos quais privilégios exigem que a autenticação em dois fatores seja habilitada na plataforma.
- Como parte disto, melhoraremos nossos sistemas de autenticação e recuperação para que nós (WMF) e nossas pessoas usuárias possam apoiar mais facilmente uma postura mais rígida com relação à autenticação em dois fatores. Expandiremos a disponibilidade geral da autenticação em dois fatores em toda a plataforma, de modo que toda pessoa usuária possa habilitá-la como desejado e para garantir que seja habilitada antes de privilégios delicados serem concedidos. Focaremos nossa atenção também em reduzir a carga operacional suportada por nossos sistemas de recuperação e suporte a contas, ajudando a otimizar nossos processos de reset e recuperação de login de contas. Pretendemos ainda melhorar a usabilidade da nossa implementação de autenticação em dois fatores, oferecendo às pessoas usuárias mais opções para tornar suas contas seguras e evitar que fiquem acidentalmente impedidas de logar.
Uso Responsável de Infraestrutura (WE5)
- Objetivo: Pessoas desenvolvedoras e reutilizadores acessam conteúdo de conhecimento em caminhos curados, garantindo a sustentabilidade da nossa infraestrutura e o reúso responsável de conteúdo.
- Contexto do objetivo: Este objetivo focará em estabelecer caminhos para o reúso responsável de conteúdo.
- A Wikimedia hospeda a maior coleção de conhecimento curado por humanos na web. Isto tornou nossa infraestrutura de conhecimento um destino de valor imensurável não apenas para humanos, mas também para consumidores automáticos de dados. Nosso conteúdo alimenta mecanismos de busca, plataformas de mídias sociais, e-commerce e desde o surgimento das IAs, é usado para treinar modelos de aprendizagem de máquina. Pessoas consumidoras exploram dados raspando páginas, usando as APIs, baixando conteúdo – geralmente sem atribuição. No mundo do tráfego não autenticado nós não podemos diferenciar confiavelmente uma pessoa usuária da outra, o que limita muito nossa capacidade de propiciar e fiscalizar o uso responsável da nossa infraestrutura: Como podemos continuar a propiciar nossa comunidade ao mesmo tempo em que estabelecemos limites para o consumo automático de conteúdo? Como podemos afunilar as pessoas usuárias em canais de preferência e suportados? Que orientações precisamos incentivar o reúso responsável de conteúdo? Como podemos nos dirigir a uma experiência de pessoa desenvolvedora coesa e construir produtos que atendam as necessidades de pessoas desenvolvedoras, equipes e reutilizadores? Enquanto essas perguntas não são todas novas, a urgência de lidar com elas cresceu exponencialmente: Desde 2024 estamos observando um aumento dramático no volume de requisições, com a maior parte do aumento vindo de robôs de raspagem coletando dados de treinamento para fluxos de trabalho e produtos movidos a IA. A carga em nossa infraestrutura não é sustentável e põe em risco o acesso humano ao conhecimento: Precisamos agir agora para restabelecer um equilíbrio saudável, para que possamos apoiar efetivamente os projetos Wikimedia e permitir o sucesso sustentável de nossa missão.
- Resultado-chave WE5.1: Até o final do quarto trimestre, 50% das solicitações aos canais de acesso programático poderão ser atribuídas a uma pessoa desenvolvedora ou aplicação conhecidos.
- Nós atualmente temos meios limitados para identificar quem é responsável por tráfego automatizado e, diferente do ambiente nas wikis, meios limitados de contatar pessoas usuárias ou regular seu acesso. Vimos um aumento significativo no volume de tráfego externo, o que não é sustentável para nós e põe em risco o acesso humano a conhecimento. Buscamos aumentar a porcentagem de tráfego automatizado que é atribuído a uma conta conhecida exigindo autenticação ou autorização com base em níveis diferentes de acesso para raspagem e uso de API em nível alto. Isto nos ajudará a identificar quem está reutilizando o conteúdo em larga escala, permitindo-nos proteger nossa infraestrutura e melhorar a governança sobre uso justo, enquanto atendemos as suas necessidades mais eficientemente. Continuaremos a explorar maneiras de apoiar melhor a comunidade técnica com uma experiência de pessoa desenvolvedora mais coesa que proteja o acesso preferencial a membros da comunidade e permite novas funcionalidades para pessoas desenvolvedoras.
- Resultado-chave WE5.2: Até o final do quarto trimestre, 70% dos endpoints da API web da Wikimedia terão suporte de uma infraestrutura comum.
- Buscamos melhorar a experiência e sustentabilidade de nossos caminhos para pessoas desenvolvedoras oferecendo APIs web mais consistentes, estáveis e encontráveis para todas as pessoas desenvolvedoras da Wikimedia. Nós simplificaremos nossa oferta de API apresentando uma infraestrutura mais centralizada para capacidades de API centrais, permitindo-nos ter caminhos e governança consistentes para: especificações e documentação OpenAPI, identificação e controles de acesso para pessoas desenvolvedoras, aplicação de política de API, roteamento, versionamento e gestão de erros. Otimizando nossa oferta de API, tornaremos mais rápido, mais fácil e mais prazeroso construir ferramentas, robôs, projetos de pesquisa e funcionalidades que servem a missão Wikimedia. Esta abordagem apoia o futuro multigeracional da nossa missão reduzindo os custos de manutenção de infraestrutura API, aumentando a visibilidade e controle de acesso para combater maus agentes e promovendo uma comunidade mais forte de pessoas desenvolvedoras.
- Resultado-chave WE5.3: Até o final do quarto trimestre, novas diretrizes de atribuição para web, aplicativos, assistentes de voz e LLMs serão publicadas e linkadas em todos os sites da Wikimedia, com duas demonstrações de reutilização implantadas que gerem engajamento mensurável e um parceiro externo de reutilização adotando as melhores práticas de atribuição.
- Para aumentar a devida atribuição de conteúdo Wikimedia, forneceremos orientações claras de melhores praticas que promovam o reúso responsável. Isto inclui criar diretrizes de atribuição para plataformas chave (web, aplicativos, voz, multimedia) e exibir ao menos dois exemplos práticos destacando aplicações exemplares de conteúdo Wikimedia. Exemplos de resultados incluem encorajar organizações midiáticas a creditarem imagens do Wikimedia Commons, mecanismos de busca a revelarem dados da Wikimedia mais eficientemente ou assistentes de IA a integrarem o conhecimento da Wikipédia de formas transparentes e responsáveis que aumentem a confiança em sua confiabilidade. Fortalecer práticas de atribuição não apenas aumenta a conscientização do público e dirige o engajamento de volta para os projetos Wikimedia, como também ajuda a estabelecer meios responsáveis e novos de remixar conhecimento e a reter o uso indevido.
- Resultado-chave WE5.4: Reduzir a quantidade de tráfego gerado por agentes de raspagem em 20% quando medido em termos de taxa de requisições, e em 30% em termos de largura da banda
- A raspagem sempre existiu: os mecanismos de busca confiaram na Wikipédia para prover informações a suas pessoas usuárias por décadas; contudo, ultimamente há outra grande motivação para raspar nossos dados: é o maior conjunto curado e multilíngue de conhecimento que você pode encontrar na internet e é uma ferramenta fundamental para treinar modelos de linguagem de grande escala. Isto vale tanto para nosso conteúdo enciclopédico quanto para nosso repositório multimídia, o Wikimedia Commons, que tem valor inestimável para modelos de aprendizagem de máquina que geram imagens.
- Como consequência, ao longo do último ano, vimos um aumento significativo na quantidade de tráfego de raspagem, e também de incidentes relacionados de estabilidade do site: Pessoas Engenheiras de Confiabilidade do Site tiveram de fiscalizar caso a caso a limitação da taxa ou o banimento de rastreadores repetidamente para proteger nossa infraestrutura. A raspagem se tornou tão proeminente que nossa largura de banda para dados saindo aumentou 50% em 2024. Além disso, uma análise recente mostrou que ao menos 65% de nossas requisições mais caras (aquelas que não pudemos servir com nossos servidores de cache e que são servidas dos bancos de dados principais) são feitas por robôs.
- Nossos recursos computacionais são extremamente limitados comparados à quantidade de tráfego que fazemos, então temos que priorizar quem servimos com esses recursos, e queremos favorecer o consumo humano e priorizar o apoio aos projetos e pessoas contribuidoras da Wikimedia com nossos recursos escassos.
- Resultado-chave WE5.1: Até o final do quarto trimestre, 50% das solicitações aos canais de acesso programático poderão ser atribuídas a uma pessoa desenvolvedora ou aplicação conhecidos.
Acelerar o Caminho para Resultados de Produtos (WE6)
- Objetivo: Pessoas desenvolvedoras da Wikimedia liberam seus produtos às pessoas usuárias finais com rapidez e confiança.
- Contexto do objetivo: Para terem efetividade em atingir os 4 pilares estratégicos, pessoas desenvolvedoras da Wikimedia precisam dispensar seu tempo e esforço em atividades de alta alavancagem que resultam na entrega de produtos de qualidade o mais cedo possível. Fluxos de trabalho exageradamente complicados, falta de ferramentas padrão e componentes de sistemas insustentáveis atrapalham esses resultados.
- Este trabalho constrói sobre a crescente que desenvolvemos nos últimos 2 planos anuais envolvendo a MediaWiki como uma plataforma e o software que sustenta seu desenvolvimento e implementação. O trabalho para este ano focará em prover ambientes de pessoas desenvolvedoras mais confiáveis, simplificar os fluxos de trabalho de pré-produção e reduzir os riscos de plataforma e infraestrutura.
- Resultado-chave WE6.1: Ao final do quarto trimestre, o número de bugs que bloqueiam treinamentos e ultrapassam as wikis de testes é reduzido em 10%
- Em 2024, houve 144 vezes em que pessoas desenvolvedoras tiveram de revisitar seu trabalho porque houve uma emergência impedindo a implementação do MediaWiki. Em muitos desses casos, os bugs foram pegos após implementação nas testwikis, ou seja, o problema atingiu um público potencialmente na casa das bilhões de pessoas usuárias. Não podemos controlar o fato de que bugs vão existir, mas pegá-los antes significaria que seria preciso menos trabalho de herói. Isso construiria também confiança nas pessoas desenvolvedoras de que quando algo vai pra etapa de produção real, não haverá incêndio para apagar.
- Pegaremos estes bugs mais cedo fornecendo os ambientes que pessoas desenvolvedoras precisam para entregar e testar confiantemente seus códigos através do ciclo de desenvolvimento e implementação. Precisamos também garantir que essas melhorias não venham às custas da velocidade das pessoas desenvolvedoras.
- Resultado-chave WE6.2: Ao final do quarto trimestre, 4 passos do checklist de revisão da prontidão da produção podem ser executados sem intervenção de SRE
- Implementar em produção um novo serviço ou funcionalidade atualmente depende de uma lista de 24 passos na qual cada passo geralmente precisa de apoio de SREs Estabelecemos o programa de pessoas embaixadoras de SRE para intervir mais cedo no ciclo de desenvolvimento e capacitar as próprias equipes de desenvolvimento, mas muitas das tarefas deveriam ser totalmente autoaproveitáveis. Atualmente, elas acontecem na forma de trabalho manual, repetitivo, automatizável e que aumenta de escala linearmente com o número de equipes de desenvolvimento. Isto não é sustentável para a equipe de SRE a longo prazo.
- No passado, muito desse trabalho era abstraído de equipes de desenvolvimento por meio da manutenção de um conjunto de bibliotecas comuns compartilhadas e melhores práticas para interagir com nossa plataforma. Elas foram abandonadas quando adotamos a nova infraestrutura Kubernetes e elas não têm um substituto direto. Ao fornecer bibliotecas similares, documentações e treinamentos que se apliquem ao novo meio com que construímos e implementamos coisas hoje, acreditamos que podemos reduzir a quantidade de envolvimento necessária da SRE antes de implementar um novo serviço ou funcionalidade em produção.
- Resultado-chave WE6.3: Ao final do quarto trimestre, 100% das visualizações de páginas da Wikipédia são servidas por meio do Parsoid
- O Parsoid oferece capacidades aprimoradas para a evolução de wikitexto e para tornar a plataforma à prova de futuro. Manter dois serviços de parsing atualmente não é sustentável a longo prazo, pois ele aumenta o débito técnico e a complexidade. Além disso, o sucesso de alguns novos projetos como as Wikifunções depende do Parsoid estar amplamente disponível.
- Temos ampliado a escala da implementação em projetos menores e neste ano estaremos de prontidão para as Wikipédias. Servir todas as leituras de visualização de páginas da Wikipédia por meio do Parsoid é o próximo marco mais importante. Além da implementação em si, este trabalho também inclui resolver questões de desempenho e comunicar efetivamente acerca do impacto a pessoas leitoras e editoras.
- Resultado-chave WE6.4: Ao final do segundo trimestre, ao menos dois riscos identificados que ameaçam nossa capacidade de continuar a implementar ou aumentar a escala das wikis foram mitigados ou reduzidos a um nível aceitável
- Por meio de algumas iniciativas direcionadas, reduziremos ou mitigaremos vários riscos de escalabilidade, confiabilidade ou segurança que identificamos como uma possível ameaça potencial ao crescimento e sustentabilidade de nossas plataformas e nossos projetos públicos.
- Por exemplo, nós iremos refatorar a estrutura dos bancos de dados centrais do Commons para garantir que seu crescimento não seja limitado pela capacidade do hardware de servidores disponível dentro dos próximos poucos anos. Vamos também aprimorar o PHP, a linguagem de programação que alimenta o MediaWiki e serviços relacionados, para uma versão mais moderna. Outros riscos identificados provavelmente demandarão a implementação de medidas adicionais de segurança para proteger e blindar nossa infraestrutura.
- Resultado-chave WE6.1: Ao final do quarto trimestre, o número de bugs que bloqueiam treinamentos e ultrapassam as wikis de testes é reduzido em 10%
Sinais e Serviços de Dados (SDS, na sigla em inglês)
Métricas (SDS1)
- Objetivo: As pessoas tomadoras de decisão usam métricas mais confiáveis e oportunas para fundamentar as decisões sobre produto e estratégia.
- Contexto do objetivo: Utilizamos métricas para informar as decisões da Fundação sobre onde concentrar nossos esforços para melhor servir ao Movimento. No entanto, alguns de nossos canais de dados são propensos a falhas, causando atrasos na entrega. Quando surgem problemas com os dados, nosso tempo de identificação e resolução é longo demais. Além disso, muitos de nossos conjuntos de dados não são otimizados para facilitar a exploração de tendências e carecem de dimensões que se revelaram importantes para a interpretação dos dados. Esses problemas retardam e limitam nossa capacidade de avaliar métricas.
- No ano fiscal de 2025-2026, vamos nos concentrar em casos de uso específicos do plano anual para resolver as lacunas de qualidade dos dados em nossos pipelines atuais, configurar infraestrutura e processos para monitorar e resolver problemas de qualidade dos dados e fornecer ferramentas que permitam às pessoas tomadoras de decisão entender as tendências.
- Um caso de uso é sobre como medimos o tráfego humano e de bots. O aumento do tráfego automatizado nos últimos dois anos tornou mais difícil entender até que ponto os seres humanos estão interagindo e contribuindo para os projetos da Wikimedia. Nosso objetivo é melhorar nossa capacidade de avaliar os padrões de tráfego humano e de bots, que são informações essenciais para o planejamento e as decisões sobre produtos.
- Resultado-chave SDS1.1: Ao final do primeiro trimestre, analistas que usam métricas de visualizações de páginas podem acessar mensurações básicas de qualidade de dados e detecção de tráfego automatizado
- Por meio de hipóteses exploradas neste KR, nós buscamos identificar lacunas em nossa heurística atual de detecção de tráfego automatizado e entender onde eles falham em categorizar apropriadamente o tráfego de visualização de páginas. Essas percepções fundamentarão melhorias nos meios que geram e classificam métricas de visualização de páginas. Além disso, definiremos métricas de qualidade de dados para monitorar e medir melhorias na precisão dos dados.
- Este KR abrirá caminho para um KR subsequente focado na implementação das melhorias necessárias dos meios identificados aqui. As métricas de qualidade dos dados estabelecidas nesta fase servirão como benchmarks para avaliar a efetividade desses aprimoramentos futuros.
- Resultado-chave SDS1.2: Até o final do segundo trimestre, todas as seis pipelines de dados dependentes do conjunto de dados do histórico do wikitexto terão garantias de entrega semanal (SLOs) para as fontes de entrada do histórico do wikitexto.
- O objetivo do resultado-chave 1.4 para o ano fiscal de 2024/25 foi eliminar a dependência dos conjuntos de dados mediawiki_wikitext_history e mediawiki_wikitext_history_current, atualizados mensalmente, para os três pipelines downstream mais relevantes e fornecer um conjunto de dados alternativo com SLOs semanais garantidos.
- Embora o resultado-chave 1.4 do ano fiscal de 2024/25 tenha ajudado a mitigar os problemas de confiabilidade dos pipelines dependentes mais relevantes, ainda existem pipelines com fontes de entrada antigas e não confiáveis. Esses pipelines também devem ser migrados, assim como a fonte de entrada baseada em arquivos, para o próprio conjunto de dados do histórico do wikitexto.
- Key result SDS1.3: By the end of Q2, bot detection incorporates 1 additional signal and generates automated alerts for anomalies.
- Across the Foundation, teams are making product and funding decisions based on being able to determine the difference between human readership and automated traffic. The Data Platform is the central repository for bot detection signals and batch analysis. Through the hypotheses we've scoped through Q1/Q2, we plan to begin introducing new bot detection signals to sharpen our analysis of automated traffic, and to begin making the process of introducing new signals both efficient and repeatable.
- Key result SDS1.4: By the end of Q2, decision makers have a clear understanding of the current state of insights provided by our organizational metrics. We’ll know we’re successful if we provide a board meeting ready presentation deck that situates analysis of our metrics within both the Wikimedia ecosystem, as well as within broader internet trends and challenges in the market.
- Insights from our organizational metrics are used to make a myriad of decisions across the foundation, including decisions around how we build our product, how we allocate infrastructure resources, and how we fundraise. At the same time, the landscape of the internet is evolving, with automated traffic in particular affecting our metrics. The goal is for Foundation leadership to enter the December board meeting with a clear narrative about threats to, and opportunities within, the Wikimedia ecosystem supported by confident analysis of internal metrics and external trends. We can tell this story by gathering insights, metrics, and data points that tell us with confidence about:
- Trends in our internal measures of readership (pageviews)
- Trends in our contributor ecosystem
- Trends from external data and competitor benchmarks
- Insights from internal and external studies and trusted research
- Insights from our organizational metrics are used to make a myriad of decisions across the foundation, including decisions around how we build our product, how we allocate infrastructure resources, and how we fundraise. At the same time, the landscape of the internet is evolving, with automated traffic in particular affecting our metrics. The goal is for Foundation leadership to enter the December board meeting with a clear narrative about threats to, and opportunities within, the Wikimedia ecosystem supported by confident analysis of internal metrics and external trends. We can tell this story by gathering insights, metrics, and data points that tell us with confidence about:
- Resultado-chave SDS1.1: Ao final do primeiro trimestre, analistas que usam métricas de visualizações de páginas podem acessar mensurações básicas de qualidade de dados e detecção de tráfego automatizado
Plataforma de Experimentação (SDS2)
- Objetivo: Gerentes de produtos podem avaliar com rapidez, facilidade e confiança os impactos de mudanças em funcionalidades de produtos na Wikipédia.
- Contexto do objetivo: Para propiciar e acelerar a tomada de decisão fundamentada em dados sobre desenvolvimento de funcionalidades de produtos, gerentes de produto precisam de uma plataforma de experimentação na qual eles possam definir funcionalidades, selecionar públicos de pessoas usuárias para tratamento e ver medições de impacto. Acelerar o tempo do lançamento até a análise é essencial, pois reduzir o tempo para aprender acelerará a experimentação e, enfim, a inovação. Tarefas manuais e abordagens individualizadas a medições foram identificadas como barreiras à velocidade. O cenário ideal é que gerentes de produto possam ir do lançamento do experimento à descoberta com pouca ou nenhuma intervenção de analistas ou profissionais de engenharia.
- Focaremos na Wikipédia para o próximo ano fiscal porque é onde o Experiências Centrais tem interesse em experimentação (a estratégia organizacional nos faz duplicar a aposta na Wikipédia), e porque isso nos permite focar e sinalizar mais claramente com que equipes e projetos nós estamos lidando. Outras equipes usaram os componentes da plataforma de experimentação e podem continuar a fazê-lo, mas este uso não será o foco deste objetivo.
- Resultado-chave SDS2.1: Até ao final do segundo trimestre, permitir a conclusão de, pelo menos, dois ciclos completos de experimentação utilizando a plataforma de experimentação.
- À medida que a organização enfatiza cada vez mais as decisões sobre produtos baseadas em dados, precisamos tornar a experimentação acessível a todas as equipes de produto, não apenas àquelas com habilidades especializadas. As equipes de produto precisam de padrões, ferramentas e infraestrutura compartilhados que lhes permitam:
- Teste rapidamente ideias em nossa base global de pessoas usuárias
- Medir o impacto das mudanças no produto com métricas padronizadas
- Compartilhar os resultados de forma transparente com as partes interessadas do nosso Movimento
- Por que estamos mudando o foco do número de “equipes habilitadas” para “experimentos concluídos”:
- Alinhamento estratégico: é a principal métrica de sucesso da plataforma
- Abordagem baseada em dados: nossa pesquisa com pessoas usuárias (em andamento) sugere que a equipe não está totalmente preparada em toda a organização, embora saibamos que a equipe da Web confirmou interesse em dois experimentos específicos.
- Otimização de recursos: a implementação da nossa plataforma MVP exigirá uma integração intensiva, tornando mais eficiente, a curto prazo, concentrar-se em oportunidades de experimentação, em vez de espalhar-se por várias equipes. Pretendemos avançar para um lançamento geral e não queremos reinvestir na formação de equipes, se for possível evitar.
- Foco no futuro: o feedback dos ciclos completos de experimentação irá informar as melhorias da nossa plataforma de forma mais eficaz do que os aprendizados obtidos com a adoção parcial ou incompleta. À medida que avançamos em direção ao lançamento geral, o foco na conclusão da experimentação evita o investimento em abordagens temporárias que precisariam ser redesenvolvidas.
- Estamos realizando uma pesquisa de pessoas usuárias para identificar as necessidades e exigências das equipes: pesquisas e entrevistas estão sendo agendadas para esclarecer as necessidades da equipe de produto na segunda quinzena de maio de 2025. Assim que a pesquisa for concluída, criaremos um calendário de experimentação que poderá ser usado para definir nossas próximas metas de resultados-chave (KR) e prioridades.
- À medida que a organização enfatiza cada vez mais as decisões sobre produtos baseadas em dados, precisamos tornar a experimentação acessível a todas as equipes de produto, não apenas àquelas com habilidades especializadas. As equipes de produto precisam de padrões, ferramentas e infraestrutura compartilhados que lhes permitam:
- Resultado-chave SDS2.1: Até ao final do segundo trimestre, permitir a conclusão de, pelo menos, dois ciclos completos de experimentação utilizando a plataforma de experimentação.
Públicos Futuros (PF)
Públicos Futuros (PF1)
- Objetivo: A Fundação Wikimedia é equipada com recomendações sobre investimentos estratégicos para buscar que ajudem nosso movimento a servir novos públicos numa internet em transformação.
- Contexto do objetivo: Devido a mudanças em andamento na tecnologia e no comportamento da pessoa usuária online (ex: preferência crescente por obter informações em aplicativos sociais, popularidade do edutenimento em vídeos curtos, o surgimento da IA generativa), o movimento Wikimedia enfrenta desafios em atrair e reter pessoas leitoras e contribuidoras. Essas mudanças também trazem oportunidades para servir novos públicos criando e entregando informações de novas maneiras. Contudo, nós como movimento não temos um quadro claro e fundamentado em dados sobre os benefícios e sacrifícios de diferentes estratégias potenciais que podemos buscar para superar os desafios ou aproveitar novas oportunidades. Por exemplo, deveríamos...
- Investir em novas funcionalidades grandes como chatbots?
- Levar o conhecimento e os diferentes caminhos para a contribuição da Wikimedia para plataformas populares de terceiros?
- Algo mais?
- Para assegurar que a Wikimedia se torne um projeto multigeracional, testaremos hipóteses para melhor compreender e recomendar estratégias promissoras – para a Fundação Wikimedia e o movimento Wikimedia – a serem buscadas para atrair e reter públicos futuros.
- Resultado-chave PF1.1: Como resultado das percepções e recomendações de Públicos Futuros, ao final do terceiro trimestre ao menos um objetivo ou resultado-chave de uma equipe sem ligação com Públicos Futuros está presente no esboço para o plano anual do ano seguinte.
- Desde 2020, a Fundação Wikimedia vem monitorando tendências externas que podem impactar nossa capacidade de servir futuras gerações de pessoas consumidoras e contribuidoras de conhecimento e continuar sendo um movimento próspero de conhecimento livre para as próximas gerações. O Públicos Futuros, uma pequena equipe de P&D, irá:
- Realizar experimentos rápidos e com prazo determinado (visando pelo menos 3 experimentos por ano fiscal) para explorar maneiras de abordar essas tendências
- Com base em percepções de experimentação, fazer recomendações para novos investimentos não experimentais que a WMF deveria buscar – ou seja, novos produtos ou programas que precisam ser tocadas por uma equipe ou equipes inteiras – durante nosso período regular de planejamento anual.
- Este resultado-chave será cumprido se ao menos um objetivo ou resultado-chave de uma equipe fora do Públicos Futuros e que é guiado por uma recomendação de Públicos Futuros aparecer no esboço do plano anua para o próximo ano fiscal.
- Desde 2020, a Fundação Wikimedia vem monitorando tendências externas que podem impactar nossa capacidade de servir futuras gerações de pessoas consumidoras e contribuidoras de conhecimento e continuar sendo um movimento próspero de conhecimento livre para as próximas gerações. O Públicos Futuros, uma pequena equipe de P&D, irá:
- Resultado-chave PF1.1: Como resultado das percepções e recomendações de Públicos Futuros, ao final do terceiro trimestre ao menos um objetivo ou resultado-chave de uma equipe sem ligação com Públicos Futuros está presente no esboço para o plano anual do ano seguinte.
- Contexto do objetivo: Devido a mudanças em andamento na tecnologia e no comportamento da pessoa usuária online (ex: preferência crescente por obter informações em aplicativos sociais, popularidade do edutenimento em vídeos curtos, o surgimento da IA generativa), o movimento Wikimedia enfrenta desafios em atrair e reter pessoas leitoras e contribuidoras. Essas mudanças também trazem oportunidades para servir novos públicos criando e entregando informações de novas maneiras. Contudo, nós como movimento não temos um quadro claro e fundamentado em dados sobre os benefícios e sacrifícios de diferentes estratégias potenciais que podemos buscar para superar os desafios ou aproveitar novas oportunidades. Por exemplo, deveríamos...
Vídeos sociais (PF2)
- Objetivo: Pessoas jovens (<25 anos de idade) amam, aprendem com, se engajam com e compartilham conteúdo da Wikipédia em plataformas onde elas gostam de passar tempo online.
- Contexto do objetivo: A experimentação de Públicos Futuros com vídeos curtos neste ano fiscal mostrou que podemos atingir públicos mais jovens em larga escala nessas plataformas, mas nossos dados de saúde de marca mostram que nosso investimento anual não é suficiente para compensar a queda na consciência e afinidade do público com a Wikipédia entre públicos da Geração Z.
- A fim de garantir que nós efetivamente atinjamos e engajemos com esta geração, acreditamos que precisaremos adotar várias táticas e aumentar significativamente nosso engajamento em áreas como marketing pago e com pessoas influenciadoras, campanhas criativas, tendo responsividade a tendências e aumentando nosso nível de experimentação nesses canais.
- Esperamos que esses desafios que estamos enfrentando demandarão mais investimentos substanciais para nos ajudar a superá-los, particularmente em esforços de Comunicações e Marketing para criar engajamento, bem como colaborações interdepartamentos para criar novos produtos e experiências direcionadas para o aumento da presença da marca e do conteúdo da Wikipédia nessas plataformas.
- Resultado-chave PF2.1: Gerar 9.500.000 de visualizações de conteúdo de vídeos curtos em todos os canais que temos até o final da primeira metade do ano.
- Neste ano, atingimos um alcance de aproximadamente 1 milhão de visualizações 3 meses após lançar vídeos curtos nos canais @Wikipedia no TikTok, Instagram e YouTube. No início do próximo ano fiscal, esperamos mais pessoas seguidoras nos canais que temos e mais percepções sobre conteúdo efetivo/engajador que podemos pôr em prática para alcançar ainda mais pessoas visualizadoras.
- Estabelecendo uma meta ambiciosa na primeira metade do ano, esperamos nos dirigir para um impacto mais significativo, permitir a criação de novas estratégias/processos para facilitar o trabalho e sermos capazes de defender a necessidade de recursos adicionais para atingir esta meta.
- Key result FA2.2: Grow our off-platform following on TikTok from the Mid tier (100k–250k followers) to the Macro tier (250k–1M followers) by the end of FY25/26 (June 2026).
- We’re currently in the Mid tier of TikTok following (100k–250k followers), and our goal is to reach the Macro tier (250k–1M followers) by the end of FY25/26 (June 2026). These tiers—Micro, Mid, and Macro—are standard benchmarks in the industry for audience size and reach. To get there, we’ll refine our content strategy to better attract Gen Z followers and increase our overall visibility through community management. H1 performance will inform tactical adjustments in H2 to accelerate growth and hit this milestone.
- Resultado-chave PF2.3: Lançar um produto fora da plataforma direcionado nos novos métodos de aprendizagem e consumo de mídia dos públicos futuros e trazê-lo ao mercado por meio de uma campanha colaborativa de branding e marketing de produto.
- O Públicos Futuros geralmente trabalha em experimentos de pequena escala com marketing mínimo/orgânico. Neste ano, gostaríamos de reservar tempo para uma campanha de novo produto + marketing de escala maior direcionada a públicos mais jovens fora da plataforma.
- Resultado-chave PF2.1: Gerar 9.500.000 de visualizações de conteúdo de vídeos curtos em todos os canais que temos até o final da primeira metade do ano.
Suporte a Produto e Engenharia (PES, na sigla em inglês)
Suporte a Produto e Engenharia (PES1)
- Objetivo: Equipes de Produto e Engenharia da WMF são mais efetivos devido a processos melhorados, promovendo uma mudança positiva em nossa cultura.
- Contexto do objetivo: Este objetivo é sobre tornar as formas de trabalho da Fundação Wikimedia mais rápidas, inteligentes e melhores. Tem tudo a ver com como trabalhamos. Isto significa menos atrito e obstáculos (ineficiências e erros) em processos, e atingir impacto mais rapidamente. Este objetivo é também sobre aprender formas de trabalho que podem ser adotadas por todo o departamento e organização.
- Resultado-chave PES1.1: Ao final do segundo trimestre, definir SLOs para 6 serviços de produção com base em uma rubrica de priorização que busca maximizar nossa aprendizagem de como definir e usar SLOs para tomar decisões fundamentadas sobre priorização de trabalho relacionado a confiabilidade por equipes de partes interessadas.
- Um Objetivo de Nível de Serviço (SLO, na sigla em inglês) é um acordo entre equipes de partes interessadas sobre um nível de serviço desejado (confiabilidade/desempenho) que as equipes colaboram para alcançar (e não exceder muito). Por exemplo, ele ajuda a determinar quando trabalho de confiabilidade ou desempenho deveria ser priorizado ou despriorizado por uma equipe de desenvolvimento, ou o que constitui um problema. Equipes precisam se importar em identificar o que é imediato (alertar/resposta a incidents/bugs críticos) ante o que não é. O objetivo é reduzir atritos entre funções por meio d negociação de alvos e da fundamentação compartilhada e clara de priorizações.
- Resultado-chave PES1.2: Até o final do segundo trimestre, sinais da comunidade (incluindo a Lista de Desejos) terão influenciado a WMF a priorizar ao menos 5 fluxos de trabalho de produto para o terceiro e quarto trimestres.
- Nossa meta é identificar e celebrar quando equipes priorizam o trabalho baseado em pedidos da comunidade baseados em evidência.
- Duas hipóteses planejadas são focadas na Lista de Desejos, exclusivamente. Elas são elaboradas para melhorar a confiança, otimizar processos e aumentar a participação das equipes e do voluntariado. Outra hipótese é um experimento elaborado para ver se há sinais valiosos suficientes de esplanadas, etc., e se a IA pode apoiar nossos esforços de coleta de sinais.
- Resultado-chave PES1.3: Dois experimentos interdepartamentos e em estágio inicial, validados por nossos públicos consumidores, doadores e contribuidores externos, são incorporados pela Fundação no plano anual.
- Este trabalho é sobre criar experimentos e processos de experimentação para adoção em toda a nossa organização.
- A Fundação fortalece uma cultura de experimentação interdepartamentos por meio da incorporação de dois experimentos validados e em estágio inicial em seu planejamento anual. Esta iniciativa promove a colaboração além das equipes principais do departamento de Produto e Tecnologia, encorajando mais inovação com outros departamentos na organização (como Comunicações e Desenvolvimento). Ao semear ideias novas e não testadas e otimizar processos para experimentação, equipes aprimoram a produtividade e aumentam a escala de impacto. O sucesso é medido completando dois experimentos interdepartamentais por ano, integrando-os ao trabalho futuro de OKR, e aumentando a adoção de práticas de experimentação. Exemplos de resultados são novos protótipos para aumentar o crescimento e a produtividade de novas pessoas editoras e funcionalidades experimentais que aprofundam a conexão da pessoa leitora e doadora com a Wikipédia. Uma oportunidade específica identificada é conectar pequenas explorações de funcionalidades para celebrar o 25º aniversário d a Wikipédia.
- Resultado-chave PES1.1: Ao final do segundo trimestre, definir SLOs para 6 serviços de produção com base em uma rubrica de priorização que busca maximizar nossa aprendizagem de como definir e usar SLOs para tomar decisões fundamentadas sobre priorização de trabalho relacionado a confiabilidade por equipes de partes interessadas.
- Contexto do objetivo: Este objetivo é sobre tornar as formas de trabalho da Fundação Wikimedia mais rápidas, inteligentes e melhores. Tem tudo a ver com como trabalhamos. Isto significa menos atrito e obstáculos (ineficiências e erros) em processos, e atingir impacto mais rapidamente. Este objetivo é também sobre aprender formas de trabalho que podem ser adotadas por todo o departamento e organização.
Hipóteses
1º tri
O primeiro trimestre (1º Tri) do pano anual da WMF cobre de julho a setembro.
| Hipóteses de Wiki Experiências (WE) | ||
|---|---|---|
| Nome curto da hipótese | Texto do 1º Tri | Detalhes & Discussão |
| WE1.1.1 | Se pedirmos a pessoas voluntárias (mais) novas colando texto de um site externo que conformem se elas escreveram o conteúdo que estão tentando adicionar, então nós veremos uma queda ≥10% na porcentagem de edições de novos conteúdos que pessoas voluntárias (mais) novas publicam que são revertidas com base em WP:VDA (e políticas relacionadas). | |
| WE1.1.2 | Se entregarmos uma versão beta inicial de da Edição Sugerida "Melhorar o Tom" então podemos aprender se este novo formato de Edições Sugeridas é um jeito carregado de significado para aumentar edições construtivas para pessoas contribuidoras novas sem aumentar o fardo de moderação para pessoas patrulhadoras/revisoras. | |
| WE1.1.3 | Se implementarmos um novo Modo de Sugestão voltado para Pessoas Contribuidoras Experientes no editor visual (móvel + desktop) como uma Funcionalidade Beta com ≥ 3 novas sugestões de edição dentro dela, descobriremos que ajustes – se houver algum – precisam ser feitos antes de avaliar a experiência com pessoas voluntárias (mais) novas por meio de um experimento controlado. | |
| WE1.1.4 | Se implementarmos o Reference Check na en.wiki por meio de um experimento controlado, veremos um aumento ≥10% nas edições construtivas que pessoas voluntárias (mais) novas publicam e aprenderemos se há apoio suficiente entre pessoas patrulhadoras e moderadoras para habilitar a funcionalidade mais amplamente. | |
| WE1.1.5 | Se testarmos um sistema de progressão por meio de protótipos de design com pessoas novas, então poderemos identificar que tipos de marcos, diretrizes e reconhecimentos são percebidos como mais motivadores, e usar essas percepções para finalizar um design para experimentação wiki piloto futura. | |
| WE1.1.6 | Se investigarmos as maiores barreiras técnicas, sociais e comportamentais e propiciadoras da edição web móvel por meio de pesquisa com pessoas usuárias e análise de dados, geraremos ao menos 3 percepções acionáveis que preenchem lacunas de conhecimento-chave e fortalecem nossa habilidade para priorizar confiantemente investimentos de produto para a segunda metade do ano fiscal 25/26 e além. | |
| WE1.2.1 | Se criarmos uma prova de conceito para exibir dados de contribuição colaborativa nas wikis, podemos reunir feedback de ao menos 30 pessoas contribuidoras com 70% de participantes compartilhando que a funcionalidade é útil e poderia ajudar a impulsionar crescimento colaborativo. | |
| WE1.3.1 | Se utilizarmos as necessidades identificadas de pesquisas e designs anteriores e compartilharmos simulações iniciais dos X módulos de moderação mais impactantes, podemos modificar a página inicial para ações de moderação com elas. | |
| WE1.3.2 | Se modificarmos a página inicial para pessoas novas para condicionalmente renderizar módulos de moderação, então podemos provar a viabilidade de usar a página inicial para pessoas moderadoras. | |
| WE1.4.1 | Se fizermos algumas melhorias sinalizadas em T396489, reduziremos as consultas lentas do recentchanges em X por cento em grandes wikis. Aí ferramentas de moderação poderão implementar módulos da página inicial nessas wikis sem uma preocupação especial de desempenho de banco de dados. | T400696 |
| WE2.1.1 | Se convidarmos pessoas falantes nativas de pequenas wikis por meio de um banner no CentralNotice em uma Wikipédia de alto tráfego em sua região para contribuir para o SuggestedEdits e outras funcionalidades de Crescimento, poderemos avaliar se esta abordagem atrai novas pessoas falantes nativas de e se elas usam essas ferramentas de edição para melhorar conteúdo vital. | |
| WE2.1.2 | Se desenvolvêssemos e lançássemos sugestões de tradução ajustadas para pessoas editoras novas, poderíamos então testar se essa abordagem produz resultados de tradução melhores se comparado a nossa abordagem atual.
Isto lida com os desafios conhecidos enfrentados por pessoas editoras novas, que têm uma probabilidade maior de eliminação de artigos. Ao indicá-las para a tradução de conteúdo mais gerenciável, a meta é prover uma introdução com menos sobrecarga e mais acessibilidade ao processo de tradução. Candidatos a artigos e seções boas poderiam parecer ter complexidade limitada em termos de formatação e tamanho geral. |
|
| WE2.1.3 | Se aprendermos sobre a experiência da pessoa editora ao criar novos artigos e seções (incluindo motivações, dores de cabeça e sua reação a novas ideias para melhor apoiá-las), então revelaremos necessidades e comportamentos de pessoas usuárias que fornecem percepções e estratégias acionáveis para fundamentar produto, design e engenharia e melhorar a experiência de criação de artigos. | |
| WE2.1.4 | Se explorarmos, por meio de oficinas participativas ou entrevistas, como três Wikipédias de médio porte lidam com lacunas de gênero e importância, revelaremos definições em funcionamento ou conceitos de enquadramento para "conhecimento vital" que são relevantes para cada comunidade. | |
| WE2.2.1 | Se seguirmos a implementação do Parsoid e integrarmos o Wikifunções na maioria dos Wikcionários e algumas Wikipédias de tráfego baixo, nós obteremos as testagens que precisamos para confiantemente implementar em wikis maiores. | |
| WE2.2.2 | Se habilitarmos Wikifunções para tabelas, estilização e ligações de saída de HTML, demonstraremos por meio de uma Função que exibe uma tabela de conjugação sua capacidade de gerar novo conhecimento líquido em Wikcionários além de simples conversões. | |
| WE2.2.3 | Se adicionarmos apoio para entidades do Wikidata em chamadas de funções embedadas, habilitaremos mais de 200 novas funções que podem gerar frases completas usando entidades Wikitada, tornando as funções mais facilmente usadas em projetos Wikimedia. | |
| WE2.2.4 | Se construirmos um plano de arquitetura para onde o Conteúdo Abstrato ficará e como ele vai interagir com a Wikipédia, teremos mais preparação para implementar a plataforma da Wikipédia Abstrata para aumentar o fornecimento de conteúdo enciclopédico de alta qualidade. | |
| WE2.2.5 | Se definirmos e socializarmos pelas equipes de Produto e Tecnologia sobre as necessidades de produto para citações que são necessárias para Conteúdo Abstrato, conseguiremos guiar trabalho pela Wikimedia para entregar informação de proveniência anexada a Conteúdo Abstrato, que é crucial para a adoção bem-sucedida pelas wikis. | |
| WE2.2.6 | Se tornarmos nosso formato de solicitações internas-backend mais expressivo e conciso, podemos aumentar a estabilidade do sistema, apoiando assim uma implementação mais ampla. | |
| WE2.2.7 | Se fornecermos protótipos de fragmentos usando chamadas de Wikidata e Wikifunções para gerar trechos de linguagem natural, mostraremos prontidão para o projeto, e estaremos prontas e prontos para ele ser usado para treinar IA de modo que humanos não tenham que pensar muito sobre funções. | |
| WE2.2.8 | Se forneceremos importações de afirmações do Wikidata com qualificadores, será possível gerar fatos multifacetados (fatos que requerem mais do que apenas sujeito/predicado/valor para serem expressos), o que inclui, conforme estimativas, 50% do conteúdo enciclopédico no Wikidata. | |
| WE2.2.9 | Se forneceremos caching de entidades recuperadas do Wikidata, reduziremos em ao menos 50% o tempo de rodagem de funções baseadas em conteúdo Wikidata, reduzindo erros do tipo timeout e frustração das pessoas usuárias. | |
| WE2.2.10 | Se fornecermos um componente de sentido de lexemas na interface de usuário do Wikifunções, então pessoas contribuidoras conseguirão identificar e selecionar lexemas sem deixar a plataforma/Wikifunções—reduzindo troca de conteúdo e permitindo a criação mais rápida e bem-sucedida de funções relacionadas a línguas. | |
| WE2.2.11 | Se lidarmos com descobertas de usabilidade da comunidade Dagbani na integração do Wikifunções na Wikipédia, observaremos que pessoas editoras encontram menos ou zero questões críticas de usabilidade ao inserir uma função em um artigo durante a testagem. | |
| WE3.1.1 | Se fizermos uma testagem A/B de uma versão melhorada da funcionalidade de navegação Tabbed, veremos um aumento de 5% em uso multidiário entre pessoas usuárias de Tabs. | |
| WE3.1.3 | Se forneceremos uma nova maneira para pessoas usuárias navegarem por conteúdo relevante de imagens e vídeos dentro de páginas de artigos, veremos ao menos uma taxa de cliques de 3% entre pessoas usuárias a quem esta funcionalidade é apresentada. | |
| WE3.1.4 | Se mostrarmos a pessoas leitoras vários conceitos para atravessar a rede de conhecimento nas wikis, sairemos com uma lista priorizada de conceitos para desenvolvimento adicional. | |
| WE3.1.5 | Se fornecermos a pessoas leitoras na web a opção de ver uma versão de conteúdo Wikipédia indisponível em sua língua traduzida automaticamente, aprenderemos se a atividade de leitura aumenta, medida como um aumento de 3% em interações de páginas, trazendo pessoas leitoras à língua wiki local com um aumento potencial em atividade local de edição. Isto será fornecido como uma configuração de testagem controlada A/B para não mais do que 6 meses, e em 13 Wikipédias com consentimento prévio, usando serviços abertos de tradução automática já disponíveis a pessoas editoras da Wikipédia. | |
| WE3.2.1 | Se colaborarmos com captação de recursos nós desenvolveremos slides de pessoas doadoras mais engajantes, integrados e personalizados na Retrospectiva do iOS. Isto será sucedido por uma hipótese no segundo trimestre para avaliar se a Retrospectiva melhorada viu 5% a mais de doações do que a Retrospectiva de 2024. | |
| WE3.2.2 | Se convidarmos pessoas leitoras do app Android em mercados fora da campanha a configurar lembretes opcionais e customizáveis (quantidade e frequência) para doações com base em seu uso da Wikipédia, veremos um aumento de 5% em doações do menu do app nesses mercados. | |
| WE3.2.3 | Se rodarmos um experimento-teste A/B em pessoas usuárias deslogadas para exibir variantes sutis do ponto de entrada de doações tanto para dispositivos móveis quanto para desktop, observaremos um número 2% maior de doações por meio dos caminhos de tratamento, comparado ao controle | |
| WE3.3.1 | Se adicionarmos elementos personalizados de baixo a médio esforço solicitados por pessoas usuárias de iOS em 2024 à Retrospectiva de 2025, veremos um aumento de 3% em níveis de satisfação comparado ao ano passado, conforme medido por meio de testagem de usabilidade ou testagem beta. | |
| WE3.3.2 | Se expandirmos a aba de Edição existente no Android em um hub de atividade personalizado que inclui percepções sobre leitura e participação além das edições, veremos um aumento de 5% em engajamento pluridiário com a aba comparado à versão original. | |
| WE3.3.3 | Se introduzirmos ao menos um avatar desbloqueável no app Android para pessoas com contas—conquistados por meio de ações significativas de leitura como salvar um certo número de artigos — aumentaremos o engajamento repetido com ação associada por pessoas usuárias logadas em 10% ao longo de vários dias. | |
| WE3.3.4 | Se dermos a pessoas leitoras a capacidade de salvar artigos a uma lista de leitura privada, esperamos que o engajamento no site aumente, conforme medido por um aumento de 5% em tráfego interno de referência para pessoas leitoras que usam a funcionalidade, e um aumento estatisticamente significativo para todas as pessoas usuárias. | |
| WE3.3.5 | Se conduzirmos um estudo de pessoas usuárias que permita a pessoas leitoras coletar/fazer curadoria de conteúdo da Wikipédia, então ao menos 10% de participantes salvarão dois ou mais tipos distintos de conteúdo (ex: artigos, excertos, mídia) a uma coleção. | |
| WE3.4.1 | Se trabalharmos para uma implementação híbrida PoP/CDN, isso nos permitirá trazer tanto PoPs completos quanto mini PoPs (físicos e na nuvem) conforme necessário, plantando as sementes para a implementação de protótipos de mini PoP no futuro. | |
| WE3.6.1 | Se realizarmos um teste A/A na taxa de retenção para pessoas usuárias deslogadas, estabeleceremos uma base para a taxa de retenção que podemos usar para trimestres futuros. | |
| WE3.6.2 | Se criarmos e publicarmos uma definição de pessoa leitora logada, poderemos usar esta definição em todas as equipes e hipóteses relacionadas ao resultado-chave da WikiExperiência 3.3. | |
| WE3.6.3 | Se engajarmos comunidades em conversas sobre as necessidades em evolução de pessoas leitoras, e sobre a natureza mutante do conhecimento na internet, podemos construir um foco compartilhado em como servir pessoas leitoras e trabalhar conjuntamente em se e como testar nossas várias ideias (incluindo as sobre multimídia, busca e descoberta e aprendizado de máquina). | |
| WE3.6.4 | Se pesquisarmos as motivações distintas, comportamentos e necessidades por trás de quando, por que e como pessoas leitoras usam a Wikipédia e outras plataformas de conhecimento, nós teremos descobertas que podemos usar para fundamentar e evoluir nossa estratégia de consumo. | |
| WE4.1.1 | Se fizermos um protótipo de um fluxo que não seja de emergência e minimamente viável, e mantivermos aberto um loop de feedback iterativo conforme o desenvolvemos com pessoas usuárias com direitos estendidos, então esses grupos apoiarão a implementação expandida deste fluxo. | Project page |
| WE4.2.1 | Se revelarmos o nível de risco hCaptcha associado à criação de contas a pessoas contribuidoras confiáveis, diminuiremos o tempo necessário para identificar maus agentes, e aumentaremos o número de detecções de contas de maus agentes criadas na plataforma. Podemos medir o sucesso da hispótese olhando para a taxa de bloqueios aplicados a contas, o alinhamento de níveis de risco hCaptcha e bloqueios de contas em geral, e feedback qualitativo de pessoas contribuidoras. | |
| WE4.2.2 | Se gerarmos investigações sugeridas para pessoas verificadoras acompanharem, veremos uma diminuição do tempo necessário para identificar contas de maus agentes e um aumento no número de contas de maus agentes identificadas. Saberemos que tivemos sucesso quando virmos usos regulares da funcionalidade "Investigações sugeridas", um aumento de mitigações aplicadas a contas identificadas por meio das investigações sugeridas e por meio de feedbacks de pesquisa qualitativa. | |
| WE4.2.3 | Se analisarmos dados do experimento de criação de conta hCaptcha, entenderemos o funil de criação de contas, a efetividade dos enigmas e pontuações do hCaptcha, e teremos os dados necessários para fundamentar mais implementações do hCaptcha em criações de contas. | |
| WE4.2.4 | Se implementarmos o UserInfoCard em todas as wikis, empoderaremos pessoas colaboradoras e moderadoras para mais eficientemente identificar e mitigar contas de maus agentes. | Project page |
| WE4.2.5 | Se conduzirmos pesquisas, consultarmos as comunidades e investigarmos soluções técnicas, poderemos definir um conjunto de motivos estruturados de bloqueio que podem ser usados em todas as wikis da WMF. | |
| WE4.2.6 | Se desenvolvermos a capacidade de implementar clusters baseados em OpenSearch na Plataforma de Dados, então as equipes de engenharia de funcionalidades de produtos serão empoderadas para desenvolver sistemas que integram esta capacidade, com uma grande dose de autonomia, resiliência e isolamento de outros sistemas baseados em buscas. O primeiro e principal locatário para esse sistema será o serviço IPoid. | |
| WE4.2.7 | Se implementarmos integração do hCaptcha Enterprise em várias Wikipédias de produção como um teste piloto, conseguiremos coletar dados sobre a eficácia e valor do hCaptcha Enterprise em antiabuso, detecção de robôs, usabilidade e acessibilidade. | |
| WE4.3.1 | Se integrarmos apoio para o novo cookie Edge Uniques no requestctl, nosso mecanismo de regras edge para SREs combatendo abusos serão mais capazes de se defender de DDoS e reutilização de conteúdo. | |
| WE4.4.1 | Se fizermos melhorias baseadas em feedbacks de pilotos e implementarmos Contas Temporárias a todos os projetos, conseguiremos proteger a exposição de informações pessoalmente identificáveis (endereços de IP) de pessoas usuárias não registradas em todos os nossos projetos a ficarem disponíveis a menos de 0.1% de todas as pessoas usuárias (registradas). | Project page |
| WE4.4.2 | Se comunicarmos com as partes interessadas relevantes do movimento (incluindo wiki comunidades e pessoas colaboradoras globais) claramente e a tempo, conseguiremos implementar em todas as wikis restantes, reduzir carga de trabalho descoberta no último minuto e evitar reverter a implementação. | |
| WE4.4.3 | Se facilitarmos que pessoas patrulhadoras filtrem ações de e vejam a atividade de contas temporárias, com base em seus endereços IP, então habilitaremos contas temporárias para serem implementadas com sucesso em todas as wikis. | |
| WE4.4.4 | Se permitirmos que o acesso à revelação de IPs de contas temporárias seja revogado, em linha com a política de acesso à revelação de IP, e mostrarmos a funcionalidade em mais lugares, então habilitaremos contas temporárias para serem implementadas com sucesso em todas as wikis. | |
| WE4.5.1 | Se realizarmos pesquisas qualitativas para identificar exemplos de abuso de maus agentes, com ajuda de IA generativa (como spam, assédio, abusadores de longa data, edições pagas não informadas ou campanhas de desinformação), conseguiremos avaliar o risco aos nossos modelos de comunidade e gerar ideias para mitigar diferentes tipos de abuso assistido por IA generativa. | |
| WE4.6.1 | Se automatizarmos o processo de sincronização de contas no Zendesk para resets de senhas, isto aliviará o fardo da equipe de Confiança e Segurança e permitirá que ela lide com mais pedidos de resets de autenticação em dois fatores. | |
| WE4.6.2 | Se apoiarmos e encorajarmos que pessoas usuárias registrem múltiplos fatores de autenticação, pessoas usuárias com autenticação em dois fatores habilitada terão menos chance de perderem acesso a suas contas. | |
| WE4.6.3 | Se permitirmos que todas as pessoas usuárias com email confirmado possam habilitar autenticação em dois fatores para suas contas, mas não divulgarmos proativamente esta mudança para pessoas usuárias, a carga da nossa equipe de apoio a recuperação permanecerá num nível sustentável. | |
| WE5.1.1 | Se usarmos diferente backends de armazenamento para sessões autenticadas e anônimas, conseguiremos proteger Sessionstore de ataques DDoS e raspadores de alto volume não sobrecarregando-o com as sessões anônimas que são criadas para fornecer prevenção CSRF em páginas de autenticação. | T398814 |
| WE5.1.2 | Se mudarmos os cookies de dessão do MediaWiki para um formato estruturado com uma assinatura criptográfica, conseguiremos usar a presença de uma sessão como um fator na proteção contra raspadores habilitando verificação confiável de sessões em edge de uma maneira performante e altamente escalável. | T398815 |
| WE5.1.3 | Se criarmos uma taxa limitando soluções para o gateway API usando um ambiente de desenvolvimento local baseado em Kubernetes, conseguiremos determinar a melhor opção para testar com tráfego de produção, comparando o desempenho e funcionalidade de ao menos três diferentes serviços limitadores de taxas. | T398913 |
| WE5.2.1 | Se redesenharmos a interface de usuário da página de testes REST API para atender melhor às necessidades informacionais das pessoas desenvolvedoras, melhoraremos a clareza de documentação, conforme validado por meio de testagem de usabilidade. | |
| WE5.2.2 | Se rotearmos todas as APIs sob rest.php por meio de um gateway central, desbloquearemos os meios para uma gestão centralizada de APIs e poderemos começar a medir consistentemente o tráfego e os padrões de uso de APIs REST para obter percepções que fundamentarão futuras decisões e ações. | |
| WE5.2.3 | Se implementarmos dashboards de monitoramento e alarmes para a REST API do MediaWiki, então possivelmente demonstraremos um meio sustentável, útil e replicável de melhorar a visibilidade no comportamento de nossos sistemas e revelaremos problemas mais cedo, especialmente durante modificações críticas. | |
| WE5.3.1 | Se expandirmos e otimizarmos diretrizes de atribuição de experiência do usuário enquanto atualizamos qualquer diretriz atual, estabeleceremos um conjunto central de diretrizes melhoradas prontas para serem testadas internamente e iterativamente refinadas para serem preparadas para uso público mais amplo. | |
| WE5.3.2 | Se criarmos um pitch que demonstre os benefícios de atribuir a Wikipédia a terceiros reutilizadores de conteúdo e suas pessoas usuárias finais, poderemos apoiar a WME4.1 e WME4.2 propiciando que ao menos um parceiro de reutilização adicional concorde em aparecer em um estudo de caso de atribuição ou demonstração ao final do primeiro trimestre. | |
| WE5.4.1 | Se garantirmos que uma maioria de requisições web consigam cookies edge únicos, ficará mais fácil identificar robôs e requisições forjadas. | |
| WE5.4.2 | Se construirmos um jeito escalável para identificar clientes conhecidos, podemos permitir exceções aos limites de taxas gerais para robôs de origem verificada e nos dirigirmos para a aplicação sistemática de nossas regras. | |
| WE5.4.3 | Se reorganizarmos a filtragem de requisições de texto no CDN sobre uma abordagem de lista de permissões/negações, podemos aplicar uma limitação de taxas mais rígida para robôs e otimizar a filtragem de tráfego. | |
| WE5.4.4 | Se desenvolvermos uma estratégia de medida unificada, propiciaremos a avaliação da estratégia plurianual de 'uso responsável de infraestrutura' e definiremos um mapa para guiar desenvolvimento métrico e capacidades de emissão de relatórios. | |
| WE6.1.1 | Se realojarmos builds de imagens diários ao servidor de desenvolvimento e adicionarmos atualizações de imagens acionadas por ações de implementação select, revelaremos limitações e estabeleceremos uma base para o tempo necessário para desempenhar implementações mais contínuas. | |
| WE6.1.3 | Se adicionarmos wikifazendas a um ambiente de testagem pré-fusão, isto permitirá a equipes de desenvolvimento construindo ante a produção que requerem múltiplas wikis para testar seus patches em isolamento dando a elas mais confiança pré-produção e resultados em menos fugas de defeitos. | |
| WE6.2.1 | Se revisarmos e publicarmos nosso Checklist de Prontidão de Produção que claramente defina os pré-requisitos para que um serviço seja considerado pronto para produção, junto com tarefas autoutilizáveis, alinharemos expectativas entre SREs e equipes de desenvolvimento, melhorando nossa eficiência e escalabilidade operacionais em geral. | |
| WE6.2.2 | Se anunciarmos a criação de uma biblioteca de Golang e nodejs abstraindo várias tarefas trabalhosas para pessoas desenvolvedoras, elas responderão oferecendo feedback e interesse. | |
| WE6.2.3 | Se criarmos um checklist/planilha, pessoas desenvolvedoras poderão se preparar totalmente com antecedência para a revisão do design de Persistência de Dados. | |
| WE6.3.1 | Se implementarmos ao menos 70 Wikipédias de tráfego baixo no primeiro trimestre, excluindo wikis com suporte de variante linguística, aumentaremos nossa confiança para a implementação eventual nas 10 maiores wikis, o que terá um impacto maior em visualizações de páginas servidas pelo Parsoid. | |
| WE6.4.1 | Se implementarmos uma tabela de ligações de divisão do Commons em seu próprio cluster, aumentaremos as chances de crescimento de banco de dados para o Commons seguir sustentável. | T398709 |
| WE6.4.2 | Se nós (SRE) fornecermos ajuda às equipes de engenharia do MediaWiki - criando documentação preparando a infraestrutura necessária (ex: pacotes PHP, imagens contêineres) e oferecendo orientação e revisão - elas conseguirão confiantemente iniciar a atualização PHP 8.3 de produção no início do segundo trimestre. | T360995 |
| WE6.4.3 | Se exigirmos um segundo fatos físico (chave de segurança de hardware) para logins SSH por pessoas usuárias com privilégios de sistema elevados, reduziremos o risco de um laptop comprometido causar uma falha grava de segurança. | |
| WE6.4.4 | Se unificarmos nossos domínios servindo todas as visualizações de páginas em sites MediaWiki por meio de um domínio canônico, então reduziremos a complexidade da plataforma e riscos de Otimização de Mecanismos de Busca (SEO, na sigla em inglês) eliminando o redirecionamento móvel-de subdomínio. A completude é medida aumentando visualizações de páginas móveis em domínios canônicos de 0% para 100%. | T214998 |
| WE6.4.5 | If the MediaWiki Engineering Team actively monitor and fix issues in MediaWiki related to the PHP 8.3 upgrade, the SRE team will be unblocked to proceed with the PHP 8.3 upgrade by the start of Q2. | T360995 |
| Hipóteses de Sinais e Serviços de Dados (SDS) | ||
|---|---|---|
| Nome curto da hipótese | Texto do 1º Tri | Detalhes & Discussão |
| SDS1.1.1 | Se analisarmos a eficácia das heurísticas de detecção de tráfego automatizada em nossos conjuntos de dados de visualizações de páginas, conseguiremos desenvolver métricas de qualidade de dados para descrever sua performance e determinar a necessidade de mais investimentos nessas heurísticas. | |
| SDS1.2.2 | Se migramos o processo de Dumps XML da infraestrutura atual 'Dump 1' para um pipeline de dados que tire proveito dos Pipelines de Conteúdo MediaWiki, nós conseguiremos garantir SLOs e desligar a exportação de XML baseada em 'Dumps 1'. | |
| SDS1.2.3 | Se fizemos um guia e revisarmos os SLOs para o Histórico de Conteúdo de MediaWiki e Plataforma de Eventos / Portão de Eventos, poderemos validar clientes, métricas e partes interessadas dependentes e identificar melhorias que possam ser necessárias para os SLOs, o que nos ajudará a esclarecer qualquer lacunas em nossas garantias de entrega semanal. | |
| SDS2.1.1 | Se nos aproximarmos de equipes realizando experimentos, aprenderemos como tornar o sistema mais self-service no futuro e que desafios conceituais ou técnicos elas podem encontrar. | |
| SDS2.1.2 | Se pudermos implementar debugging melhor para eventlogging, então equipes de produto saberão que seu experimento está coletando dados de eventos conforme esperado, aumentando a confiança das pessoas donas do experimento. | |
| SDS2.1.3 | Se melhorarmos o logging e observabilidade do componente do sistema de testagem A/B (xLAb) da plataforma de experimentação, e para suas partes MediaWiki relacionadas, conseguiremos estabelecer bases para a performance do sistema e responder a falhas relacionadas a experimentos. | |
| SDS2.1.4 | Se compartilharmos histórias e resultados de experimentos por toda a organização uma vez por mês (por meio de reuniões de operações de Produto, reuniões da equipe de Design e apresentações entre equipes), então criaremos a adoção orgânica da plataforma de experimentação. | |
| SDS2.1.5 | Se dissermos a pessoas usuárias que seu instrumento, caso criado no xLab, contém um conjunto de atributos que muda a categoria de risco, impediremos que pessoas usuárias de instrumentação coletem dados em excesso e aumentaremos a clareza sobre que combinações de atributos exigem revisão de privacidade. | |
| Hipóteses do Público Futuro (FA) | ||
|---|---|---|
| Nome curto da hipótese | Texto do 1º Tri | Detalhes & Discussão |
| FA1.1.1 | Se 1) oferecermos meios para coletores de mídia em outras plataformas (como such Letterboxd, Goodreads e RateMyMusic) aprimorarem suas coletas com conhecimento exclusivo da Wikipédia ou 2) oferecermos a esses coletores de mídia materiais interessantes compartilháveis nas redes sociais, então conseguiremos aumentar o alcance da Wikipédia fora da plataforma. | |
| FA2.1.1 | Se aumentarmos nossa capacidade interna de criar conteúdos curtos em vídeo (aumentando o tamanho da nossa equipe e auditando e identificando oportunidades para aumentar a eficiência em nosso processo de produção atual) no primeiro trimestre, conseguiremos agir em aprendizados de conteúdo criado no Ano Fiscal 2024-5 e atingiremos um alcance maior ano a ano de conteúdo produzido no segundo trimestre do Ano Fiscal 2025-6. | |
| Hipóteses de Suporte de Produto e Engenharia (PES) | ||
|---|---|---|
| Nome curto da hipótese | Texto do 1º Tri | Detalhes & Discussão |
| PES1.1.1 | Se apoiarmos o xLab, Charts e ToneCheck na definição de métricas para SLIs (sigla em inglês para Indicadores de Nível de Serviço) no Prometheus e integrarmos aqueles Objetivos de Nível de Serviço (SLOs, na sigla em inglês) no Pyrra, aprenderemos os limites e casos extremos de nossa ferramentaria em vários cenários complexos, bem como esclarecer que iterações são necessárias para a predefinição de SLO, o que nos ajudará a apoiar melhor os 6 SLOs planejados para o KR. | |
| PES1.1.2 | Se pilotarmos dois conjuntos de de dashboards de alerta de SLO, aprenderemos o quão difícil seria implementar ferramentaria adequada de modo que pessoas proprietárias de serviços claramente entendam seus compromissos e também se precisamos migrar para uma ferramenta diferente que oferece apenas uma visão simples de um SLO específico. Um dashboard será para relatórios trimestrais (em que um Acordo de Nível de Serviço para o orçamento de erro é definido) e um dinâmico menor (chamado "rolando") será para operações e alertas do dia-a-dia. | |
| PES1.1.3 | Se continuarmos a apoiar o grupo da Wikipédia Abstrata na redação de um SLO (Objetivos de Nível de Serviço) para o projeto de Wikifunções, aprenderemos como definir uma lista de metas de SLO (juntamente às suas métricas de Indicador de Nível de Serviço) para uma funcionalidade complexa atualmente sendo adicionada a um fluxo de trabalho essencial de pessoa usuária: renderizar Wiki-artigos. Aprenderemos também como visualizar apropriadamente os orçamentos de erro e alerta relacionados neles usando dashboards e monitores fornecidos por SRE. | |
| PES1.1.4 | Se apoiarmos o grupo de Plataforma de Dados com revisão e interação dos Objetivos de Nível de Serviço (SLO) para o projeto de Histórico de Conteúdo MediaWiki, aprenderemos como tirar proveito de SLOs para apoiar posse de serviços quando uma combinação de serviços de processamento em batch e stream são orquestrados juntos para atualizar o conjunto de dados, mantendo-o consistente e disponível para pessoas usuárias mais à frente no processo. | |
| PES1.2.1 | Se criarmos 3 melhorias direcionadas à Lista de desejos, então encorajaremos 30% mais pessoas participantes únicos na Lista de desejos | |
| PES1.2.2 | Se fizermos triagem de desejos que estão chegando e designarmos uma Pessoa Mantenedora (ex: Gerentes de Produto) dentro de 72 horas (incluindo negar, esclarecer, marcar serviços sem manutenção, etc.), inter-referenciando novos desejos ante a tabela da Pessoa Mantenedora e designando uma "categoria de Pessoa Mantenedora" pra equipe ou indivíduo de produto mais relevante, Pessoas Mantenedoras (ex: Gerentes de Produto) conseguirão acessar e responder a desejos em 10 dias ou menos. | |
| PES1.2.3 | Se pilotarmos trabalho para identificar sinais de comunidade em ampla escala, incorporaremos mais vozes de pessoas voluntárias em nossos esforços de priorização fundamentados pela comunidade. | |
| PES1.2.4 | Se pilotarmos um processo trimestral de revisão de sinal de desejo e comunidade com 3 equipes no primeiro trimestre, engajaremos Gerentes de Produto para integrar sinais da comunidade em seus processos de planejamento trimestrais e anuais. | |
| PES1.3.1 | Se, ao final do primeiro trimestre, coordenarmos 3 sessões de planejamento funcionais com o departamento de Comunicações e equipes de produtos para alinhar envio de mensagens, necessidades criativas e linhas do tempo de campanha para iniciativas WP25, então finalizaremos briefs criativos para todos os 3 experimentos de campanha (Retrospectiva 25, Easter Eggs, WikiRun). | |
| PES1.3.2 | Se estabelecermos um comitê diretor com representantes das equipes de Design e de engenharia de funcionalidades, poderemos definir métricas-base sobre contribuições ao Codex: conscientização, uso, qualidade das contribuições e quantidade. as percepções obtidas a partir da avaliação ante essas métricas-base nos ajudarão a determinar um mapa para federalizar o crescimento e a diversificação da base de pessoas contribuidoras do Codex. | |
Q2
The second quarter (Q2) of the WMF annual plan covers October-December.
| Wiki Experiences (WE) Hypotheses
[ WE Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| WE1.1.1 | If we analyze a pre-predetermined set of leading indicators ≥2 weeks after the start of the Paste Check A/B test, we will be able to identify what – if any – facets of the end-to-end experience need to be adjusted or investigated before we can be confident evaluating the impact of the feature. | |
| WE1.1.4 | If we deploy Reference Check at en.wiki through a controlled experiment, we will see a ≥4% increase in the constructive edits new(er) volunteers publish and learn whether there is sufficient support among patrollers and moderators to enable the feature more widely. | |
| WE1.1.7 | If we analyze a pre-predetermined set of leading indicators ≥2 weeks after the start of the Tone Check A/B test, we will be able to identify what – if any – facets of the end-to-end experience need to be adjusted or investigated before we can be confident evaluating the impact of the feature. | |
| WE1.1.8 | If we apply the Tone Check model to published articles, we will learn whether we can identify the ≥10,000 tone issues (each with a probability score of 0.8 or higher) that are needed to build a high-quality (accuracy ≥ 70%) pool of suggestions to help guide editors in improving article tone. | |
| WE1.1.10 | If we interview ~10 experienced volunteers at en.wiki and fr.wiki who write AbuseFilters (and other gadgets/scripts/templates/edit notices) to automate patrolling/moderation workflows, we will identify ≥3 patterns/needs that will help shape the value proposition of community-authored Edit Checks. | |
| WE1.1.11 | If we distribute a survey to ≥500 successful newcomers[i] and obtain high quality data that is representative of the broader successful newcomer population, we will be able to identify ≥4 actionable insights we can use to prioritize what aspects of the onboarding experience to improve. | |
| WE1.1.12 | If we enable ≥3 volunteers to evaluate ≥30 sample edits each, for each of the 10 new languages we are seeking to scale Tone Check to, we will learn how often volunteers agree with model predictions and be able to decide which new wikis to approach about deploying Tone Check to. | |
| WE1.1.13 | Given we scaled “Add a Link” to 100% of newer volunteers at English Wikipedia, then newcomer constructive activation and retention will improve, which will increase constructive edits made by newer volunteers by ≥4%. | |
| WE1.2.3 | If we remove the requirement that someone needs the Event Organizer right to use Event Registration on small and medium-sized wikis, then we will see at least X more events* created on small and medium-sized wikis by the end of the fiscal year.
|
|
| WE1.2.4 | If we iterate on the Collaborative Contributions MVP with at least 2 improvements, then more collaborations will be created via Event Registration. | |
| WE1.2.5 | If we set one adoption strategy for Event Registration on Wikimedia Commons in early Q2, we will be able to test it with organizers of at least 1 large campaign and enable 5 local organizers to use the feature. | |
| WE1.3.3 | If we launch an experiment to surface a moderator dashboard to newer editors, 10% of contributors who visit it do so two weeks in a row. | |
| WE1.4.1 | If we make improvements defined in T396489, we will reduce the slow recentchanges queries by at least 30% on large wikis, which will enable Community Tech to deploy Watchlist Labels without overloading the recentchanges database. | |
| WE1.4.3 | If we instrument recent changes and watchlist, then we can define a baseline for how often people click to pages. | |
| WE1.5.1 | If we implement a dashboard to explore 7 contributor metrics and standardize the calculation of at least one metric using dbt then we can enable contributor product teams to self-serve metric insights and develop a standard for storing metric calculation logic. | |
| WE1.5.2 | If we determine in Q2 which moderation actions to include in the definition of who is a Moderator, then the Movement Insights team can build out the metric of Monthly Active Moderators in Q3/Q4. | |
| WE2.1.3 | If we learn about the editor experience when creating new articles and sections (including motivations, pain-points and their reaction to new ideas on how to better support them),then we will uncover user needs and behaviors that provide actionable insights and strategies to inform product, design, and engineering on improving the article creation experience. | |
| WE2.2.12 | If we roll Wikifunctions out to wikis that have Parsoid enabled, we will be able to continue testing whether the system remains performant and usable in increasingly broad rollouts. | |
| WE2.2.13 | If we socialize the availability of the conjugation table function with the Wiktionary community, we will gain valuable feedback about function usage and insights into our user personas that we can apply to future rollouts. | |
| WE2.2.14 | If we look into the community’s Databox work on using Wikidata for infoboxes and investigate whether Wikifunctions might help, we will be able to identify a first experiment for Wikifunctions in infoboxes. | |
| WE2.2.15 | If we create community awareness about the ability to create and translate error messages on Wikifunctions, we will see an increase in the number of helpful error messages. | |
| WE2.2.16 | If we demo available semantic functions to the community, we will see an increase in grammatical functions by 50%. | |
| WE2.2.17 | If we provide a custom component for viewing Wikidata statements on Wikifunctions, users will be more able to understand data fetched from Wikidata and feel less overwhelmed. | |
| WE2.2.18 | If we can prevent 10x memory consumption spikes, the orchestrator will be better able to handle Wikidata objects, supporting the utility of Wikifunctions as a platform for Abstract Wikipedia. | |
| WE2.2.19 | If we enable users to share direct links to specific function calls — including their inputs — contributors will be able to reproduce, verify, and discuss function behavior more easily, which will in turn speed up debugging, improve testing workflows, and support collaborative problem-solving across the Wikifunctions community. | |
| WE2.3.1 | If we finalize the decision for creating a new wiki and decide on a name with the community, we will be able to more broadly socialize the creation of this new wiki with our stakeholders and prepare for the logistics of a potential product name change. | |
| WE2.3.2 | If we define an MVP for an Abstract wiki prototype that includes the barest possible experience for testing our back-end and NLG capabilities, and allows us design iteratively, we will be able to plan and launch a live prototype in Q3. | |
| WE2.3.3 | If we start talking to the community and exploring potential designs for the user experience of an Abstract wiki, we will be able to keep work moving forward in Q3. | |
| WE2.4.1 | If we collect Wikidata and WDQS use cases from WMDE and WMF teams, we will be able to define product requirements for infrastructure improvements. | |
| WE2.4.2 | If we produce an aggregated reporting view of key performance indicators (KPIs) with existing service level objectives (SLOs) for Wikidata and WDQS, we will be able to articulate and track success criteria for improvements to the technical infrastructure supporting the critical Wikidata use case. | |
| WE2.4.3 | If we can evaluate and benchmark alternative stores to Blazegraph using production-realistic criteria within the quarter, we will be able to make a data-driven migration decision and articulate a concrete roadmap with timeline and resource requirements. | |
| WE3.1.1 | If we A/B test an improved version of the Tabbed browsing feature, we’ll see a 5% increase in multi-day usage among Tabs users. | |
| WE3.1.3 | If we provide a new way for users to browse through relevant image content within article pages, and test it with a subset of logged-out readers via an A/B test across a set of wikis, we will see at least an 3% click-through rate among users who are presented with this feature. | |
| WE3.1.4 | If we show readers several concepts for traversing the knowledge network on the wikis, we will come away with a prioritized list of concepts for further development. | |
| WE3.1.5 | If we provide web readers the option to view a machine translated version of Wikipedia content unavailable in their language, we'll learn if reading activity is increased, measured as a 3% increase in page interactions, drawing readers to the local language wiki with a potential increase in local editing activity. This will be provided as a controlled A/B testing setting for no longer than 6 months, and in 13 Wikipedias with prior consent, using open machine translation services already available to Wikipedia editors. | |
| WE3.1.6 | If we produce a prototype for semantic search and in-article Q&A, delivered as a demo interface that contrasts the current approach with new exploratory approaches, then the Reader teams will be able to qualitatively evaluate how each approach performs across different user journeys and surface gaps or opportunities for further iteration. | |
| WE3.1.7 | If we review existing research on how readers interact with search and navigation tools on Wikipedia, and how they use external search to find knowledge on Wikipedia, we will be able to provide the Reader teams with ≥3 actionable recommendations and findings that help them scope a search and discovery MVP to address gaps in reader expectations and needs. | |
| WE3.1.8 | If we evaluate 2 semantic search prototypes (natural language search, Q&A) with external participants, we can learn whether users see value in improved search tools, and provide the Readers teams with a recommendation on how to move forward with a search and discovery MVP. | |
| WE3.1.9 | If we show high-fidelity design concepts for content discovery through semantic search to 10-20 casual Wikipedia readers in a qualitative study, we will see positive sentiment for the feature and gain the confidence needed to proceed with a search and discovery MVP that relies on short-form human-written excerpts to search queries. | |
| WE3.1.10 | If we show 10 casual readers a live prototype of the new image browsing experience in an unmoderated user study, we will uncover at least one UX improvement for future iterations of the feature. | |
| WE3.1.11 | If we relax the matching of keywords in Search, then we better support natural language queries, and enable Product to evaluate this capability, include it in how they design, prioritize and deliver work in the Semantic Search space. | |
| WE3.2.5 | If we introduce a Year in Review feature on Android that highlights user impact and includes integrated donor messaging, we’ll drive new donation behavior—and we’ll see a 5% increase in app menu compared to 2024. | |
| WE3.2.6 | If we make the donor slides in the iOS Year in Review, more integrated, and personalized, we’ll see a 5% increase in donations compared to 2024. | |
| WE3.3.3 | If we introduce at least one unlockable avatar in the Android app for account holders—earned through meaningful reader actions like saving a certain number of articles — we’ll increase repeated engagement with associated action by logged-in users by 10% over multiple days. | |
| WE3.3.4 | If we give logged-in readers the ability to save articles to a private reading list, we expect engagement on the site to increase, as measured by a 5% increase in internal referral traffic for readers who use the feature, and a statistically significant increase for all users. | |
| WE3.3.6 | If we make article topic inference data available via a service that meets agreed-upon scalability and availability requirements, plus any necessary data backfills, then we will have established the technical foundation necessary to support upcoming personalized reader experiences that depend on this data. | |
| WE3.3.7 | If we leverage the data platform’s processing capabilities to aggregate tailored editor metrics and impact data and serve the aggregated data through suitable services with defined SLOs, we can enhance future iterations of Year in Review WE3.3.1 and Activity Tab WE3.3.2. | |
| WE3.3.9 | If we release Year in Review on Android and A/B test offering engaged users a reward to save a custom reading list, we will see a 1% increase in overall app retention rate amongst readers offered the reward compared to those who were not. | |
| WE3.3.10 | If we A/B test requiring an account to view the personalized reading insights of Year in Review, we’ll see a 1% increase in overall retention rate for users that were required to have an account, compared to those that were not. | |
| WE3.3.11 | If we A/B test an improved version of the “Activity” tab on iOS that highlights reading, editing and other participation behaviors, we will see a 5% increase in multi-day visits by logged-in readers to the tab compared to the prototype version. | |
| WE3.4.1 | If we work towards a hybrid point of presence (PoP/CDN) deployment, it will allow us to bring up both full PoPs and mini PoPs (physical and cloud) as required, laying the foundation for a prototype mini PoP deployment in the future. | |
| WE3.5.1 | If Product & Technology and Fundraising collaboratively evaluate and document technical approaches for identifying donors within our platforms, we will be able to recommend a short- and long-term solution that balances privacy, feasibility, and impact. This shared understanding will help align decision-making, enable persistent donor recognition across platforms, as well as more targeted experimentation in future fundraising related features. | |
| WE3.6.3 | If we engage communities in conversations about the evolving needs of readers, and about the changing nature of knowledge on the internet, we can build a shared focus on how to serve readers and work together on whether and how to test our various ideas (including those around multimedia, search and discovery, and machine learning). | |
| WE3.6.4 | If we research the distinct motivations, behaviours, and needs behind when, why and how readers use Wikipedia and other knowledge platforms, we will be able to propose priority areas and specific initiatives for the consumer strategy. | |
| WE3.6.5 | If Product & Technology and Fundraising collaborate on a shared strategy to diversify on-platform donation opportunities and steward and recognize readers who donate, we will set clear, aligned goals and metrics tied to our consumer and fundraising strategies. | |
| WE3.6.6 | If we develop a unified measurement strategy, we will enable evaluation of the consumers’ multi-year strategy and define a roadmap to guide metric development and reporting capabilities. | |
| WE4.1.1 | If we prototype a minimally viable non-emergency flow, and keep open an iterative feedback loop as we develop it with users with extended rights, then these groups will support expanded deployment of this flow. | |
| WE4.1.3 | If we update 7 Wikipedias (French, German, Spanish, Hungarian, Italian, Polish, Portuguese) by the end of October, we will complete phase 1 of the new Legal Footer roll-out in response to DSA requirements. | |
| WE4.1.4 | If we deploy the Incident Reporting System MVP to at least 15 wikis, with a focus on larger complex communities, we will observe it being used as intended by the community, and will have demonstrated a working model for non-emergency incident reporting. | |
| WE4.1.5 | If we design a flow diagram for reporting incidents of abuse to wikis without established abuse-handling processes, this will encourage adoption of the Incident Reporting System on such wikis and enable users on those wikis to have a clear and viable support pathway. | |
| WE4.2.3 | If we analyze data from the hCaptcha account creation trial, we will understand the account creation funnel, the effectiveness of hCaptcha’s puzzle and scores, and have the data necessary to inform further rollout of hCaptcha on account creations. | |
| WE4.2.5 | If we conduct research, consult with communities, and investigate technical solutions, we will be able to define a set of structured block reasons that can be used across all WMF wikis. | |
| WE4.2.6 | If we develop the capability for deploying OpenSearch based clusters on the Data Platform, product feature engineering teams will be empowered to develop systems that integrate this capability, with a great deal of autonomy, resilience, and isolation from other search-based systems. The first and principal tenant for this system will be the IPoid service. | |
| WE4.2.7 | If we deploy hCaptcha Enterprise integration on several production Wikipedias as a pilot trial, we will be able to collect data on the efficacy and value of hCaptcha Enterprise on anti-abuse, bot detection, usability and accessibility. | |
| WE4.2.8 | If we make the hCaptcha proxy production-ready by improving its availability and observability, we will be delivering a more stable and reliable service to production Wikipedias in Q1. | |
| WE4.2.9 | If we integrate the hCaptcha SDK into the native mobile apps, evaluate the native app user experience and evaluate enabling hCaptcha challenges as part of the account creation API, we will have sufficient understanding to inform further rollout of hCaptcha for the account creation API. | |
| WE4.2.11 | If we enable hCaptcha for detecting bots in higher risk editing scenarios, we will see that hCaptcha can reduce automated abuse. | |
| WE4.2.16 | If we consult with relevant WMF teams, we will be able to develop an agreed-upon plan to manage more granular user access to non-public data, and support the deployment of non-public defensive software rules. | |
| WE4.2.17 | If we analyze real world examples and interview CheckUsers to identify at least 2 signals of potential abusive behaviour from the editor history prototype, the Product Safety and Integrity team will be able to later incorporate these signals into the Suggested Investigations feature with a higher level of confidence that the signals will provide value. | |
| WE4.3.2 | If we deploy JA4H fingerprints, which summarize HTTP client behavior, we will be better able to identify and categorize bot traffic | |
| WE4.4.1 | If we can make improvements based on pilots feedback and deploy Temporary Accounts to all projects we will be able to protect the exposure of personally identifiable information (IP addresses) of unregistered users on all our projects to be available to less than 0.1% of all (registered) users | |
| WE4.4.2 | If we communicate with the relevant movement stakeholders (incl. wiki communities and global functionaries) clearly and on time, we will be able to deploy on all remaining wikis, reduce workload discovered last-minute, and avoid rolling back deployment. | |
| WE4.4.5 | If we reduce friction for patrollers to identify bad actors who are using temporary accounts to vandalise, we will be able to prevent an increase in vandalism by measuring no increase in the revert rate across all wikis with temporary accounts. | |
| WE4.4.6 | If we sunset the LiquidThreads extension, we will unblock Temporary Accounts being deployed to all projects that currently use this extension. | |
| WE4.6.1 | If we automate the sync account process within Zendesk for password resets, this will alleviate the burden on T&S and allow them to handle more incoming 2FA reset requests | |
| WE4.6.3 | If we allow all users with a confirmed email address to be able to turn on 2FA for their accounts, but do not proactively advertise this change to users, our recovery support desk load will remain at a sustainable level. | |
| WE4.6.4 | If we continue our user experience overhaul of our 2FA system, and add support for passkeys, then more users will register multiple authentication factors and be better protected against losing account access. | |
| WE4.6.5 | If we design and build a general framework for specifying requirements that a local or global group’s members must meet, we will use this framework to enforce that members of the temporary-account-ip-viewer group meet existing policy requirements. | |
| WE4.6.6 | If we research how users with extended rights (UWER) rely on User Scripts, we will be able to propose a plan, which the UWER community could support, to make one or more significant technical interventions that would meaningfully secure the User Scripts system. | |
| WE4.6.7 | If we evaluate the user experience and technical changes required for the native mobile apps to align the mobile sign-in experience with the web platform, through exploring alternative mechanisms like OAuth, we can determine the feasibility of integration, in the interest of providing a more secure and consistent experience for users. | |
| WE4.6.8 | If we monitor the impact of the Zendesk and MediaWiki forms we built in Q1, then we can propose technical interventions for future quarters that would better automate the rest of the account recovery process. | |
| WE5.1.2b | If we integrate multiple methods for developer identification and authentication in the API gateway, we will be able to assign an appropriate rate limit to each request, by correctly identifying requests that come from different user cohorts. | |
| WE5.1.3b | If we perform a dry run for rate limiting on at least 3 routes of the REST gateway, this will allow us to verify feasibility of rate limiting with respect to resource consumption and to define an initial set of limits that could be enforced with minimal user impact. | |
| WE5.1.4b | If we validate the proposed API user segmentation mechanisms with broader data sets and manual reviews of the identified groups, we will be able to finalize the user cohorts, refine the methodologies used for calculation, and better understand their efficacy. | |
| WE5.1.5 | If we collaborate with the MediaWiki Platform team on traffic identification and rate limiting, we will be able to deploy rate limiting for dry run testing in production, by supporting the Platform team in the creation and roll out this capability. | |
| WE5.2.1b | If we engage with prospective users of the new REST API Explorer, this will help us identify key usability insights that indicate whether the new design is easy to use and aligned with developers’ mental model. | |
| WE5.2.2b | If we route the Action API through the central API gateway, we can begin consistently measuring traffic and usage patterns to gain insights that will inform future decisions and actions. | |
| WE5.2.4 | If we implement standard documentation patterns for 2 APIs, we will be able to refine the content guidelines, understand what API owners need in order to adopt the guidelines, and quantify the effort required to implement the guidelines across remaining Wikimedia API docs. | |
| WE5.2.5 | If we experiment with defining and applying OpenAPI spec linting rules to the MediaWiki REST APIs, we will demonstrate a means of programmatically enforcing API style guides to improve the quality and consistency of APIs published across Wikimedia and our communities. | |
| WE5.3.1 | If we expand and streamline UX attribution guidelines while updating any existing guidelines, we will establish a core set of improved guidelines ready to be internally tested and iteratively refined to be prepared for broader public use. | |
| WE5.3.1b | If we publish and iterate on the draft UX guidelines and demos, we will establish a core framework ready to be internally tested and iteratively refined to be prepared for broader public use. | |
| WE5.3.2 | If we create a pitch that demonstrates the benefits of attributing Wikipedia to 3rd party content reusers and their end-users, we can support WME4.1 & WME4.2 by enabling at least one additional reuse partner to agree to appear in an attribution case study or demo by the end of Q1. | |
| WE5.4.2b | If we build a scalable way to identify known clients, we can allow exceptions to general rate-limits for bots of verified origin, and move towards systematic enforcement of our rules. | |
| WE5.4.5 | If we start enforcing rate limits tailored to different classes of individual clients, we will reduce the burden of crawling on our infrastructure. | |
| WE5.4.6 | If by the end of Q2 we've classified the top N spiders as known bots, we can constrain the amount of resources they're using. | |
| WE5.4.7 | If we settle on a standardized sets of allowed thumbnail sizes on our media infrastructure, and we pregenerate the most expensive ones while rate-limiting generation of different image sizes, we will reduce the burden on the media serving infrastructure. | |
| WE6.1.2 | If we add wikifarms to a pre-merge testing environment this will enable development teams building against production who require multiple wikis to test their patches in isolation giving them greater pre-production confidence and result in fewer defect escapes. | |
| WE6.2.1 | If we review and publish our Production Readiness Checklist that clearly defines the prerequisites for a service to be considered production-ready, along with self-serviceable tasks, we will align expectations between SREs and development teams, improving our overall operational efficiency and scalability. | |
| WE6.2.2 | If we announce creating a Golang and nodejs library abstracting a lot of toilous tasks for developers, they will respond offering feedback and interest. | |
| WE6.2.4 | If we apply, and actively support the Data Persistence design review, we may identify paved pathways to production. | |
| WE6.3.2 | If we develop new metrics, improve Parsoid's cache infrastructure, and deploy on two "top-ten" wikipedias, we will develop performance criteria for the confidence framework, which will help validate our readiness for deployment to other large wikis and demonstrate our ability to handle high-traffic volumes at scale. | |
| WE6.3.3 | If we implement critical Language Variant support improvements and successfully deploy Parsoid to at least 3 Language Variant wikis in Q2, we will identify and resolve the key technical challenges necessary to confidently roll out to all remaining Language Variant wikis. | |
| WE6.4.6 | If SRE provides assistance to the MediaWiki engineering teams - through capacity and traffic management, preparation and review of configuration changes, and collaboration to investigate and troubleshoot issues - we will together complete the production PHP 8.3 upgrade in Q2 and document a set of recommendations to minimize critical-path dependencies on SRE for future upgrades. | T360995 |
| WE6.4.7 | If we migrate at least 90% of all users with global root access to use a hardware-backed SSH key for accessing Wikimedia production servers, we will reduce the risk that a compromised laptop will cause a severe security breach. | |
| WE6.4.8 | If the MediaWiki Engineering Team actively monitors and fixes issues in MediaWiki related to the PHP upgrade, this will enable the SRE team to complete the production PHP 8.3 upgrade by November 2025. | T360995 |
| Signals & Data Services (SDS) Hypotheses
[ SDS Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| SDS1.2.1 | If we migrate the XML Dumps process from the current 'Dumps 1' infrastructure to a data pipeline that leverages the MediaWiki Content Pipelines we will be able to guarantee SLOs and turn off the 'Dumps 1'-based XML export. | |
| SDS1.2.2 | If we do a walkthrough and review the SLOs for MediaWiki Content History and Event Platform / Event Gate, we can validate the customers, metrics, and dependent stakeholders, and identify improvements that might be needed for the SLOs, which will help us clarify any gaps in our weekly delivery guarantees. | |
| SDS1.3.1 | If we introduce client-side signals and audit them in comparison to the server-side webrequest logs, we will find additional bot patterns that can be characterized. | |
| SDS1.3.2 | If we assume the current bot vs human distribution as baseline and create automated alerts for shifts in the distribution, we will decrease detection time of the next unforeseen pattern of automated traffic from weeks to minutes. | |
| SDS1.3.3 | If we automate the backfill mechanism for webrequest and use it on the May logs, we will decrease the remediation time for future incidents from months to days and resolve the “rise in May pageviews” incident. | |
| SDS1.3.4 | If we create a regular, operationalized internal audit process for bot classification outputs, we will build trust in our solutions and anticipate changes in traffic patterns that are not automatically detected. | |
| SDS1.3.5 | If we analyze the basic client-side signal and incorporate it into our heuristics, we will detect additional bot patterns in the Data Platform. | |
| SDS1.3.6 | If we import, analyze and incorporate into our heuristics the Spur.us IP reputation, we will detect additional bot patterns in the Data Platform. | |
| SDS1.3.7 | If we import, analyze and incorporate into our heuristics one signal from the edge, we will detect additional bot patterns in the Data Platform. | |
| SDS1.4.1 | If we reconfirm existing analysis of trends within the Wikimedia ecosystem - pageviews, contributor and readership metrics, traffic, etc. - we will be able to confidently support salient talking points for our most important movement insights. | |
| SDS1.4.2 | If we reconfirm existing analysis of trends within the Wikimedia ecosystem - pageviews, contributor and readership metrics, traffic, etc. - we will be able to confidently support salient talking points for our most important movement insights. | |
| SDS2.1.1 | if we pair closely with teams running experiments, we will learn how to make the system more self-service in the future and what conceptual or technical challenges they may run into. | |
| SDS2.1.2 | If we can implement better debugging for eventlogging, then product teams will know that their experiment is collecting event data as expected, increasing experiment owners’ confidence. | |
| SDS2.1.3 | If we improve logging and observability for the A/B testing system (xLab) component of the experimentation platform, and for its related MediaWiki parts, we’ll be able to establish baselines for the system's performance and respond to experiment-related failures. | |
| SDS2.1.4 | If we share experiment stories and results across the organization once a month (through Product Ops meetings, Design team meetings, and cross-team presentations), then we will create organic adoption of the experimentation platform. | |
| SDS2.1.5 | If we tell users that their instrument, if created in xLab, contains a set of attributes that changes the risk category, we will deter instrumentation users from over-collecting data and increase clarity around what combination of attributes require privacy review. | |
| SDS2.1.6 | If the Growth Team works on instrumenting 2 use-cases (one with an A/B test to gain insight about bucketing capabilities, and one with long-term instrumentation to learn about support for KPI-like metrics) with the Experiment Lab, then we can evaluate whether it sufficiently fulfils the requirements to replace our bespoke experiments setup in GrowthExperiments. | |
| Future Audience (FA) Hypotheses
[ FA Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| FA1.1.4 | [Continued from last FY] If we build a new Wikipedia experience on Roblox, we will learn if this could be an effective way to introduce our brand to younger (Gen Alpha) audiences. | |
| FA1.1.2 | If we build a central hub for new Wikipedia experiences on itch.io, then we’ll be able to grow an audience of >50 interested non-Wikipedians giving us feedback, which will help us learn what works and what doesn’t in games. | |
| FA2.2.1 | If we invest in community management across short-video platforms, then by the end of Q2 (December 2025) we will see a 30% QoQ increase in the percentage of views from New Viewers on TikTok — and across all SFV platforms, we’ll earn 50,000 total engagements (likes and reply comments) on brand comments left on external content, which will help us increase visibility and drive engagement with audiences we’re not currently reaching. | |
| FA2.2.2 | If we develop and get sign-off on a Wikipedia Creator Partnerships Program internal strategy and external shareables (inclusive of an outline of our value to creators, partnership criteria, contracting process, and how creator content will show up across owned and creator channels), we will be able to establish a robust creator strategy that will help us reach new audiences across social media with our knowledge content. | |
| Product and Engineering Support (PES) Hypotheses
[ PES Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| PES1.1.5 | If we onboard the service level objectives (SLOs) for MediaWiki Content History and Wikifunctions to Sloth/Pyrra, we will get 2 more SLOs into production. | |
| PES1.1.6 | If we pilot Sloth with retroactive data from existing SLOs, we will understand whether Pyrra or Sloth (or something else) is the right tool for our fixed-window approach to error budget windows. We will learn about how to support service owners with a self-serve approach to SLO metrics and use them in decision making. | |
| PES1.2.4 | If we pilot a quarterly wish and community signal review process with 3 teams in Q1, we will engage Product Managers to integrate community signals into their quarterly and annual planning processes. | |
| PES1.2.5 | If we add the ability to filter and sort wishes on the Wishlist extension, to the improvements that allow categorisation with tags and voting, the 3 improvements will increase more unique participants in the Wishlist by at least 30%. | |
| PES1.3.3 | If we create at least 5 delightful interventions on platform that occur based on user interactions, we will define what the triggers will be for the portal page and the Birthday Mode gadget. Usability testing will tell us which interventions create positive associations with our brand. This hypothesis is time-bound to end by WikiCon North America at the end of October. | |
| PES1.3.4 | If we create an immersive website exploring Wikipedia's history, present, and future, in collaboration with members of the Comms department, aimed at engaging online audiences between 18-34 in campaign target areas, it will simulate greater connection with Wikipedia via social shares and other online activities. This will contribute to Comms’ KR of increasing brand presence by 10 percentage points, while telling us if dynamic approaches to content improve brand likeability. | |
Planejando Conjuntamente (Janeiro de 2025)
Atualização de janeiro de 2025.
.jpg)
O Plano Anual é a descrição da Fundação Wikimedia do que esperamos conquistar no ano vindouro. Nós trabalhamos muito para tornar o plano participativo, aspiracional e atingível. Todo ano, pedimos às pessoas contribuidoras que compartilhem suas perspectivas, esperanças e pedidos específicos conforme moldamos o plano. Algumas das maneiras com que buscamos esses comentários são por meio de conversas de equipes de produto com comunidades, a Lista de Desejos da Comunidade, conversas da comunidade como a série de conversas do Commons, em conferências e por meio de páginas wiki como esta.
Para o nosso próximo plano anual, de julho de 2025 a junho de 2026, estamos pensado em como podemos servir melhor uma visão multigeracional, dadas as rápidas mudanças no mundo e na internet e como isso afeta a nossa missão do conhecimento livre.
Como eu disse no último ano, precisamos focar no que nos diferencia: nossa capacidade de prover conteúdo confiável mesmo que a desinformação e as informações falsas estejam se proliferando pela internet e em plataformas que competem pela atenção das novas gerações. Isto inclui garantir que cumpramos a missão de reunir e entregar a soma de todo o conhecimento humano ao mundo expandindo nossa cobertura de informações em falta, que pode ser causado por iniquidade, discriminação e viés. Nosso conteúdo precisa também servir e se manter vital em uma internet em transformação e guiada por inteligência artificial e experiências ricas. E finalmente, precisamos encontrar meios de financiar sustentavelmente nosso movimento construindo uma estratégia compartilhada para nossos produtos e captação de recursos de modo que possamos apoiar esse trabalho a longo prazo.
Para fazer escolhas sobre onde focar nossos esforços no próximo ano, reunimos questões e pensamos sobre como alocar nossos recursos finitos na direção de realizar o máximo impacto.
Se você tem interesse especificamente em que funcionalidades ou serviços o departamento de Produto e Tecnologia construirá com base nas prioridades definidas aqui, haverá tempo em março para comentar em objetivos e resultados-chave específicos. (Aqui estão os objetivos e resultados-chave para o plano anual atual, para referência.)
Se você quer pensar sobre os desafios e oportunidades em nosso ambiente técnico e a direção que deveríamos configurar no próximo plano anual, por favor, considere as perguntas abaixo conosco.
Nós continuamente coletamos informações sobre essas perguntas de várias formas -- de conversas da comunidade, dados que coletamos, entrevistas de pesquisas que fazemos, e mais. Esta não é a primeira vez que estamos perguntando e aprendendo sobre muitas dessas coisas-e já andamos trabalhando em várias delas! Queremos perguntá-las de novo agora e seguir aprendendo, pois elas são nossa prioridade neste estágio do nosso planejamento.
Perguntas:
- Métricas e dados
- De quais maneiras os dados e métricas poderiam apoiar melhor o trabalho de vocês como pessoas editoras? Conseguem pensar em dados sobre edições, leituras ou organização que poderiam ajudar vocês a escolher como usar seu tempo, ou quando algo precisa de atenção? Poderiam ser dados sobre suas próprias atividades ou sobre atividades alheias.
- Editar
- Quando editar passa a maior sensação de recompensa e diversão para você? Quando passa a maior sensação de frustração e dificuldade?
- Queremos que as pessoas contribuidoras recebam mais feedback e reconhecimento por seu trabalho, para que não pareça que ninguém nota o esforço que elas fazem nas wikis. Que tipo de feedback e reconhecimento é motivador para você? O que te incentiva a continuar editando?
- Como as wikis são muito grandes, pode ser difícil para as pessoas editoras decidiram que wikitrabalho é mais importante para elas dedicarem seu tempo a cada dia. Que informações ou ferramentas ajudariam você a decidir como dedicar seu tempo? Seria útil ter um lugar central e personalizado que te permita encontrar novas oportunidades, gerir suas tarefas e entender seu impacto?
- Queremos melhorar a experiência de colaboração nas wikis, para que seja mais fácil para pessoas contribuidoras se encontrarem e trabalharem em projetos conjuntamente, seja reduzindo trabalho acumulado, editatonas, WikiProjetos ou até duas pessoas editoras trabalhando juntas. Como você acha que poderia ajudar mais pessoas contribuidoras a se encontrarem, se conectarem e trabalharem juntas?
- Ler/Aprender
- As wikis carregam mais rápido ou mais devagar dependendo de onde no mundo as pessoas moram. Tem alguma parte do mundo que você acha que mais precisa de um desempenho melhor?
- Como podemos ajudar novas gerações de pessoas leitoras a achar o conteúdo da Wikipédia interessante e engajante? Discutimos ideias sobre conteúdos e vídeos interativos anteriormente, e no ano atual nós focamos em gráficos e em experimentar novas maneiras de destacar conteúdo existente da Wikipédia. Como podemos continuar nesse caminho para usar nosso conteúdo existente de novas maneiras que sejam únicas da Wikimedia?
- Pessoas moderadoras
- O que pode precisar mudar sobre a Wikipédia de modo que mais pessoas queiram se envolver em papéis voluntários avançados, como nas áreas de patrulhamento e administração?
- Que informações ou contexto sobre edições ou pessoas usuários poderiam ajudar você a tomar decisões de patrulhamento ou administração mais rápida ou facilmente?
- Tendências Externas
- Quais são as mudanças mais importantes que você está notando no mundo fora da Wikimedia? Podem ser tendências em tecnologia, educação ou como as pessoas aprendem.
- Fora do movimento Wikimedia, de que outras comunidades online você participa? Que lições podemos tirar das ferramenta e processos em outras plataformas de comunidade?
- Como você está usando ferramentas de IA dentro e fora do seu trabalho na Wikimedia? Para o que você acha a IA útil?
- Commons
- Que decisões podemos tomar com a comunidade Commons para criar um projeto sustentável que apoie a criação de conhecimento enciclopédico?
- Wikidata
- Como você gostaria de ver o Wikidata evoluir no futuro? Como ele pode ser o mais útil possível para construir conteúdo enciclopédico confiável?